Systemd Vs. Vmin Admin Users

SYSTEM INFORMATION
OS type and version Ubuntu 20.04
Webmin version 2.001
Virtualmin version 7.2-1-Pro
Related packages Systemd 245

Hi all,

Does anyone know why systemd only kills the user slices of Virtialmin virtual server admins?

First I got this error message for almost all my Vmin admin users (corresponding id’s):

user@1078.service     loaded failed failed User Manager for UID 1078

So from there I restarted a service

# systemctl status user@1078
● user@1078.service - User Manager for UID 1078
     Loaded: loaded (/lib/systemd/system/user@.service; static; vendor p>
    Drop-In: /usr/lib/systemd/system/user@.service.d
             └─timeout.conf
     Active: active (running) since Wed 2022-10-12 13:57:46 CST; 3s ago
       Docs: man:user@.service(5)
   Main PID: 3323694 (systemd)
     Status: "Startup finished in 241ms."
      Tasks: 6
     Memory: 6.6M
     CGroup: /user.slice/user-1078.slice/user@1078.service
             ├─dbus.service
             │ └─3323708 /usr/bin/dbus-daemon --session --address=system>
             ├─init.scope
             │ ├─3323694 /lib/systemd/systemd --user
             │ └─3323700 (sd-pam)
             └─pulseaudio.service
               └─3323705 /usr/bin/pulseaudio --daemonize=no --log-targe

And I ran # killsnoop-bpfcc -p 3323694 in order to determine is killing the prcoess:

TIME      PID    COMM             SIG  TPID   RESULT
14:01:22  3323694 systemd          15   3323708 0
14:01:22  3323694 systemd          18   3323708 0

In essence there seems to be something about Vmin admin users running php apps (wordpress, roundcube, & phpmyadmin) that Systemd doesn’t like… and therefore kills the process.

The process functioning properly it appears as follows:

● user@1078.service - User Manager for UID 1078
     Loaded: loaded (/lib/systemd/system/user@.service; static; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/system/user@.service.d
             └─timeout.conf
     Active: active (running) since Wed 2022-10-12 14:37:58 CST; 11s ago
       Docs: man:user@.service(5)
   Main PID: 3337802 (systemd)
     Status: "Startup finished in 244ms."
      Tasks: 6
     Memory: 6.7M
     CGroup: /user.slice/user-1078.slice/user@1078.service
             ├─dbus.service
             │ └─3337816 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
             ├─init.scope
             │ ├─3337802 /lib/systemd/systemd --user
             │ └─3337808 (sd-pam)
             └─pulseaudio.service
               └─3337813 /usr/bin/pulseaudio --daemonize=no --log-target=journal

Oct 12 14:37:58 admin.example.com systemd[3337802]: Listening on D-Bus User Message Bus Socket.
Oct 12 14:37:58 admin.example.com systemd[3337802]: Reached target Sockets.
Oct 12 14:37:58 admin.example.com systemd[3337802]: Reached target Basic System.
Oct 12 14:37:58 admin.example.com systemd[1]: Started User Manager for UID 1078.
Oct 12 14:37:58 admin.example.com systemd[3337802]: Starting Sound Service...
Oct 12 14:37:58 admin.example.com systemd[3337802]: Started D-Bus User Message Bus.
Oct 12 14:37:58 admin.example.com dbus-daemon[3337816]: [session uid=1078 pid=3337816] AppArmor D-Bus mediation is enabled
Oct 12 14:37:58 admin.example.com systemd[3337802]: Started Sound Service.
Oct 12 14:37:58 admin.example.com systemd[3337802]: Reached target Main User Target.
Oct 12 14:37:58 admin.example.com systemd[3337802]: Startup finished in 244ms.

NOTE:
Most of my Vmin admin users have existed for months on the server without this issue happening. Only recently, have I begun adding php applications, which seem to have to pissing off Systemd.

Anyone have an ideas on how to Systemd and Vmin playing together nicely?

User slices spawn and disappear as needed, and they don’t necessarily run forever. You don’t need to “start” them.

If your processes are being killed it’s almost certainly because you don’t have enough memory.

On my test machine… I would agree with you… but my prod server isn’t even close to pushing memory limits:

The problem seems periphery, in nature… just find it odd…