Resolved There was an issue with updating system packages and third-party components. pum is called with arguments: ['--list', '--repo-info', '--json']

[PeopleInside]

Server operating system version

Ubuntu 22.04.5 LTS

Plesk version and microupdate number

18.0.71 Update 2

Hi, I hope this message finds you well.
Since different days I'm getting an email from Plesk that indicate issues on updating third-party components.
The email say:

There was an issue with updating system packages and third-party components
Reason: 2025-08-02 06:26:21 INFO: pum is called with arguments: ['--list', '--repo-info', '--json']
2025-08-02 06:26:59 ERROR: Apt cache fetch failed. Try to run the `apt-get update` command.
2025-08-02 06:26:59 ERROR:
2025-08-02 06:26:59 ERROR: Exited with returncode 1.

I searched on the Internet for a solution but I was unable to fix and find a solution.
Could you please help me?

IF I run

apt-get update

by SSH I don't get any error.
Thank you in advance!

 

[PeopleInside]

The error can be reproduced using the command:

/usr/local/psa/admin/sbin/pum --list --repo-info --json

Result:

2025-08-02 11:00:20 INFO: pum is called with arguments: ['--list', '--repo-info', '--json']
2025-08-02 11:00:20 ERROR: Update operation was locked by another update process (Plesk installer or pum).
2025-08-02 11:00:20 ERROR: Exited with returncode 100.

 

[PeopleInside]

After this error I run:

ps aux | grep -E 'pum|plesk'

to check if some process was locking the update.

AI helped to understand the result and no process was locking the update.

I checked also for zombie process

sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/apt/lists/lock
sudo lsof /var/cache/apt/archives/lock
sudo lsof /opt/psa/var/modules/pum/pum.lock

but everything was fine.

Now running

/usr/local/psa/admin/sbin/pum --list --repo-info --json

it gives a long Json output so everything seems is working fine but is since 4 days I get error email every morning.

Maybe something in the way update work should be improved checking for locking process and retry as soon process are not locked or better management of scheduled process. I hope this issue never happen again in tomorrow morning and I hope Plesk can maybe improve this.

I can read about other users that has reported the same issue and was not finding any solution.

 

[Sebahat.hadzhi]

Regarding:

2025-08-02 11:00:20 ERROR: Update operation was locked by another update process (Plesk installer or pum).

please try running:

plesk installer stop

If the update issue still continues, please double-check /var/log/plesk/systemupdatestool.log and /var/log/plesk/install/autoinstaller3.log for additional details.

 

[PeopleInside]

Hi Sebahat, thank you for your kind reply and for your time.
I hope your day is going well!
I will try and see, for now the error has been stopped but can happen again in the future as maybe Plesk run some update when is running other update.
Thank you!

 

[PeopleInside]

Hi, the issue start to be again present since different days (2).

var/log/plesk/systemupdatestool.log

2025-08-13 06:26:04 INFO: pum completed successfully
2025-08-13 06:26:05 INFO: pum is called with arguments: ['--check']
2025-08-13 06:26:09 INFO: pum is called with arguments: ['--list', '--repo-info', '--json']
2025-08-13 06:26:47 ERROR: Apt cache fetch failed. Try to run the `apt-get update` command.
2025-08-13 06:26:47 ERROR:
2025-08-13 06:26:47 ERROR: Exited with returncode 1.

/var/log/plesk/install

no recent log here

 

[PeopleInside]

As I cannot get in touch with Plesk support because it require to me to pay to access the support, as also the Plesk guide here seems have the same error but not the same cause, as... I looked into the

/var/log/plesk/install/autoinstaller3.log

, I was able to find some row related to the 13 august but nothing as in the plesk guide... so this plesk guide never help me...

There is a way to disable only fail update notification as seems Plesk is not managing well this?

 

[PeopleInside]

If I run

/usr/local/psa/admin/sbin/pum --list --repo-info --json

right now no errors on SSH but is two days that in the morning at 6 AM I get a Plesk email of failed update. This is very annoying.

On my opinion this is not managed well.
I don't see any fix I can apply to resolve this.

Maybe would be useful have a fail email notification only if the error persist after different retry or I don't know why I get disturbed often by this Plesk email.
This kind of update error should not happen and also I don't see how to resolve with the notification email.
Turn off the update email also for successfully update doesn't look a good idea.

 

[PeopleInside]

Unfortunately if I want help and resolve this issue seems I'm forced to contact the Plesk support.

 

[GerdSchrewe]

I have been experiencing exactly this problem for months on two Contabo V-servers running Ubuntu 22.04 and Plesk Obsidian 18.0.71 Update 1, Web Pro Edition. Every 2–3 days I get this message. Most of the time, the updates via Plesk work the next day. Sometimes it takes 2–3 days.

 

[PeopleInside]

It's terrible and seems there is not a real solution.
For now I'm trying to change the update time but even the support seems unable to find a log that motivate the issue.
Seems like a network temporary issue that still disturb me by email ... many different days... sometimes yes, sometimes no.

 

[PeopleInside]

At the end what seems helped is move the cronjob to 6 AM to 14 PM
Plesk guide here
In the Plesk guide I need select the Ubuntu tab: " (For Debian-based Linux operating systems (Debian, Ubuntu, etc.) "

 

[trialotto]

At the end what seems helped is move the cronjob to 6 AM to 14 PM
Plesk guide here
In the Plesk guide I need select the Ubuntu tab: " (For Debian-based Linux operating systems (Debian, Ubuntu, etc.) "

@PeopleInside

In most cases, these kind of "pum related" issues go away after 1 or a couple of days.

As a result, in most cases, it is safe to ignore the error notifications - not desirable, not truely safe, but ignoring them is sufficient.

Setting the cronjob at 14PM - or any time at which your endusers need working sites and hosting panels - is not recommended.

I hope the above helps a bit...

Kind regards....

 

[PeopleInside]

@trialotto for me this problem lasted for weeks, for almost every day.
Was starting to be stressful have a server that inform of error every days.

What I shared finally here is the result of the investigation and suggestion from Plesk support and seems it worked so, change the Plesk scheduled maintenance tasks was what it worked and what Plesk support suggested to me. This is maybe also the reason a guide has been created in the past by Plesk support Team.

 

[trialotto]

@trialotto for me this problem lasted for weeks, for almost every day.
Was starting to be stressful have a server that inform of error every days.

What I shared finally here is the result of the investigation and suggestion from Plesk support and seems it worked so, change the Plesk scheduled maintenance tasks was what it worked and what Plesk support suggested to me. This is maybe also the reason a guide has been created in the past by Plesk support Team.

@PeopleInside

The workaround suggested by Plesk can work for many reasons, but it still is a workaround that can other issues - for instance, an issue might be and probably is that you are updating packages during rush hours, hence leaving the server less responsive and the web server even unresponsive.

In essence, one has to look for the root cause of the problem : why do your servers give pum related issues at a specific time (and not at other times)?

There might be regular network maintenance hindering updates and, although not very likely, even running backup processes might cause issues with updates.

There might also be external factors like repositories that can temporarily not be reached, due to network errors or regular maintenance on the repository side.

And in some odd scenario's, update processes might hang and cause issues with update processes that are - essentially - reinitiated.

Stated differently, one can apply a workaround, that is perfectly safe - nevertheless, I would be curious about the root cause of the problem.

For instance, if your server provider has the nasty habit of creating bad mirrors and/or doing frequent network maintenance (with network related errors when running updates), then I would really like to know that : this is a rock-solid reason to another server provider.

In short, a workaround may work fine, but it will also not give you an incentive to look at the actual root cause of the problem that might be severe.

Kind regards.....

 

[PeopleInside]

@PeopleInside

The workaround suggested by Plesk can work for many reasons, but it still is a workaround that can other issues - for instance, an issue might be and probably is that you are updating packages during rush hours, hence leaving the server less responsive and the web server even unresponsive.

In essence, one has to look for the root cause of the problem : why do your servers give pum related issues at a specific time (and not at other times)?

There might be regular network maintenance hindering updates and, although not very likely, even running backup processes might cause issues with updates.

There might also be external factors like repositories that can temporarily not be reached, due to network errors or regular maintenance on the repository side.

And in some odd scenario's, update processes might hang and cause issues with update processes that are - essentially - reinitiated.

Stated differently, one can apply a workaround, that is perfectly safe - nevertheless, I would be curious about the root cause of the problem.

For instance, if your server provider has the nasty habit of creating bad mirrors and/or doing frequent network maintenance (with network related errors when running updates), then I would really like to know that : this is a rock-solid reason to another server provider.

In short, a workaround may work fine, but it will also not give you an incentive to look at the actual root cause of the problem that might be severe.

Kin

 

[PeopleInside]

At 6 AM Ubuntu run his cronjob to update the system. Plesk run his update too early after this time and uldate may still be in progress then cause the error.

Move the Plesk maintenance cronjob to a later time works just for that.

I monitored the server resource usage and it's not currently an issue so all looks fine.

I don't know why this issue started to exist just recently after for a long time I don't have that. Maybe also Plesk may introduce some bug with time as the recent issue with let's encrypt renew that generate email errors about the renew.

Finally after a long ticket work this was the solution: move the Plesk cronjob to a different time.

 

[GerdSchrewe]

In the meantime, I’ve learned to live with the “error messages.”
When error messages about updates that cannot be executed or Let’s Encrypt certificates that cannot be renewed arrive by email, I just ignore them, instead of spending hours tracking down the cause.
I also no longer install Plesk updates (e.g., 18.0.27) right away but instead wait for two follow-up updates first (updates that unfortunately sometimes bring new bugs - that used to be better).
But how confusing must that be for a Plesk beginner?

 

[PeopleInside]

For me the discussion with you ends here.
Its a good idea to wait a little before install updates but the intent of this discussion was searching for help. Your replies did not helped me at all. Have a nice day. Fortunately I shared what was working and if you don't agree that it's a good solution, it's ok. I shared what finally helped me. Have a nice day and time and enjoy your server, expert user

 

[GerdSchrewe]

I completely agree with you. My approach is not a solution.
As you already wrote, one can (indeed) prevent the emails with error messages about updates by changing the cronjob time, but the real cause still remains unresolved. Everyone finds his own way of dealing with it...
Wishing you all the best!