Ja (sehr wahrscheinlich): Die Vorgänge liegen zeitlich jeweils im nächtlichen KeyHelp-Lauf (Cron-Sitzung 03:14, systemctl daemon-reload aus cron.service). Den Urheber selbst kann ich im Code nicht nachvollziehen.
Server-Betriebssystem + Version
Debian 13.7 (Trixie), Kernel 6.12.113, Upgrade von Debian 12 im Mai 2026
Eingesetzte Server-Virtualisierung-Technologie
KVM (Contabo VPS)
KeyHelp-Version + Build-Nummer
26.1.1 - Build 3698
Problembeschreibung / Fehlermeldungen
Seit Debian 13 ist /tmp standardmäßig ein tmpfs (tmp.mount). Bei der nächtlichen Wartung (alle zwei Tage zwischen 3 und 4 Uhr) wird /tmp ausgehängt und gleich danach neu als leeres tmpfs eingehängt. Dabei gehen die privaten /tmp-Verzeichnisse (/tmp/systemd-private-*) aller laufenden Dienste mit PrivateTmp=yes verloren (bei uns u. a. dovecot, redis-server, redis-keyhelp, rsyslog, systemd-logind).
Folge: Jedes spätere "systemctl reload" dieser Dienste – und jeder Dienststart in der kurzen Lücke zwischen Aus- und Einhängen – scheitert:
Code: Select all
Oct 23 20:48:03 (doveadm)[224892]: dovecot.service: Failed to set up mount namespacing: /tmp: No such file or directory
Oct 23 20:48:03 systemd[1]: dovecot.service: Control process exited, code=exited, status=226/NAMESPACE
Oct 27 03:14:03 (mandb)[718889]: man-db.service: Failed to set up mount namespacing: /tmp: No such file or directory
Oct 27 03:14:03 systemd[1]: man-db.service: Main process exited, code=exited, status=226/NAMESPACE
Code: Select all
Oct 23 03:14:27 systemd[1]: Reload requested from client PID 133585 ('systemctl') (unit cron.service)...
Oct 23 03:14:28 systemd[1]: Reloading finished in 358 ms.
Oct 23 03:14:28 systemd[1]: Reload requested from client PID 133628 ('systemctl') (unit cron.service)...
Oct 23 03:14:28 systemd[1]: Reloading finished in 279 ms.
Oct 23 03:14:28 systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
Oct 23 03:14:28 systemd[1]: Mounted tmp.mount - Temporary Directory /tmp.
Oct 23 03:14:28 CRON[132955]: pam_unix(cron:session): session closed for user root
Zur gleichen Zeit wird folgende Datei neu geschrieben (zuletzt 27.10.2026 03:14:18):
Code: Select all
/etc/systemd/system/tmp.mount.d/override.conf
[Mount]
Options=mode=1777,strictatime,nosuid,nodev,size=50%,nr_inodes=1m
Erwartetes Ergebnis
- /tmp bleibt im laufenden Betrieb eingehängt, die privaten /tmp-Verzeichnisse laufender Dienste bleiben erhalten, "systemctl reload <dienst>" funktioniert.
- Eine bewusst gesetzte Maskierung von tmp.mount (Debian-Release-Notes trixie, Abschnitt 5.1.6: "systemctl mask tmp.mount" für /tmp auf der Platte) bleibt bestehen.
Tatsächliches Ergebnis
- /tmp wird jede zweite Nacht aus- und wieder eingehängt (leeres tmpfs).
- Danach fehlen alle /tmp/systemd-private-*-Verzeichnisse; reload/Start betroffener Dienste scheitert mit status=226/NAMESPACE, bis der jeweilige Dienst neu gestartet wird.
- Die Maskierung von tmp.mount wird entfernt und override.conf neu geschrieben.
Schritte zur Reproduktion
1. Debian 13 mit KeyHelp, /tmp als tmpfs (Standard).
2. Vorher: ls -d /tmp/systemd-private-* (Verzeichnisse vorhanden).
3. Nächtliches automatisches Paket-Update von KeyHelp abwarten (oder eine Konfigurationsänderung im Panel, die einen Lauf von mastercronjob.php mit daemon-reload auslöst – am 21.10. z. B. nach dem Speichern einer Einstellungsseite beobachtet).
4. Danach: ls -d /tmp/systemd-private-* (keine mehr) und systemctl reload dovecot -> status=226/NAMESPACE.
5. journalctl | grep tmp.mount zeigt "Deactivated successfully" und "Mounted tmp.mount" zur Zeit des KeyHelp-Laufs.
Zusätzliche Informationen
- /etc/fstab enthält keinen Eintrag für /tmp; tmp.mount ist die Debian-Vorgabe (/usr/lib/systemd/system/tmp.mount, "static").
- In den lesbaren Dateien unter /home/keyhelp/www/keyhelp/ kommt "tmp.mount" nicht vor.
- Mögliche Kleinigkeit in override.conf: In systemd-Unit-Dateien leitet ein einzelnes "%" einen Platzhalter (Specifier) ein; die Vorlage von systemd selbst schreibt deshalb "size=50%%".
- Auf einer zweiten Test-Installation (Debian 13, KeyHelp 26.1.1, KVM) trat dasselbe Muster auf (dovecot reload -> 226/NAMESPACE nach einem daemon-reload aus cron.service).
Fragen:
1. Verwaltet KeyHelp tmp.mount bzw. /etc/systemd/system/tmp.mount.d/override.conf bewusst? Wozu dienen die Optionen?
2. Lässt sich das abschalten, oder kann KeyHelp eine Maskierung von tmp.mount respektieren?
3. Falls die Verwaltung gewollt ist: Kann sie so erfolgen, dass ein bereits eingehängtes /tmp nicht aus- und wieder eingehängt wird (z. B. nur bei geänderter override.conf)?
Danke und viele Grüße,
Rainer