Question Plesk Obsidian 18.0.81.4 on Ubuntu 24.04/OpenVZ: 1,742 abandoned popuser sessions in systemd-logind

[AndreasKrNE]

Server operating system version

Ubuntu 24.04.5 LTS

Plesk version and microupdate number

Obsidian 18.0.81.4, build 2026/10/21 21:00

System environment

• Plesk: Obsidian 18.0.81.4, build 2026/10/21 21:00
• Operating system: Ubuntu 24.04.5 LTS
• Virtualization: OpenVZ (Virtual Cloud Server)
• Kernel: 5.4.0
• systemd: 255.4-1ubuntu8.18
• libpam-systemd: 255.4-1ubuntu8.18
• D-Bus: 1.14.10-4ubuntu4.1

Problem description​

A large number of orphaned sessions belonging to the system user popuser have accumulated on my Plesk mail server. The current count is 1,742 sessions.

The corresponding systemd scope units are in the abandoned state, while systemd-logind reports the sessions as closing. The original processes no longer exist, and the scopes have no running tasks.

The counts match exactly:

• 1,742 popuser sessions
• 1,742 abandoned scope units
• 1,742 transient scope files under /run/systemd/transient/

systemd-logind is running normally and has not restarted. The entries are not continuously increasing: a 60-second test showed no new scope files. They appear to accumulate during recurring operations instead.

Possible connection with Plesk​

The journal records the daily Plesk maintenance task ExecuteSpamtrain. During this task, short-lived su commands are executed as popuser to train SpamAssassin mailboxes.

The timestamps of newly created scope files coincide with the daily spam-training window. I therefore suspect a connection between ExecuteSpamtrain, the short-lived su sessions, and session cleanup by systemd-logind. However, I have not yet established that spam training is the sole cause.

Impact and tests performed​

• Postfix and Dovecot remain active.
• systemd-logind is active and has not restarted.
• CPU usage by PID 1 and systemd-logind is negligible.
• /run/systemd/transient/ uses approximately 6.9 MB.
• The installed systemd version, 255.4-1ubuntu8.18, is also the candidate version in the configured Ubuntu repositories.

I tested removing one orphaned scope with systemctl stop session-c10009.scope. The session then disappeared from loginctl, the unit reported not-found/inactive, and the counts decreased from 1,742 to 1,741. Postfix and Dovecot remained active. No bulk cleanup has been performed.

Questions for Plesk and the community​

1. Is this issue involving ExecuteSpamtrain and systemd-logind known on Plesk Obsidian 18.0.81.4?
2. Is there a Plesk patch, hotfix, or documented fix for this behavior?
3. Is there a known condition under which the spam-training routine can leave orphaned su sessions?
4. What is the recommended and supported method for cleaning up the accumulated closing sessions and abandoned scopes?
5. Should the root cause be investigated in Plesk, Ubuntu/systemd, or the OpenVZ container environment?

A potentially related report is systemd Issue #37880 – Leaked abandoned logind sessions. The reported symptoms appear similar, although that report concerns a different systemd version.

I would prefer not to modify Plesk maintenance scripts or manually delete transient scope files. I am looking for a safe, supported solution that cleans up the existing entries and prevents them from accumulating again.

Thank you for any advice or suggestions.

 

[AndreasKrNE]

Additional findings: ExecuteSpamtrain and abandoned popuser sessions

Further investigation indicates that Plesk's daily maintenance task ExecuteSpamtrain is associated with the creation of a very large number of short-lived popuser sessions.

The Plesk script /usr/local/psa/admin/sbin/spamtrain uses repeated commands such as su - popuser to execute /usr/bin/sa-learn for spam and ham learning and synchronisation. During the daily maintenance task, the system journal records a large number of corresponding session-c*.scope units and PAM session open/close events.

Approximately 1,641 abandoned session scopes were safely stopped after checking that their TasksCurrent value was zero. Postfix and Dovecot remained active throughout the cleanup.

Afterwards, two popuser sessions still appeared in the closing state. Their associated processes were linked to an active Dovecot IMAP connection, so these sessions were deliberately left untouched.

systemd-logind remained active and showed no restarts. The PAM configuration contains pam_systemd.so as an optional session module.

The evidence suggests an association with ExecuteSpamtrain, but the underlying cause has not yet been established. No Plesk scripts or PAM configuration files have been modified.

Could the Plesk team investigate whether the repeated su - popuser calls during ExecuteSpamtrain can cause abandoned systemd session scopes on Ubuntu 24.04 with systemd 255 in an OpenVZ environment?

Any advice on a permanent fix or a recommended workaround would be appreciated.