WP Toolkit causing repeated systemd root session/runtime-dir failures on CloudLinux

Hello,

We are investigating an issue on a CloudLinux 8.10 server running cPanel 136.0.33 and WordPress Toolkit.

At approximately 16:16 on 2026-08-09 (and for some time previous to this), WP Toolkit began generating a large number of very short-lived `sudo` sessions from the `wp-toolkit` user to `root`.

pam_systemd(sudo:session): Failed to create session: Transaction for session-c470.scope/start is destructive (user-0.slice has 'stop' job queued, but 'start' is included in transaction).

These sessions cause systemd to repeatedly create and destroy:

* `user-0.slice`
* `user-runtime-dir@0.service`
* `/run/user/0`
* `session-cXXX.scope`

The relevant journal entries include:

Created slice User Slice of UID 0.
Starting User runtime directory /run/user/0...
Started User runtime directory /run/user/0.
Started Session c476 of user root.
...
Stopping User runtime directory /run/user/0...
Stopped User runtime directory /run/user/0.
Removed slice User Slice of UID 0.

During the WP Toolkit activity, systemd-logind also reports:

Requested transaction contradicts existing jobs:
Transaction for session-c477.scope/start is destructive
(user-0.slice has 'stop' job queued, but 'start' is included in transaction).

systemd-logind[1297]:
Failed to start session scope session-c477.scope:
Transaction for session-c477.scope/start is destructive
(user-0.slice has 'stop' job queued, but 'start' is included in transaction).

pam_systemd(sudo:session):
Failed to create session:
Transaction for session-c477.scope/start is destructive
(user-0.slice has 'stop' job queued, but 'start' is included in transaction).

There is also an instance where `pam_systemd` reports:

pam_systemd(sudo:session):
Failed to stat() runtime directory '/run/user/0':
No such file or directory

pam_systemd(sudo:session):
Not setting $XDG_RUNTIME_DIR, as the directory is not in order.

The WP Toolkit log shows that this occurs while its background task is performing server/environment detection. For example:

wp-toolkit : USER=root ; COMMAND=/bin/test -e /usr/local/psa
wp-toolkit : USER=root ; COMMAND=/bin/test -e /etc/psa
wp-toolkit : USER=root ; COMMAND=/bin/test -e /usr/local/cpanel
wp-toolkit : USER=root ; COMMAND=/bin/cat /usr/local/cpanel/version
wp-toolkit : USER=root ; COMMAND=/bin/sh -c 'readlink /usr/local/cpanel/server.type'
wp-toolkit : USER=root ; COMMAND=/bin/sh -c 'cagefsctl --cagefs-status'

The relevant WP Toolkit task completed successfully:

Starting process for task '19226'
...
Process for task '19226' exited with code '0' and signal 'null'

so this appears to be a systemd/PAM/session lifecycle problem rather than a failed WP Toolkit task.

The PAM configuration contains:

/etc/pam.d/sudo:
session required pam_sulve.so

/etc/pam.d/system-auth:
-session optional pam_systemd.so

/etc/pam.d/password-auth:
-session optional pam_systemd.so

There is no `pam_lve.so` entry in `/etc/pam.d/sudo`; `pam_lve.so` is present for `crond`, `atd`, `su`, and `sshd`.

The `user-runtime-dir@.service` has a CloudLinux drop-in:

/etc/systemd/system/user-runtime-dir@.service.d/kcs_5931241.conf

[Service]
Type=oneshot

The standard unit contains:

[Unit]
StopWhenUnneeded=yes

[Service]
ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start %i
ExecStop=/usr/lib/systemd/systemd-user-runtime-dir stop %i
Type=oneshot
RemainAfterExit=true
Slice=user-%i.slice

user-0.slice likewise has:

[Unit]
StopWhenUnneeded=yes

Interestingly, repeatedly executing `sudo -u root /bin/true` from an interactive root shell did NOT reproduce the problem. Therefore, the issue appears to be specific to the non-root `wp-toolkit` execution environment and/or the way WP Toolkit invokes sudo/background tasks, rather than simply rapid root sudo sessions.

Could you please advise whether this is a known interaction between WP Toolkit, CloudLinux's `pam_sulve`, `pam_systemd`, and systemd user slices/runtime directories?

In particular, we would like to know:

1. Whether `pam_sulve` is expected to interact with `pam_systemd` in this manner for WP Toolkit's sudo operations.
2. Whether the `user-0.slice`/`user-runtime-dir@0.service` transaction conflict is a known CloudLinux/cPanel issue.
3. Whether the `kcs_5931241.conf` drop-in is expected on current CloudLinux/cPanel installations and whether it is relevant.

(CloudLinux-recommended drop-in for the user-runtime-dir@.service race we're seeing. CloudLinux's KB gives that exact filename and path, and says it's intended to address a race involving /run/user/<UID>)

4. Whether there is a recommended cPanel/CloudLinux configuration or update that prevents WP Toolkit's short-lived sudo operations from racing with teardown of `user-0.slice`.

We have not modified the PAM or systemd configuration while investigating this issue.

Thank you.