Question Plesk backend often not accessible when installing updates manually

[brother4]

Server operating system version

Ubuntu Server 22.04.5 LTS

Plesk version and microupdate number

Plesk Obsidian 18.0.71 (Web Host Edition)

Hello, when I install a Plesk update manually and the installation is completed successfully, I can access my websites normally. But when I try to log in to the Plesk backend, I usually get an error message when I call up the login page and it is recommended to use the repair kit. If you then restart the server once, it works again immediately. Do you have any idea what this has to do with?

 

[brother4]

What I then see is that the sw-engine.service is not running (in the repair kit). Does this take longer after an update until it starts again? Even hours? This has not yet been observed with automatic updates.

 

[brother4]

sw-engine.service: Main process exited, code=exited, status=219/CGROUP
sw-engine.service: Failed with result 'exit-code'.
restart counter is at 209

 

[brother4]

Analysis Commands​

cat /proc/sys/kernel/pid_max​

→ Shows the maximum number of process IDs (PIDs) available system-wide.

• Output: 4194304
• This is a very high limit, meaning the system allows up to 4.19 million simultaneous tasks.
• It’s a kernel-level setting and not a practical limit for individual services.

---

systemctl show --property=DefaultTasksMax​

→ Displays the default maximum number of tasks (processes/threads) allowed per systemd service.

• Output: DefaultTasksMax=1843
• This limit is 15% of an internal systemd reference value, not of pid_max.
• It restricts how many processes each systemd-managed service may spawn by default.

---

systemctl show sw-engine.service | grep TasksMax​

→ Displays the actual task limit (TasksMax) applied to the sw-engine.service.

• Output: TasksMax=1843
• This value is inherited from the DefaultTasksMax above.
• It's likely too low for a service like sw-engine, which can spawn many PHP worker threads, especially during updates or load.

---

Probable Fix / Customization​

mkdir -p /etc/systemd/system/sw-engine.service.d​

→ Creates a directory for systemd override configuration specific to sw-engine.service.

• -p ensures all parent folders are created if they don't exist.

---

echo -e "[Service]\nTasksMax=4096" > /etc/systemd/system/sw-engine.service.d/override.conf​

→ Writes an override file that sets a new TasksMax limit for the service to 4096.

• This tells systemd to allow up to 4096 processes/threads for sw-engine.

---

systemctl daemon-reexec​

→ Re-executes the systemd process itself (clears internal state).

• Needed when changes affect system-wide behavior or PID handling.

---

systemctl daemon-reload​

→ Reloads systemd unit files and recognizes override changes.

• Essential after creating or editing unit configuration files.

---

systemctl restart sw-engine​

→ Restarts the sw-engine service to apply the new TasksMax setting.

---

systemctl show sw-engine.service | grep TasksMax​

→ Verifies that the new task limit is active.

• Expected Output: TasksMax=4096

---

✅ Summary​

This entire block of commands:

• Analyzes current limits that may cause service startup failures (like status=219/CGROUP).
• Applies a clean, persistent fix by overriding the default task limit for sw-engine.
• Ensures Plesk services have enough headroom during updates or high load.

 

[brother4]

But I'm not entirely sure whether this is the solution to the problem. As there was a real loop when restarting the service tonight.

Ps. Too bad you can only edit here for 4 minutes, that's a bit short.

journalctl -u sw-engine -n 100 --no-pager

Jul 09 04:08:51 example.com systemd[1]: Failed to start Startup script for Panel sw-engine.
Jul 09 04:08:56 example.com systemd[1]: sw-engine.service: Scheduled restart job, restart counter is at 209.
Jul 09 04:08:56 example.com systemd[1]: Stopped Startup script for Panel sw-engine.
Jul 09 04:08:57 example.com systemd[1]: Starting Startup script for Panel sw-engine...
Jul 09 04:08:57 example.com systemd[1]: sw-engine.service: Main process exited, code=exited, status=219/CGROUP
Jul 09 04:08:57 example.com systemd[1]: sw-engine.service: Failed with result 'exit-code'.
Jul 09 04:08:57 example.com systemd[1]: Failed to start Startup script for Panel sw-engine.

 

[Bitpalast]

A restart of sw-engine is immediate, there is no wait.

What's shown in /var/log/sw-cp-server/error_log and sw-engine.log at the time of failure?

 

[brother4]

@Bitpalast

/var/log/sw-cp-server/error_log - Many entries of:

2025/07/09 03:50:08 [crit] 4075683#0: *206 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:08 [crit] 4075683#0: *207 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:08 [crit] 4075683#0: *209 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:08 [crit] 4075683#0: *213 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:08 [crit] 4075683#0: *214 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:08 [crit] 4075683#0: *212 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:08 [crit] 4075683#0: *218 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:08 [crit] 4075683#0: *220 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:08 [crit] 4075683#0: *222 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"
2025/07/09 03:50:15 [crit] 4075683#0: *224 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /modules/monitoring/public/index.php/id1234censored/query HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8880"

cat /var/log/sw-cp-server/sw-engine.log (nothing more)

[09-Jul-2025 03:37:33] NOTICE: Terminating ...
[09-Jul-2025 03:37:33] NOTICE: exiting, bye-bye!
[09-Jul-2025 03:37:33] NOTICE: fpm is running, pid 4056871
[09-Jul-2025 03:37:33] NOTICE: ready to handle connections
[09-Jul-2025 03:37:33] NOTICE: systemd monitor interval set to 10000ms
[09-Jul-2025 03:48:12] NOTICE: Terminating ...
[09-Jul-2025 03:48:12] NOTICE: exiting, bye-bye!
[09-Jul-2025 04:11:53] NOTICE: fpm is running, pid 386
[09-Jul-2025 04:11:53] NOTICE: ready to handle connections
[09-Jul-2025 04:11:53] NOTICE: systemd monitor interval set to 10000ms
[09-Jul-2025 13:49:00] NOTICE: Terminating ...
[09-Jul-2025 13:49:00] NOTICE: exiting, bye-bye!
[09-Jul-2025 13:49:01] NOTICE: fpm is running, pid 250138
[09-Jul-2025 13:49:01] NOTICE: ready to handle connections
[09-Jul-2025 13:49:01] NOTICE: systemd monitor interval set to 10000ms

 

[Bitpalast]

The missing socket means that the service isn't running. But that is expected as it is not running. You should find the cause why it is not running. Normally before that situation occurs, another error is logged, telling you WHY the service cannot be started or why it stopped. Have you considered scrolling back into the log to find that point in time where it happens?

 

[brother4]

Unfortunately there is nothing to be found anywhere. These are the first entries from the log. I don't understand it either. But the problem is reproducible after every Plesk update, which I install myself via https://example.com:8447/installer/summary.html.

The other user here had the same error but apparently also no entry about it: Issue - Error 502 when trying to log in

The problem has been occurring since the previous Plesk version Onyx. In the meantime, the server has also been reinstalled for an Ubuntu server update and Plesk has been cleanly installed with Obsidian. So that can't be the reason. Plesk does not find any errors in the repair program.

 

[brother4]

I was just able to reproduce it this way too, so the task limit doesn't seem to be the problem:

systemctl restart sw-engine.service
Job for sw-engine.service failed because the control process exited with error code.
See "systemctl status sw-engine.service" and "journalctl -xeu sw-engine.service" for details.


systemctl status sw-engine.service
● sw-engine.service - Startup script for Panel sw-engine
Loaded: loaded (/lib/systemd/system/sw-engine.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/sw-engine.service.d
└─override.conf
/usr/lib/systemd/system/sw-engine.service.d
└─respawn.conf
Active: activating (auto-restart) (Result: exit-code) since Wed 2025-07-09 20:10:59 CEST; 4s ago
Process: 348276 ExecStart=/usr/sbin/sw-engine-fpm --fpm-config /etc/sw-engine/sw-engine-fpm.conf -c /usr/local/psa/admin/conf/php.ini --nodaemonize --pid /run/sw-engine.pid (code=exited, status=219/CGROUP)
Process: 348277 ExecStopPost=/usr/bin/find /run/lock/lmlib/ -mindepth 1 -delete (code=exited, status=219/CGROUP)
Main PID: 348276 (code=exited, status=219/CGROUP)
Tasks: 3 (limit: 4096)
Memory: 283.3M
CGroup: /system.slice/sw-engine.service


cat /etc/systemd/system/sw-engine.service.d/override.conf
[Service]
TasksMax=4096

After that it worked again on 2 attempts. Is it possible that Plesk sometimes does something in the background and if an update takes place during this time, that it then hangs? Cronjobs or something similar?

 

[Bitpalast]

It's all possible, but it is unlikely that nothing is logged for it.

 

[Sebahat.hadzhi]

@brother4 , please also check /var/log/plesk/installer/autoinstaller3.log for any errors logged.

 

[brother4]

@Sebahat.hadzhi

grep "2025-07-09 0[34]:" /var/log/plesk/install/autoinstaller3.log | grep -Ei "error|failed|warn" | cat
[2025-07-09 03:33:05.541478] Warning: ez_template_suffix is NOT defined in pool/PSA_18.0.70_17122/plesk-18.0.70-ubt22.04-x86_64.inf3
[2025-07-09 03:33:05.568086] Warning: ez_template_suffix is NOT defined in PHP70_17/php70-ubt22.04-x86_64.inf3
[2025-07-09 03:33:05.598493] Warning: ez_template_suffix is NOT defined in pool/PHP_7.1.33_14/php71-ubt22.04-x86_64.inf3
[2025-07-09 03:33:05.627190] Warning: ez_template_suffix is NOT defined in pool/PHP_7.2.34_22/php72-ubt22.04-x86_64.inf3
[2025-07-09 03:33:05.652951] Warning: ez_template_suffix is NOT defined in pool/PHP_7.3.33_13/php73-ubt22.04-x86_64.inf3
...
[2025-07-09 03:33:16.494551] Component plesk/ruby: mode error, installed_buildtime=0, available_buildtime=0
[2025-07-09 03:33:16.496519] Component plesk/drweb: mode error, installed_buildtime=0, available_buildtime=0
[2025-07-09 03:33:16.496576] Component plesk/sophos: mode error, installed_buildtime=0, available_buildtime=0
[2025-07-09 03:33:16.497467] Component plesk/watchdog: mode error, installed_buildtime=0, available_buildtime=0
[2025-07-09 03:33:16.498312] Component plesk/ntp-timesync: mode error, installed_buildtime=0, available_buildtime=0
...
[2025-07-09 03:46:51.701772] Warning: BuildLoader finish with unsuccess.
...
[2025-07-09 04:09:55.221906] Warning: XML answer is already sent (try to send '<?xml version="1.0" encoding="UTF-8" standalone="yes" ?><autoinstaller status="ok" />'
...
[2025-07-09 04:30:10.129228] Warning: ez_template_suffix is NOT defined in pool/WPB_18.0.69_87/sitebuilder-18.0.69-deball-all.inf3
[2025-07-09 03:33:05.541478] Warning: ez_template_suffix is NOT defined in pool/PSA_18.0.70_17122/plesk-18.0.70-ubt22.04-x86_64.inf3
[2025-07-09 03:33:05.568086] Warning: ez_template_suffix is NOT defined in PHP70_17/php70-ubt22.04-x86_64.inf3
[2025-07-09 03:33:05.598493] Warning: ez_template_suffix is NOT defined in pool/PHP_7.1.33_14/php71-ubt22.04-x86_64.inf3
[2025-07-09 03:33:05.627190] Warning: ez_template_suffix is NOT defined in pool/PHP_7.2.34_22/php72-ubt22.04-x86_64.inf3
[2025-07-09 03:33:05.652951] Warning: ez_template_suffix is NOT defined in pool/PHP_7.3.33_13/php73-ubt22.04-x86_64.inf3
...
[2025-07-09 03:33:16.494551] Component plesk/ruby: mode error, installed_buildtime=0, available_buildtime=0
[2025-07-09 03:33:16.496519] Component plesk/drweb: mode error, installed_buildtime=0, available_buildtime=0
[2025-07-09 03:33:16.496576] Component plesk/sophos: mode error, installed_buildtime=0, available_buildtime=0
[2025-07-09 03:33:16.497467] Component plesk/watchdog: mode error, installed_buildtime=0, available_buildtime=0
[2025-07-09 03:33:16.498312] Component plesk/ntp-timesync: mode error, installed_buildtime=0, available_buildtime=0
...
[2025-07-09 03:46:51.701772] Warning: BuildLoader finish with unsuccess.
...
[2025-07-09 04:09:55.221906] Warning: XML answer is already sent (try to send '<?xml version="1.0" encoding="UTF-8" standalone="yes" ?><autoinstaller status="ok" />'
...
[2025-07-09 04:30:10.129228] Warning: ez_template_suffix is NOT defined in pool/WPB_18.0.69_87/sitebuilder-18.0.69-deball-all.inf3

 

[Sebahat.hadzhi]

@brother4 , thank you. Unfortunately, none of the entries helps to identify what the issue could be. It is possible that during the process, the update of sw-engine package wasn't executed properly, hence, resulting in the errors in provided in your initial messages. However, I cannot confirm that for sure. If you observe the same behavior again after a manual update, you can try running plesk repair installation and restarting sw-engine along with sw-cp-server. If that doesn't help it will be best to get in touch with our support team.

 

[brother4]

I have also contacted the host provider about this. And I was probably very correct in my assumption. We suspect that it is due to the very outdated kernel on the host system, which is shared with a modern Ubuntu 22.04 operating system on openvz.

hostnamectl
Virtualization: openvz
Kernel: Linux 5.2.0
Architecture: x86-64

Therefore, there is probably no truly viable option other than to change hosting providers in the future, as the Plesk Edition is no longer free on the new vServer systems and is quite expensive.

 

[trialotto]

I have also contacted the host provider about this. And I was probably very correct in my assumption. We suspect that it is due to the very outdated kernel on the host system, which is shared with a modern Ubuntu 22.04 operating system on openvz.

hostnamectl
Virtualization: openvz
Kernel: Linux 5.2.0
Architecture: x86-64

Therefore, there is probably no truly viable option other than to change hosting providers in the future, as the Plesk Edition is no longer free on the new vServer systems and is quite expensive.

@brother4

It is pretty safe to conclude that it is related to the fact that you are on a virtualized host, but I am not sure whether that makes things impossible.

I think that you should try "updating" from SSH command line, as opposed to the other methods of updating.

Just open two SSH sessions, one for the update and another for monitoring the resource usage - for instance, use the command top.

I think that you will find some irregularities in the resource usage, since the culprit is often that a host system is badly configured - the common symptom thereof is that resource usage goes crazy.

If you find some irregularities in the "update" SSH console, then keep track of the irregularities.


As a final remark, I can only recommend to move to a dedicated server - not that expensive, more fun than a VPS, better for Plesk purposes.


Kind regards....