Issue Error System Updates

[Andrea Bampi]

@Andrea Bampi

To respond to this

I cannot help myself and - somehow - need to state that I personally dislike the concept of VPSes : it is being promised a box-in-a-box, without knowing what the outerbox actually is. A "jack in the box", so to speak.
...

is worth investigating, taking into account that

- Plesk 18.0.82 MU2 seems to be a bit problematic for a lot of Plesk users, but (in theory) it should not be able to explain your issues,
- the possibility of VPS and/or its host environment overloading should be investigated first ...... to eliminate this as a potential explanation.


Kind regards.....

Thanks for all the advice..
frankly, I never had any issue with VPSs until now - and I much prefer to work with VPSs instead of baremetal servers (which I had in the past) for a couple of very practical reasons: 1) scalability 2) automatic snapshots/full backups
Anyway, I get your point but as I said, ALL VPSs are in the same farm, it's weird that every single U22 didn't have issues with that update and ALL U24 had the same issue. If my hoster has general overloading issues, I'd expect to experience random problems on U22 machines too. I freely chose to install U24 instead of U22, so I'm pretty sure all the VPSs are "mixed" together. Maybe U24 is more resource-draining? I don't know. It's beyond my knowledge level and expertise

 

[trialotto]

@Andrea Bampi

This is

If my hoster has general overloading issues, I'd expect to experience random problems on U22 machines too.

is actually missing the point.

As I said before, the host environment (of the VPSes) is a black box : a black hole from the perspective of the VPS or your perspective.

For instance, if you installed all U24 systems at the same time, then Plesk update will "more or less" run at the same time and interval - causing overloads at the host level and at the VPS level : a double whammie and a double issue ....... a chicken-and-egg discussion (what was first?).

The above scenario is not very likely though, but it can really occur on badly configured hosts (and that is more common that one would imagine).

In general, any VPS (yours and others) can cause havoc by essentially doing some tasks at virtually the same time, hence consuming the host's resources.

Memory overloads used to be a big problem on the host, not due to lack of memory, but simply due to badly coded software assigning memory to VPSes.

Disk IOPS related issues are nowadays often causing havoc ........ even though there is or should be no need for this issue.

Then again, the big black hole that the host environment is, is unknown to you : RAID 5 setup? harddisks or SSDs? state-of-the-art systems or old systems that would otherwise not be used anymore?

In most cases, an educated guess will suffice : old systems are repurposed for the sake of cheap hosting with high margins by means of VPS offerings.

Now, consider your use-case and take it to an extreme level : you install 3 Plesk installation at once, hence requiring a lot of resources from the host (that will be assigned, with a small or big delay) .......... and these 3 Plesk installations update at the same time and interval (just like most or all other Plesk instances on the same host), hence requiring memory and disk IOPS at the same time ..........

........ and then there are multiple other VPSes on the same host that do "we do not know what, but something" at the same time your VPS fire .....

........ and that should all be dealt with by a host environment that is configured not to optimize performance, but to optimize profit.

Stated differently, it is a recipe for havoc.

Again, one does not have control.......... one does not even have insight into what happens on the host level.

In short, my whole point (at least one of them) was that host server overloads can always occur and are likely to occur ..... the hoster wants profit.

Moreover, the hosting provider cannot simply afford to use a "sufficiently big" system to sell VPSes at standard VPS prices - it is not cost effective.

Sure, I do understand the advantages of the VPS in general, but "scalability" is not one of them : that is in the unique domain of the cloud based VMs.

The added value of snapshots is something that I do understand, but I do not know any VPS provider that offers sufficient space for free and were snapshots can really add value to the Plesk based backup infrastructure or - even better - a simple rsync based backup / HA infrastructure on two dedi servers.

Now you mention that........... can you check which tasks are running (or rather, "were running") at the time the updates failed?

If you find some snapshot or backup process running at the same time, then that can also be a simple explanation ........

Kind regards.....

 

[Andrea Bampi]

Now you mention that........... can you check which tasks are running (or rather, "were running") at the time the updates failed?

If you find some snapshot or backup process running at the same time, then that can also be a simple explanation ........

I checked the provider-level automatic backup/snapshot schedules as well.

They are not running anywhere near the failed Plesk update window (~06:31–06:32), and they are also staggered across the (U24) VPSs. For example:

server 1: ~11:48 / 23:47
server 2: ~10:19 / 22:18
server 3: ~11:54 / 23:53
So I think we can rule out my own automatic snapshots/backups as a concurrent workload during the failed update.

Of course I cannot see workload generated by other VPSs on the physical host, so host-level contention remains impossible for me to verify directly.

I'm waiting for the next autoupdate to check the servers' behaviour

 

[trialotto]

@Andrea Bampi

This

I'm waiting for the next autoupdate to check the servers' behaviour

is a good idea, but keep in mind that if Plesk patches some bugs / issues, that you might not see anything in particular in the logs.

That is the way it works, to my regrets.

 

[tessa67]

Hi,

We need data from the affected boxes – otherwise we're just guessing...

Quick recap of where we're at, and what's missing to actually pin this down.

What we know for sure:

• On at least two Ubuntu 24.04.5 VPS, the Plesk installer got killed with SIGTERM during/right after the report-update step.
• The timing is millisecond-close: systemd stops run-plesk-task-*.service, and <1 ms later the installer logs SIGTERM / Error: Interrupted by user.
• The actual Plesk upgrade completes fine – only the finishing step gets cut off, the failure flag stays behind, and PUM blocks.
• Plesk couldn't reproduce it on their test instances.

What we don't know – and this is where we need data:

Whether systemd tears down the cgroup because the main process (the wrapper) exits while the installer is still running as a child (ExitType=main), or whether ExitType=cgroup is already set and the stop comes from somewhere else entirely. Without that info, everything else is speculation – including my own ExitType theory.

What I'd need from an affected box (ideally during a running auto-update, otherwise right after):

1. The task unit's config:

systemctl show run-plesk-task-*.service -p ExitType -p MainPID -p ControlGroup -p Type -p KillMode

Key question: is ExitType=main or cgroup? And is MainPID the wrapper or the installer?

2. Cgroup contents during the run:

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

Does the installer (autoinstaller/pum) show up as a child in the same cgroup?

3. Who triggered the stop?

journalctl -o short-precise --since "<start-1min>" --until "<stop+1min>"

Anything interesting: systemctl calls (reload/stop/restart) coming from the task unit, and whether a timeout, a reload, or a wrapper exit happens right before.

4. Process tree at stop time (if reproducible):

ps -eo pid,ppid,pgid,sid,cmd --forest | grep -E "plesk|autoinstaller|pum|systemctl"

This tells us whether the installer is a direct child of the wrapper and which session/process group it's in.

5. systemd version and distro (for context, not as a blame claim):

systemctl --version
lsb_release -a

6. Whether the wrapper intentionally backgrounds the installer – if findable, the task wrapper contents or unit definition:

systemctl cat run-plesk-task-*.service

Why this matters:
If ExitType=main and the installer sits as a child in that cgroup, we've got a concrete, testable mechanism – and a real lead for Plesk (switch the unit to ExitType=cgroup, or have the wrapper properly wait for the installer). If ExitType is already cgroup, the theory is dead and we go hunting for whatever fires the stop (reload cascade, timeout, external trigger).

Please drop the outputs (trimmed to the relevant lines is fine) from one of the affected boxes. Without that data we're just going in circles – and "interrupted update" as an explanation doesn't help anyone who's now nervous about the next auto-update.

Regards
Tessa