Issue Error System Updates

[theplaza]

Server operating system version

Ubuntu 24.04.5 LTS

Plesk version and microupdate number

18.0.82

Hello,

How can I solve this problem: Error: Cannot get package list: 2026-11-04 09:44:23 INFO: pum is called with arguments: ['--list', '--repo-info', '--json'] 2026-11-04 09:44:23 ERROR: Previous Plesk installer call finished unsuccessfully. PUM will not perform any update operations until Plesk installation is fixed. 2026-11-04 09:44:23 ERROR: Exited with returncode 50.

Thank you

 

[Sebahat.hadzhi]

Hi, @theplaza . Could you please run plesk repair installation and confirm if any issues are reported? Thank you in advance.

 

[theplaza]

Hi! here is the report:
plesk repair installation

Reconfiguring the Plesk installation

Started bootstrapper repair procedure. This may take a while.
Certain actions may be skipped if not applicable.

Finishing up upgrade procedures and rerunning previously failed upgrade actions...
===> Cumulative Plesk database upgrade and repair (revertable stage) has been started.
===> Preparing Plesk database upgrade (revertable stage).
===> Cumulative upgrade and repair of Plesk database (revertable stage) has been completed.
===> Plesk database scheme upgrade has been started.
Applying migrations from: /opt/psa/bootstrapper/pp18.0.82-bootstrapper/migrations/
===> Plesk database scheme upgrade has been completed.
===> Cumulative Plesk upgrade and repair (final stage) has been started.
===> Preparing Plesk upgrade (final stage).
===> Cumulative upgrade and repair of Plesk (final stage) has been completed.
Reconfiguring mail subsystem...
Reconfiguring Apache web server...
Reconfiguring ProFTPD FTP server...
===> Configuring ProFTPD server
Restoring SELinux contexts...
Reconfiguring SSL ciphers and protocols...
Regenerating web servers' configuration files...
Cleaning active Panel sessions...
Fixing permissions on Panel packages files
The file '/var/parallels/autoinstaller-installation-failure.flag' is present, which may indicate problems with recent update.
Please check '/var/log/plesk/install/plesk_18.0.82_repair.log' for details

Check:

tail -n 50 /var/log/plesk/install/plesk_18.0.82_repair.log
INFO: Executing upgrade task: 2019-04-25-14-46-58 (forced)
SUCCESS: Upgrade step 2019-04-25-14-46-58_ReportUsage.php was successfully done.
INFO: Executing upgrade task: 2020-03-19-17-13-39 (forced)
SUCCESS: Upgrade step 2020-03-19-17-13-39_UpgradeExtensions.php was successfully done.
done
===> Cumulative Plesk upgrade and repair (final stage) has been started.
Upgrade or repair for 'core' (stage 'post') is not required
===> Preparing Plesk upgrade (final stage).
===> Cumulative upgrade and repair of Plesk (final stage) has been completed.
Reconfiguring mail subsystem...
Trying to execute plesk repair mail to synchronize mail server settings and Plesk Database...
Repairing the mail server configuration
Reconfiguring all domains and mailboxes ......................... [OK]

Error messages: 0; Warnings: 0; Errors resolved: 0

Reconfiguring Apache web server...
Reconfiguring ProFTPD FTP server...
Restoring SELinux contexts...
Trying to register service sw-cp-server... Trying to enable automatic respawn for service sw-cp-server.service... done
done
Trying to register service sw-engine... Trying to enable automatic respawn for service sw-engine.service... done
done
Trying to register service dovecot... Trying to enable automatic respawn for service dovecot.service... done
done
Trying to register service pc-remote... Trying to enable automatic respawn for service pc-remote.service... done
done
Trying to register service nginx... Trying to enable automatic respawn for service nginx.service... done
done
Trying to register service psa... Trying to enable automatic respawn for service psa.service... done
done
Reconfiguring SSL ciphers and protocols...
Trying to configure SSL ciphers and protocols for: ... done
Regenerating web servers' configuration files...
Cleaning active Panel sessions...
Fixing permissions on Panel packages files
The file '/var/parallels/autoinstaller-installation-failure.flag' is present, which may indicate problems with recent update.
Please check '/var/log/plesk/install/plesk_18.0.82_repair.log' for details

Bootstrapper repair finished.
If problems persist, please check installer logs ('/var/log/plesk/install/plesk_18.0.82_repair.log' and '/var/log/plesk/install/plesk_18.0.82_repair_problems.log') for errors.
If you can't resolve the issue on your own, please address Plesk support.
Trying to restart service apache2... active
done
SUCCESS: Upgrade step Plesk\Upgrade\Action_UpgradeExtensions was successfully done.
done

**** Product repair completed successfully.

 

[Andrea Bampi]

same here on two brand new VPSs with Ubuntu 24.04.5 and Plesk 18.0.82#1, after this morning's update. Both updated "correctly" and panel+sites work fine, but something broke the updating system / pum and now a "Check Updates" click fails with the same error

 

[theplaza]

Following Sebahat's advice, it seems to be unblocked now. But I wanted confirmation from the log.

 

[Andrea Bampi]

Following Sebahat's advice, it seems to be unblocked now. But I wanted confirmation from the log.

The thing is, it seems believable that the issue has something to do with the combo Ubuntu 24.04.5 + this specific update.
I had 6 other VPS with Ubuntu 22 that updated flawlessly.The only two with U24 failed. Can't be a coincidence. Thing is, many people could simply have not seen anything wrong - I spotted the issue just because I didn't get the notification email from the 2 servers. How did you spot it? Just trying to check new updates this morninga? Because otherwise, the servers work (and the sites too)

 

[Andrea Bampi]

Just to clarify: repairing plesk didn't do anything. It proved that nothing important in the autoupdate process actually went wrong; it simply was stopped before the very last step.
The autoinstaller-installation-failure file wasn't removed by the repair procedure; I moved the file (btw it's just an empty placeholder file with size 0) in my root dir just to check and (as expected) now the "Check for updates" button works again.
I DISABLED ALL PLESK AUTOUPDATES for now, since it's unclear if the issue was specific to 18.0.82#2 or general. I expect that Plesk staff will investigate the matter in a deeper way.

 

[Sebahat.hadzhi]

@theplaza , just to confirm were you able to complete the update after the repair?

@Andrea Bampi , the issue is commonly caused by interrupted update process, corrupted Plesk installation, and package inconsistencies. I just performed a test update on an Ubuntu 24 server from Plesk Obsidian 18.0.82 Update #1 to Plesk Obsidian 18.0.82 Update #2 and the process went through without issues. If repairing the installation doesn't work in your case, please check what additional details have been logged into /var/log/plesk/install/autoinstaller3.log. Thanks in advance.

 

[Andrea Bampi]

Thanks for testing this.

Your successful Ubuntu 24.04 test suggests this is not a deterministic Ubuntu 24 issue, but on my side I had the same failure on two separate brand-new Ubuntu 24.04.5 VPSs, both upgrading automatically from 18.0.82 Update #1 to Update #2.

For comparison, I have six Ubuntu 22.04 servers and all six completed the same automatic update successfully (this morning, at 0630).

On both affected Ubuntu 24 servers, the actual Plesk upgrade appears to complete correctly. The failure happens immediately afterwards, during report-update.

Example from one server:

Cumulative upgrade of Plesk (final stage) has been completed.

[2026-11-04 06:31:44.794729] Plesk Installer process has received termination signal and will stop working (signal number 15).
[2026-11-04 06:31:44.800097] Launching component and product checkers...
[2026-11-04 06:31:44.800132] FileFetcher: get file (<empty>)/report-update
[2026-11-04 06:31:44.800178] Downloading file report-update: 0%
[2026-11-04 06:31:44.803420] Plesk Installer process has received termination signal and will stop working (signal number 15).
[2026-11-04 06:31:44.804821] Error: Interrupted by user
At almost exactly the same time, the system journal shows:

Nov 04 06:31:44.793773 systemd[1]: Stopping run-plesk-task-686.service - Plesk task: Daily Maintenance: InstallUpdates ...
After this, /var/parallels/autoinstaller-installation-failure.flag remains present and PUM fails with:

Previous Plesk installer call finished unsuccessfully.
PUM will not perform any update operations until Plesk installation is fixed.
Exited with returncode 50.
I ran plesk repair installation on one server. It completed successfully with no repair errors, but it did not remove the failure flag and PUM remained blocked.

After moving that zero-byte flag out of /var/parallels, "Check for Updates" immediately started working again.

Also, before doing this:

dpkg --audit
pgrep -a apt
pgrep -a dpkg
all returned clean/no output.

So the interesting part seems to be that Daily Maintenance: InstallUpdates is being stopped while the autoinstaller is still finishing report-update.

For now I have disabled automatic Plesk updates only on my three Ubuntu 24.04 servers, until it is clearer whether this was specific to Update #2 or could happen again on a future update.

 

[Sebahat.hadzhi]

Thank you for the additional details. I ran a manual update, and it looks like the issue might be related to the automatic update. I will attempt to replicate the SIGTERM with an additional test with an automatic update and follow up with more details tomorrow. Thanks for your patience in the meantime.

 

[theplaza]

@theplaza , just to confirm were you able to complete the update after the repair?

@Andrea Bampi , the issue is commonly caused by interrupted update process, corrupted Plesk installation, and package inconsistencies. I just performed a test update on an Ubuntu 24 server from Plesk Obsidian 18.0.82 Update #1 to Plesk Obsidian 18.0.82 Update #2 and the process went through without issues. If repairing the installation doesn't work in your case, please check what additional details have been logged into /var/log/plesk/install/autoinstaller3.log. Thanks in advance.

Yes, The manual update was performed successfully, without any issues.

 

[Andrea Bampi]

Just another small clarification based on my experience on the affected servers.
Removing the failure flag alone is not sufficient; plesk repair installation is what actually clears the underlying failed-upgrade state. Something has to be fixed with an actual "plesk repair installation" command, otherwise pum remains stuck even when the failure flag file has been manually removed.
So, both actions seem to be mandatory.
I'm just concerned about the next automatic update, I hope to hear some news asap.
Thanks

 

[Sebahat.hadzhi]

Thank you for your patience. I configured two separate instances with auto-updates enabled and have been monitoring them. Each of the instances was successfully updated. With that said, I cannot point of what caused the issue in your cases, but it is likely related to the local environment rather than being a generic Plesk bug/issue. To attempt to narrow down why exactly the installer received SIGTERM, please check the following:

journalctl -o short-precise --since "2026-11-04 06:31:20" --until "2026-11-04 06:32:00"

 

[Andrea Bampi]

Thank you for your patience. I configured two separate instances with auto-updates enabled and have been monitoring them. Each of the instances was successfully updated. With that said, I cannot point of what caused the issue in your cases, but it is likely related to the local environment rather than being a generic Plesk bug/issue. To attempt to narrow down why exactly the installer received SIGTERM, please check the following:

journalctl -o short-precise --since "2026-11-04 06:31:20" --until "2026-11-04 06:32:00"

Here is the relevant filtered journal output from imhotep2. The full journal for that interval is more than 600 lines, so I filtered it around the Plesk task/systemd activity.

One thing that may also be relevant is that several systemd reloads are requested from processes running inside run-plesk-task-686.service immediately before the service is stopped:

Nov 04 06:31:39.281613 systemd[1]: Reloading requested from client PID 278746 ('systemctl') (unit run-plesk-task-686.service)...
Nov 04 06:31:39.503031 systemd[1]: Reloading requested from client PID 279006 ('systemctl') (unit run-plesk-task-686.service)...
Nov 04 06:31:39.742074 systemd[1]: Reloading requested from client PID 279208 ('systemctl') (unit run-plesk-task-686.service)...
Nov 04 06:31:40.180539 systemd[1]: Reloading requested from client PID 279398 ('systemctl') (unit run-plesk-task-686.service)...
Nov 04 06:31:40.400589 systemd[1]: Reloading requested from client PID 279695 ('systemctl') (unit run-plesk-task-686.service)...
Nov 04 06:31:40.608438 systemd[1]: Reloading requested from client PID 279880 ('systemctl') (unit run-plesk-task-686.service)...
Nov 04 06:31:41.032137 systemd[1]: Reloading requested from client PID 279974 ('systemctl') (unit run-plesk-task-686.service)...
Nov 04 06:31:41.244648 systemd[1]: Reloading requested from client PID 280361 ('systemctl') (unit run-plesk-task-686.service)...

Nov 04 06:31:43.822527 systemd[1]: Reloading apache2.service - The Apache HTTP Server...
Nov 04 06:31:44.793773 systemd[1]: Stopping run-plesk-task-686.service - Plesk task: Daily Maintenance: InstallUpdates (task=685 process=686 trace=259308:6aeac1adaa66)...
Nov 04 06:31:44.824091 systemd[1]: run-plesk-task-686.service: Deactivated successfully.
Nov 04 06:31:44.824370 systemd[1]: Stopped run-plesk-task-686.service - Plesk task: Daily Maintenance: InstallUpdates (task=685 process=686 trace=259308:6aeac1adaa66).
Nov 04 06:31:44.836971 systemd[1]: Started run-plesk-task-686.service - Plesk task: Daily Maintenance: InstallUpdates (task=685 process=686 trace=259308:6aeac1adaa66).
Nov 04 06:31:44.944320 systemd[1]: run-plesk-task-686.service: Deactivated successfully.
Nov 04 06:31:44.944457 systemd[1]: Stopped run-plesk-task-686.service - Plesk task: Daily Maintenance: InstallUpdates (task=685 process=686 trace=259308:6aeac1adaa66).

At essentially the exact same time, /var/log/plesk/install/autoinstaller3.log reports:

[2026-11-04 06:31:44.794729] Plesk Installer process has received termination signal and will stop working (signal number 15).
[2026-11-04 06:31:44.803420] Plesk Installer process has received termination signal and will stop working (signal number 15).
[2026-11-04 06:31:44.804821] Error: Interrupted by user
So the first SIGTERM is logged less than 1 ms after systemd begins stopping the Daily Maintenance: InstallUpdates transient service.

This looks like the most relevant correlation I can find in the journal.

 

[tessa67]

Hi @Andrea Bampi ,

one thing in your journal snippet that I don't think has been unpacked yet, and it might be the actual mechanism behind the SIGTERM.

Look at the sequence again: the wrapper fires a bunch of systemctl reload calls, then systemd stops run-plesk-task-686.service, and less than 1 ms later the installer logs SIGTERM. That's not a timeout. That's systemd tearing down the cgroup the moment the wrapper exits.

The relevant systemd behavior here is ExitType. It defaults to main, which means systemd considers a service finished as soon as the main process exits — regardless of whether child processes in the same cgroup are still running. If Plesk's task wrapper is the main process and autoinstaller is a child, then the wrapper reaching its exit point (or being killed by one of those reload operations) is enough for systemd to start sending SIGTERM to everything left in the cgroup. The installer gets caught mid-report-update.

ExitType=cgroup is the counterpart: systemd keeps the unit alive as long as any process in the cgroup is running. It's specifically documented as suitable for transient or automatically generated services, which is exactly what run-plesk-task-* units are.

You can test this on one of the affected boxes without waiting for the next maintenance window:

systemctl show run-plesk-task-686.service -p ExitType -p MainPID -p ControlGroup

If ExitType=main and MainPID is not the installer PID, that's the confirmation. You'd also want to see the cgroup contents during a run:

systemd-cgls | grep -A10 run-plesk-task

If autoinstaller shows up as a child inside that cgroup, the teardown theory holds.

One more angle worth checking, since you have U22 and U24 side by side: systemd 249 (U22) vs 255 (U24) handle transient unit cleanup differently in some edge cases. That could explain why the six U22 boxes sailed through while the two U24 boxes ate the SIGTERM, without it being an "Ubuntu 24 bug" in any meaningful sense. Check the systemd version on both groups:

systemctl --version

If the U22 boxes are on 249 and the U24 boxes on 255, that's a plausible variable. Plesk's own test instances (whatever they were running) may have had timing that didn't hit the window.

I'm not claiming this is definitively it — but it's testable, it matches the millisecond-level correlation you documented, and it gives the devs something concrete to look at beyond "interrupted update." If ExitType is already cgroup on those units, the theory is dead and we look elsewhere.

Regards
Tessa