Failed unmounting /tmp
Hallo Debianer,
ich bin gerade dabei, einen PC (HP ProDesk 600) mit Debian10/Buster neu
aufzusetzen. Durch Zufall ist mir beim Shutdown/Reboot folgende Meldung
aufgefallen:
>Mai 02 01:11:36 hpd umount[27323]: umount: /tmp: target is busy.
>Mai 02 01:11:36 hpd systemd[1]: tmp.mount: Mount process exited, code=exited, status=32/n/a
>Mai 02 01:11:36 hpd systemd[1]: Failed unmounting /tmp.
Gemäß /etc/fstab handelt es sich um folgenden Mountpoint:
> tmpfs /tmp tmpfs mode=1777,size=75% 0 0
Klar, wenn auf Daten in /tmp noch zugegriffen wird, dann misslingt ein
unmount. Beim Shutdown/Reboot sollten aber alle wesentlichen Dienste und
Programme beendet sein.
Als nächstes konnte ich die Fehler-Meldung bei einem Minimal-System (ohne
graphische Oberfläche) reproduzieren. Nach dem Booten gab es in /tmp nur
die folgenden 4 Verzeichnis, die allerdings keine Einträge enthielten):
>drwxrwxrwt 2 root root 40 02.05.2021 15:27:33 .ICE-unix
>drwxrwxrwt 2 root root 40 02.05.2021 15:27:33 .Test-unix
>drwxrwxrwt 2 root root 40 02.05.2021 15:27:33 .X11-unix
>drwxrwxrwt 2 root root 40 02.05.2021 15:27:33 .XIM-unix
Auch bei diesem Minimal-System erscheint beim Shutdown/Reboot die obige
Fehler-Meldung.
Bei einem Debian9/Stretch erscheint diese Fehler-Meldung trotz identischer
Definition von /tmp nicht. Was ist also bei Buster anders als bei Stretch?
Klar, die Version von systemd (Stretch: 232, Buster: 241). Das Handling
vom Shutdown/Reboot läuft in Buster offensichtlich anders ab als in
Stretch. Buster sollte mittlerweile eigentlich gut "abgehangen" sein und
solche Fehler nicht mehr produzieren.
Google brachte folgendes zu Tage: einige Beiträge vom Sommer/Herbst 2020
berichteten ebenfalls von dieser Fehler-Meldung, allerdings bezogen die
sich auf die Verzeichnisse /var und /home. Bei den Log-Auszügen war aber
zu erkennen, dass /tmp auch betroffen war. Lösungen habe ich keine
gefunden.
Fragen:
- Hat das auch schon jemand von euch beobachtet?
- Wenn ja, gibt es Abhilfe?
Einen schönen Abend noch.
Dieter
Reply to: