Question Package Update Manager notification

[JM Malsacre]

Server operating system version

Debian 11

Plesk version and microupdate number

Plesk Obsidian 18.0.75 Web Host Edition

Hello,
Excuse my bad english...
From many days i receive every day a message "Package Update Manager notification" from Plesk (in French... sorry) :

Un problème s'est produit lors de la mise à jour des packages du système et des composants tiers sur le serveur xxxxxxxxxxxxxxxxxxxx.plesk.page. Veuillez patienter jusqu'à la prochaine mise à jour automatique ou lancez la mise à jour manuellement : https://xxxxxxxxxxxxxxxxxxxx.plesk.page/admin/pum

Raison : 2026-02-24 06:27:10 INFO: pum is called with arguments: ['--verbose', '--list', '--repo-info', '--json']
2026-02-24 06:27:10 DEBUG: pum is started with debug logging
2026-02-24 06:27:41 ERROR: Apt cache fetch failed. Try to run the `apt-get update` command.
2026-02-24 06:27:41 ERROR:
2026-02-24 06:27:41 DEBUG:
Traceback (most recent call last):
File "pum_common.py", line 314, in do_main
_do_main(package_manager_maker)
File "pum_common.py", line 268, in _do_main
_do_work(package_manager_maker, options, arguments)
File "pum_common.py", line 277, in _do_work
package_manager = package_manager_maker(options.unsafe, check=options.check)
File "papt.py", line 23, in wrapper_maker
File "papt.py", line 16, in wrapper_maker
File "apt_wrapper.py", line 50, in __init__
self.cache.update()
File "/usr/lib/python3/dist-packages/apt/cache.py", line 575, in update
raise FetchFailedException()
apt.cache.FetchFailedException
2026-02-24 06:27:41 ERROR: Exited with returncode 1.

I'm not an experimented user and i don't know how i can resolve this 'error'.
If someboby can help me?

Jean-Marie

 

[mdmd]

It seems like a problem with cache metadata fetching. Could you try to run `apt-get update` directly on your server, and get more logs?

 

[JM Malsacre]

Thanks for your reply.

# apt-get update
Hit:1 Index of /pool/PSA_18.0.75_18153 bullseye InRelease
Hit:2 Index of /PHP81_17 bullseye InRelease
Hit:3 Index of /debian bullseye InRelease
Hit:4 Index of /debian-security bullseye-security InRelease
Hit:5 Index of /PHP82_17 bullseye InRelease
Hit:6 Index of /PHP83_17 bullseye InRelease
Hit:7 Index of /debian bullseye-updates InRelease
Hit:8 Index of /grafana/deb stable InRelease
Hit:9 Index of /RUBY_1.5.0 bullseye InRelease
Hit:10 Index of /imunify360/debian/11/ bullseye InRelease
Hit:11 Index of /alt-common/deb/debian/11/stable/ bullseye InRelease
Hit:12 Index of /debian/11/slot-1/ bullseye InRelease
Hit:13 Index of /debian/11/slot-2/ bullseye InRelease
Hit:14 Index of /debian/11/slot-3/ bullseye InRelease
Hit:15 Index of /debian/11/slot-4/ bullseye InRelease
Hit:16 Index of /debian/11/slot-5/ bullseye InRelease
Hit:17 Index of /debian/11/slot-6/ bullseye InRelease
Hit:18 Index of /debian/11/slot-7/ bullseye InRelease
Hit:19 Index of /debian/11/slot-8/ bullseye InRelease
Reading package lists... Done

I don't understand anything... Lol

 

[Sebahat.hadzhi]

@JM Malsacre , please check /var/log/plesk/install/autoinstaller3.log for any recent errors logged.

 

[JM Malsacre]

Thanks for your reply.
In attached file an extract of the log file from this morning.
Regards.

 

[Sebahat.hadzhi]

Thank you. I reviewed the logs and I can see several errors, but they shouldn't be related to the Apt cache fetch failed. error and can be safely ignored. From what I can see apt-get update works fine, so this is likely a temporary network connectivity issue.

 

[King555]

I get this error via mail about once per week. A simpleapt-get update (as already mentioned) or apt update (what I use) always solves this problem.

 

[JM Malsacre]

Thanks for your response.
I am reassured by your post.
I saw on another post that a user had managed to stop getting these error messages by changing the time of the script launch in the crontab.
I just shifted the launch time and I"ll see if it works anything out.
Regards
Jean-Marie

 

[Sebahat.hadzhi]

@King555 , if the issue is reoccurring the root cause could be due to overlapping in running the native OS service and the daily Plesk cron job. Plesk itself does not specify an exact time for the daily task, but relies on the OS to do so. The error happens due to system repositories rather than Plesk resources. If that's the case, you can also try adjusting the time of the Daily maintenance task as suggested by @JM Malsacre :

• https://support.plesk.com/hc/en-us/...Daily-Maintenance-tasks-run-on-a-Linux-server