Process Slice Manager — assign php-fpm, Dovecot & Exim SMTP processes to per-user cgroups

21

I wonder if the script will be compatible with Debian 13?

22

4141280 ivan 1003 PHP-FPM /system.slice/php7.4-fpm.service FAIL

When running psm-monitor.sh, I see an error like this on some processes.
I turned on the debug log, but I don’t see anything suspicious.

23

Mail monitoring does not start yet.

You have to do the same service dovecot restart

24

actly right — that FAIL is the 2-second poll window, not a real error. php-fpm’s process manager (dynamic/ondemand) respawns workers constantly; a freshly spawned worker still lives in /system.slice/php7.4-fpm.service until the daemon’s next poll cycle (default poll_interval = 2) moves it into user-1003.slice. The monitor samples every 1 s, so it routinely catches a worker inside that window and — wrongly — colored it red.

The monitor is fixed (28d055d). It now checks whether the daemon is actually running, and a process that is still in a system slice while the daemon is active is shown as PENDING (yellow) instead of FAIL (red):

PID      USER   UID    SERVICE          CGROUP                                        STATUS
4141280  ivan   1003   PHP-FPM          /system.slice/php7.4-fpm.service              PENDING
4141281  ivan   1003   PHP-FPM          /user.slice/user-1003.slice                   OK

FAIL (red) is now reserved for the real problem — the daemon is down and nothing is going to move the process. You can verify that case with systemctl status process-slice-manager.

You’ll still see a few yellow PENDING rows under load — that’s the expected cost of the 2 s polling tradeoff (lower CPU, up-to-2 s reaction time). If you want it to disappear faster, lower the interval:

poll_interval = 1

then systemctl restart process-slice-manager. Just know every halving doubles the per-cycle /proc scan cost, so 2 s is the sensible default.

To get the new monitor: sudo bash install.sh (reinstalls psm-monitor.sh too).

25

It seems to work. Put the server on production. I will monitor how it works.

It would also be cool to somehow limit the load on mysql.
But I use remote database servers connected to the panel.

26

I noticed that when the user loads the server and falls under the limits, the file manager in the panel simply stops working correctly. This is very bad indeed.

2026-08-06T20:02:48.792345+02:00 de sshd[3606735]: pam_unix(sshd:session): session opened for user aneth(uid=1046) by (uid=0)
2026-08-06T20:02:48.799472+02:00 de systemd-logind[604]: New session 399908 of user aneth.
2026-08-06T20:02:48.847181+02:00 de systemd-logind[604]: Session 399908 logged out. Waiting for processes to exit.
2026-08-06T20:02:48.847345+02:00 de systemd-logind[604]: Removed session 399908.
2026-08-06T20:02:58.846364+02:00 de sudo: hestiaweb : PWD=/usr/local/hestia/web/fm/dist ; USER=root ; COMMAND=/usr/local/hestia/bin/v-list-user aneth json
2026-08-06T20:02:58.846537+02:00 de sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
2026-08-06T20:02:58.870188+02:00 de sudo: pam_unix(sudo:session): session closed for user root
2026-08-06T20:02:58.876090+02:00 de sudo: hestiaweb : PWD=/usr/local/hestia/web/fm/dist ; USER=root ; COMMAND=/usr/local/hestia/bin/v-list-user aneth json
2026-08-06T20:02:58.876233+02:00 de sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
2026-08-06T20:02:58.898986+02:00 de sudo: pam_unix(sudo:session): session closed for user root
2026-08-06T20:03:01.599060+02:00 de CRON[3609745]: pam_unix(cron:session): session opened for user hestiaweb(uid=1000) by (uid=0)

When I open the file manager, it just freezes. It’s started working really badly. Perhaps the script is restricting the wrong things.

27

I think there is no need to limit ssh/sftp sessions. Otherwise, everything does not work correctly. Fix it.

28

ound it and fixed.

pam_systemd places interactive SSH/SFTP sessions in user.slice/user-<uid>.slice/session-*.scope. Since HestiaCP and this daemon apply cpu/memory limits (and memory.oom.group) to the whole user-<uid>.slice, when the user’s PHP-FPM drives the slice against its limits the kernel throttles — and with memory.oom.group even kills — the entire slice, taking the user’s SSH/SFTP session down with it. That’s why file transfers broke exactly while the user was falling under the limits.

Fix (commits 52aad76 + e5d6c66, tests 68/68):

  • new exempt_ssh_sftp = true option (on by default; also settable via PSM_EXEMPT_SSH_SFTP) in /etc/process-slice-manager.conf,
  • the daemon now relocates the session’s processes into a dedicated leaf scope user.slice/psm-<uid>-session-<id> that carries no per-user limits,
  • empty exemption scopes are cleaned up automatically.

Update with: sudo bash install.sh (no config changes needed — it’s on by default).

29

That is, in order not to limit sftp, do I need to add exempt_ssh_sftp = true to the configuration file?

30

No — it’s on by default. You only need to update the daemon: sudo bash install.sh. No config change required.

Adding exempt_ssh_sftp = true is only necessary if you want it to be explicit (or to re-enable it after someone set it to false).

31

Updated the config and set - exempt_ssh_sftp = true

Thanks, I will monitor.

32

2026-08-07T11:09:25.043808+02:00 de systemd-logind[604]: Failed to start session scope session-403514.scope: Transaction for session-403514.scope/start is destructive (user-1022.slice has ‘stop’ job queued, but ‘start’ is included in transaction).
2026-08-07T11:09:25.044097+02:00 de sshd[2453351]: pam_systemd(sshd:session): Failed to create session: Transaction for session-403514.scope/start is destructive (user-1022.slice has ‘stop’ job queued, but ‘start’ is included in transaction).

I also noticed something similar in the logs.

33

Hello.
I understand you’ve made changes to the script and can I update it?