ubuntuusers.de

Hallo zusammen,

ich untersuche ein reproduzierbares Problem auf mehreren identischen virtuellen Servern mit Ubuntu 24.04.5 LTS. Nach der täglichen Plesk-Wartung sammeln sich sehr viele verwaiste systemd-Sitzungs-Scopes für den Benutzer popuser an.

Ich würde gerne herausfinden, ob ein Problem mit systemd-logind, PAM oder der OpenVZ-Umgebung dahinterstecken könnte.

## Systemumgebung

- Ubuntu 24.04.5 LTS
- systemd 255.4-1ubuntu8.18
- Plesk Obsidian 18.0.81.4
- OpenVZ-Virtualserver
- Kernel: 5.4.0
- Maildienste: Postfix und Dovecot

Alle betroffenen Server sind identisch konfiguriert und zeigen dasselbe Verhalten.

Beobachtetes Verhalten

Während der täglichen Plesk-Wartungsaufgabe ExecuteSpamtrain werden sehr viele kurzlebige Sitzungen für popuser erzeugt.

Das Plesk-Skript /usr/local/psa/admin/sbin/spamtrain verwendet wiederholt Aufrufe wie:

su - popuser -c "/usr/bin/sa-learn ..."

Diese Aufrufe dienen dem Spam- und Ham-Lernen sowie der Synchronisierung von SpamAssassin.

Im Systemjournal erscheinen zahlreiche Meldungen über session-c*.scope-Units sowie PAM-Meldungen zum Öffnen und Schließen von Sitzungen. Ein Teil der Sitzungen bleibt anschließend im Zustand closing; außerdem sammeln sich verwaiste beziehungsweise als abandoned angezeigte Scopes an.

Auf einem Server hatten sich ungefähr 1.641 verwaiste Scopes angesammelt. Nach Überprüfung, dass die betreffenden Scopes keine laufenden Tasks mehr hatten (TasksCurrent=0), konnten sie kontrolliert beendet werden. Postfix und Dovecot blieben dabei aktiv.

Ein anschließender Neustart des Servers beseitigte den Altbestand vollständig. Direkt nach dem Neustart waren keine popuser-Sitzungen, keine verwaisten Scopes und keine entsprechenden transienten Scope-Dateien mehr vorhanden.

Weitere Beobachtungen

• systemd-logind ist aktiv und weist keine Neustarts auf.

• In /etc/pam.d/common-session ist pam_systemd.so als optionales Sitzungsmodul eingebunden.

• Das Problem tritt auf mehreren identisch konfigurierten Servern auf.

• Die zeitliche Beobachtung deutet auf einen Zusammenhang mit ExecuteSpamtrain hin. Die eigentliche Ursache ist jedoch noch nicht geklärt.

Meine Fragen

1. Ist ein ähnliches Verhalten von systemd-logind mit zahlreichen verwaisten session-c*.scope-Units unter Ubuntu 24.04 und systemd 255 bekannt?

2. Kann die Kombination aus OpenVZ, dem Kernel 5.4.0 und systemd 255 bei kurzlebigen su-Sitzungen zu diesem Verhalten führen?

3. Gibt es bekannte Probleme mit PAM beziehungsweise pam_systemd.so, die solche zurückbleibenden Sitzungen verursachen können?

4. Welche zusätzlichen Protokolle oder Diagnoseschritte wären sinnvoll, um die Ursache eindeutig einzugrenzen?

Ich möchte ausdrücklich **nicht vorschnell PAM-Konfigurationen verändern oder systemd-Sitzungsdienste deaktivieren**, da es sich um produktive Mailserver handelt.

Vielen Dank für Hinweise und Erfahrungen!

AndreasKr schrieb:

... sehr viele verwaiste systemd-Sitzungs-Scopes für den Benutzer popuser an.

BTW: Ist das Lingering für den popuser bereits aktiviert? Wie sind z. Zt. die Ausgaben von:

1
2

loginctl show-user popuser --property=Linger
ls -la /var/lib/systemd/linger

?
Wenn nicht, dann aktiviere das Lingering für den popuser:

sudo loginctl enable-linger popuser

und teste damit (... auf verwaiste systemd-Sitzungen).

Danke für den Hinweis!

Lingering war für popuser bisher nicht aktiviert. Das Verzeichnis /var/lib/systemd/linger/ war leer.

Ich habe es jetzt testweise mit

loginctl enable-linger popuser

aktiviert. Die Kontrolle zeigt Linger=yes.

Ich werde nach dem nächsten täglichen Plesk-Wartungslauf prüfen, ob weiterhin viele verwaiste systemd-Sitzungen entstehen, und hier über das Ergebnis berichten.

Vielen Dank für den Tipp!

AndreasKr schrieb:

... aktiviert. Die Kontrolle zeigt Linger=yes.

OK. Du musst das Lingering für den popuser jetzt (evtl.) noch "scharfstellen", damit es auch wirksam ist. Das kannst Du u. a., auch mit einem simulierten login machen (... für den popuser). Z. B.:

su - popuser -c "exit"

Hallo zusammen,

leider hat der gestern vorgeschlagene Lösungsansatz keinen Erfolg gebracht. Heute Morgen waren auf meinem Server erneut zahlreiche verwaiste session-c*.scope-Einheiten für popuser vorhanden.

Aktuell sind es 111 Scopes, bei denen TasksCurrent=0 gemeldet wird. Auch der Versuch, diese leeren Scopes mit

1

systemctl stop

zu bereinigen, hat leider nicht den gewünschten Erfolg gebracht.

Das Problem besteht also weiterhin. Hat jemand eine Idee, wie sich die Ursache dauerhaft beheben lässt?

Vielen Dank!