Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Failed unmounting /tmp
87 views
Skip to first unread message
Dieter Rohlfing
May 3, 2021, 1:10:02 PM5/3/21
to
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
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
Rolf Reintjes
May 3, 2021, 1:50:02 PM5/3/21
to
Hallo,
On 03.05.21 19:07, Dieter Rohlfing wrote:
> Gemäß /etc/fstab handelt es sich um folgenden Mountpoint:
>
>> tmpfs /tmp tmpfs mode=1777,size=75% 0 0
Bei meinem Buster auf einem Thinkpad R61i gibt es diesen Mountpoint in
der fstab nicht.
Hast du den selber angelegt oder das bei der Installation irgendwie
machen lassen?
Rolf
On 03.05.21 19:07, Dieter Rohlfing wrote:
> Gemäß /etc/fstab handelt es sich um folgenden Mountpoint:
>
>> tmpfs /tmp tmpfs mode=1777,size=75% 0 0
der fstab nicht.
Hast du den selber angelegt oder das bei der Installation irgendwie
machen lassen?
Rolf
Rolf Reintjes
May 3, 2021, 4:50:02 PM5/3/21
to
Hallo,
On 03.05.21 22:40, Dieter Rohlfing wrote:
> Am Mon, 3 May 2021 19:28:06 +0200
> schrieb Rolf Reintjes <lists...@reintjes.nrw>:
> Den Eintrag "tmpfs /tmp tmpfs mode=1777,size=75% 0 0" habe ich selbst nach
> der Installation in die /etc/fstab eingefügt.
Und warum macht man sowas?
Rolf
On 03.05.21 22:40, Dieter Rohlfing wrote:
> Am Mon, 3 May 2021 19:28:06 +0200
> schrieb Rolf Reintjes <lists...@reintjes.nrw>:
> der Installation in die /etc/fstab eingefügt.
Und warum macht man sowas?
Rolf
Dieter Rohlfing
May 3, 2021, 4:50:02 PM5/3/21
to
Am Mon, 3 May 2021 19:28:06 +0200
schrieb Rolf Reintjes <lists...@reintjes.nrw>:
schrieb Rolf Reintjes <lists...@reintjes.nrw>:
Den Eintrag "tmpfs /tmp tmpfs mode=1777,size=75% 0 0" habe ich selbst nach
der Installation in die /etc/fstab eingefügt.
Dieter
der Installation in die /etc/fstab eingefügt.
Dirk Paul Finkeldey
May 3, 2021, 5:00:03 PM5/3/21
to
Am 03.05.21 um 22:42 schrieb Rolf Reintjes:
Gute Frage, das macht man doch mittels systemd.
Es gibt Beispiele dafür, weiß jetzt aus den Kopf nicht wo diese zu
finden sind.
Gruß
Dirk
Es gibt Beispiele dafür, weiß jetzt aus den Kopf nicht wo diese zu
finden sind.
Gruß
Dirk
Christian Knoke
May 4, 2021, 5:00:03 AM5/4/21
to
Christoph Schmees schrieb am 04. Mai um 10:01 Uhr:
> >>> On 03.05.21 19:07, Dieter Rohlfing wrote:
> >>>> Gemäß /etc/fstab handelt es sich um folgenden Mountpoint:
> >>>>
> >>>>> tmpfs /tmp tmpfs mode=1777,size=75% 0 0
> Gib mal in die Suchmaschine deiner Wahl etwas ein wie "Linux SSD".
/tmp ist bei mir schon seit 10 Jahren im RAM, auch mit ähnlichem Eintrag.
Das Problem (wenn es denn eines ist, der Shutdown wird ja erreicht) ist
wohl, dass systemd seit irgendwann einen besonderen Eintrag hierfür
benötigt (welchen?).
Gruß
Christian
> Christoph
--
http://cknoke.de
> >>> On 03.05.21 19:07, Dieter Rohlfing wrote:
> >>>> Gemäß /etc/fstab handelt es sich um folgenden Mountpoint:
> >>>>
> >>>>> tmpfs /tmp tmpfs mode=1777,size=75% 0 0
> >> Den Eintrag "tmpfs /tmp tmpfs mode=1777,size=75% 0 0" habe ich selbst
> >> nach der Installation in die /etc/fstab eingefügt.
> >
> > Und warum macht man sowas?
> das gehört zu den Tipps, wie man seine SSD schonen kann.
> >> nach der Installation in die /etc/fstab eingefügt.
> >
> > Und warum macht man sowas?
> Gib mal in die Suchmaschine deiner Wahl etwas ein wie "Linux SSD".
/tmp ist bei mir schon seit 10 Jahren im RAM, auch mit ähnlichem Eintrag.
Das Problem (wenn es denn eines ist, der Shutdown wird ja erreicht) ist
wohl, dass systemd seit irgendwann einen besonderen Eintrag hierfür
benötigt (welchen?).
Gruß
Christian
> Christoph
--
http://cknoke.de
Christian Kroll
May 4, 2021, 5:30:03 AM5/4/21
to
hier (Bullseye) wird dies ohne Eintrag in der "/etc/fstab" mittels
"systemd" gehandelt:
systemctl start|stop|status tmp.mount
Vor "systemd" wurde das wohl mit dem Eintrag "RAMTMP=yes" in der Datei
"/etc/default/tmpfs" erledigt. Die Datei ist hier noch vorhanden, wird
aber wohl von "systemd" ignoriert.
Gruß
Christian
--
adte - Automations- und Datentechnik
Inh. Christian Kroll
Edith-Stein-Str. 39
59387 Ascheberg
UstID DE228738750
Tel.: 02599-740952
Mail: ch.k...@adte.de
Web : https://www.adte.de
Dieter Rohlfing
May 4, 2021, 12:50:03 PM5/4/21
to
Am Mon, 3 May 2021 22:42:55 +0200
schrieb Rolf Reintjes <lists...@reintjes.nrw>:
>> Den Eintrag "tmpfs /tmp tmpfs mode=1777,size=75% 0 0" habe ich selbst nach
>> der Installation in die /etc/fstab eingefügt.
>
>Und warum macht man sowas?
Entlastung des Root-Device.
Im Falle einer Festplatte: Verringerung der Zugriffe -> Erhöhung des Tempos
Im Falle einer SSD: Schonung der SSD, weniger Wearing
In beiden Fällen: keine Bereinigung erforderlich, da volatiler Speicher.
Dieter
schrieb Rolf Reintjes <lists...@reintjes.nrw>:
>> Den Eintrag "tmpfs /tmp tmpfs mode=1777,size=75% 0 0" habe ich selbst nach
>> der Installation in die /etc/fstab eingefügt.
>
>Und warum macht man sowas?
Im Falle einer Festplatte: Verringerung der Zugriffe -> Erhöhung des Tempos
Im Falle einer SSD: Schonung der SSD, weniger Wearing
In beiden Fällen: keine Bereinigung erforderlich, da volatiler Speicher.
Dieter
Dieter Rohlfing
May 4, 2021, 12:50:03 PM5/4/21
to
Am Tue, 04 May 2021 11:16:09 +0200
schrieb Christian Kroll <ch.k...@adte.de>:
>hier (Bullseye) wird dies ohne Eintrag in der "/etc/fstab" mittels
>"systemd" gehandelt:
>
>systemctl start|stop|status tmp.mount
Unter Jessie, Stretch und Buster wurde bzw. wird tmp.mount aus
der /etc/fstab generiert (siehe man systemd-fstab-generator), sofern ein
entsprechender Eintrag in /etc/fstab existiert.
Wenn tmp.mount in Bullseye ohne entsprechendem Eintrag in /etc/fstab
existiert, dann wäre das neu. Ich werde mal testen, was in Buster
passiert, wenn ich den Eintrag in /etc/fstab weglasse.
Dieter
schrieb Christian Kroll <ch.k...@adte.de>:
>hier (Bullseye) wird dies ohne Eintrag in der "/etc/fstab" mittels
>"systemd" gehandelt:
>
>systemctl start|stop|status tmp.mount
der /etc/fstab generiert (siehe man systemd-fstab-generator), sofern ein
entsprechender Eintrag in /etc/fstab existiert.
Wenn tmp.mount in Bullseye ohne entsprechendem Eintrag in /etc/fstab
existiert, dann wäre das neu. Ich werde mal testen, was in Buster
passiert, wenn ich den Eintrag in /etc/fstab weglasse.
Dieter
Dieter Rohlfing
May 4, 2021, 12:50:03 PM5/4/21
to
Am Mon, 3 May 2021 22:57:30 +0200
schrieb Dirk Paul Finkeldey <dirk.fi...@ewetel.net>:
>Gute Frage, das macht man doch mittels systemd.
Was macht man mittels systemd? Das Einfügen der Zeile in /etc/fstab? Oder
meintest Du was anderes?
Dieter
schrieb Dirk Paul Finkeldey <dirk.fi...@ewetel.net>:
>Gute Frage, das macht man doch mittels systemd.
meintest Du was anderes?
Dieter
Dieter Rohlfing
May 4, 2021, 12:50:04 PM5/4/21
to
Am Tue, 4 May 2021 10:44:40 +0200
schrieb Christian Knoke <chr...@cknoke.de>:
>Das Problem (wenn es denn eines ist, der Shutdown wird ja erreicht) ist
>wohl, dass systemd seit irgendwann einen besonderen Eintrag hierfür
>benötigt (welchen?).
Um welchen Eintrag handelt es sich und wo wird er gemacht?
Dieter
schrieb Christian Knoke <chr...@cknoke.de>:
>Das Problem (wenn es denn eines ist, der Shutdown wird ja erreicht) ist
>wohl, dass systemd seit irgendwann einen besonderen Eintrag hierfür
>benötigt (welchen?).
Dieter
Helge Reimer
May 4, 2021, 1:20:03 PM5/4/21
to
Am Dienstag, 4. Mai 2021, 11:16:09 CEST schrieb Christian Kroll:
> hier (Bullseye) wird dies ohne Eintrag in der "/etc/fstab" mittels
> "systemd" gehandelt:
>
> systemctl start|stop|status tmp.mount
Die Einheit 'tmp.mount' scheint aber standardmässig nicht verfügbar zu sein.
> hier (Bullseye) wird dies ohne Eintrag in der "/etc/fstab" mittels
> "systemd" gehandelt:
>
> systemctl start|stop|status tmp.mount
Man muss erst einen Symlink von '/usr/share/systemd/tmp.mount' nach '/etc/
systemd/system/' erstellen.
Dann kann man das ganze aktivieren.
# systemctl enable tmp.mount
$ systemctl status tmp.mount
● tmp.mount - Temporary Directory (/tmp)
Loaded: loaded (/etc/systemd/system/tmp.mount; enabled; vendor preset:
enabled)
Active: active (mounted) since Tue 2021-05-04 15:47:54 CEST; 3h 21min ago
Where: /tmp
What: tmpfs
Docs: https://systemd.io/TEMPORARY_DIRECTORIES
man:file-hierarchy(7)
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
Tasks: 0 (limit: 19089)
Memory: 60.0K
CPU: 1ms
CGroup: /system.slice/tmp.mount
--
Gruß
Helge
Dirk Paul Finkeldey
May 4, 2021, 3:40:03 PM5/4/21
to
Am 04.05.21 um 18:16 schrieb Dieter Rohlfing:
Unter /etc/fstab habe ich keinen mountpoint für /tmp, wozu auch?
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda3 during installation
UUID=aea610a2-8fff-4f1f-b590-11acf186b868 / xfs
relatime 0 0
# swap was on /dev/sda2 during installation
UUID=0d73fe5d-8ad3-420a-bad4-3f7550eb0a4c none swap
sw 0 0
#UUID=308c6b52-89b3-48c0-a74c-fc3d8e170a8f none swap
sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Das erledigt @tmp.mount in /etc/systemd/system.
Habe Debian Stretch 9.13
Gruß
Dirk
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda3 during installation
UUID=aea610a2-8fff-4f1f-b590-11acf186b868 / xfs
relatime 0 0
# swap was on /dev/sda2 during installation
UUID=0d73fe5d-8ad3-420a-bad4-3f7550eb0a4c none swap
sw 0 0
#UUID=308c6b52-89b3-48c0-a74c-fc3d8e170a8f none swap
sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Das erledigt @tmp.mount in /etc/systemd/system.
Habe Debian Stretch 9.13
Gruß
Dirk
Helge Reimer
May 4, 2021, 3:50:02 PM5/4/21
to
Am Dienstag, 4. Mai 2021, 21:31:14 CEST schrieb Dirk Paul Finkeldey:
> Unter /etc/fstab habe ich keinen mountpoint für /tmp, wozu auch?
...
> Unter /etc/fstab habe ich keinen mountpoint für /tmp, wozu auch?
>/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Und ich habe keinen fürs CDRom, wozu auch?
--
Gruß
Helge
Dieter Rohlfing
May 4, 2021, 5:10:03 PM5/4/21
to
Am Tue, 4 May 2021 21:31:14 +0200
findet man folgendes:
> Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details).
> In general, configuring mount points through /etc/fstab is the preferred approach.
Man kann es so machen wie Du, aber es ist nicht the preferred approach.
Dieter
>Das erledigt @tmp.mount in /etc/systemd/system.
Unter https://www.freedesktop.org/software/systemd/man/systemd.mount.html
findet man folgendes:
> Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details).
> In general, configuring mount points through /etc/fstab is the preferred approach.
Man kann es so machen wie Du, aber es ist nicht the preferred approach.
Dieter
Dieter Rohlfing
May 4, 2021, 5:20:03 PM5/4/21
to
Am Tue, 04 May 2021 19:12:23 +0200
schrieb Helge Reimer <hrn...@onlinehome.de>:
>Man muss erst einen Symlink von '/usr/share/systemd/tmp.mount' nach '/etc/
>systemd/system/' erstellen.
Ich habe mir (unter Buster) die Datei /usr/share/systemd/tmp.mount nach
/etc/systemd/system kopiert und dafür den Eintrag in /etc/fstab gelöscht.
Doch auch mit dieser Unit kommt beim Shutdown/Reboot die Fehler-Meldung
"Failed unmounting /tmp".
Dieter
schrieb Helge Reimer <hrn...@onlinehome.de>:
>Man muss erst einen Symlink von '/usr/share/systemd/tmp.mount' nach '/etc/
>systemd/system/' erstellen.
/etc/systemd/system kopiert und dafür den Eintrag in /etc/fstab gelöscht.
Doch auch mit dieser Unit kommt beim Shutdown/Reboot die Fehler-Meldung
"Failed unmounting /tmp".
Dieter
Jochen Spieker
May 5, 2021, 3:50:03 PM5/5/21
to
Dieter Rohlfing:
> schrieb Rolf Reintjes <lists...@reintjes.nrw>:
durch neue Hardware ersetzt. Da war auch eine SSD drin, eine Intel X25-M
(80GB!) der ersten Stunde, gekauft im Juni 2009. Die lief erst mehrere
Jahre in meinem Laptop und dann noch viel länger 24/7 in dem besagten
Rechner. Das war root-fs, /home, /var und so weiter. Ich habe nichts
getan, um sie zu schonen.
Ich habe sie leider nicht mehr im Zugriff, sie kriegt jetzt ihr
Gnadenbrot in der Playstation 3, die ich alle Jubeljahre mal einschalte.
Aber laut SMART hatte die immer noch >90% ihrer Lebenszeit vor sich.
Kann gut sein, dass die Dinger heute stärker auf Kante genäht sind. Mir
ist aber in all den Jahren noch keine SSD ausgefallen -- bis auf die
NVME-Variante, die ich jetzt als Ersatz für die X25-M bestellt hatte.
Die ist mir ärgerlicherweise nach wenigen Tagen komplett verstorben. Das
war aber mit Sicherheit kein Problem der Überlastung.
(Nach meiner persönlichen Statistik versterben überhaupt keine
Datenträger mehr, nicht mal die Festplatten. Das sage ich jetzt aber
lieber nicht zu laut.)
J.
--
I cannot comprehend the idea of chemical and biological weapons.
[Agree] [Disagree]
<http://archive.slowlydownward.com/NODATA/data_enter2.html>
> schrieb Rolf Reintjes <lists...@reintjes.nrw>:
>
> >Und warum macht man sowas?
>
> Entlastung des Root-Device.
> Im Falle einer Festplatte: Verringerung der Zugriffe -> Erhöhung des Tempos
> Im Falle einer SSD: Schonung der SSD, weniger Wearing
Haha, SSD schonen! :-D Ich habe kürzlich meinen ollen Server im Keller
> >Und warum macht man sowas?
>
> Entlastung des Root-Device.
> Im Falle einer Festplatte: Verringerung der Zugriffe -> Erhöhung des Tempos
> Im Falle einer SSD: Schonung der SSD, weniger Wearing
durch neue Hardware ersetzt. Da war auch eine SSD drin, eine Intel X25-M
(80GB!) der ersten Stunde, gekauft im Juni 2009. Die lief erst mehrere
Jahre in meinem Laptop und dann noch viel länger 24/7 in dem besagten
Rechner. Das war root-fs, /home, /var und so weiter. Ich habe nichts
getan, um sie zu schonen.
Ich habe sie leider nicht mehr im Zugriff, sie kriegt jetzt ihr
Gnadenbrot in der Playstation 3, die ich alle Jubeljahre mal einschalte.
Aber laut SMART hatte die immer noch >90% ihrer Lebenszeit vor sich.
Kann gut sein, dass die Dinger heute stärker auf Kante genäht sind. Mir
ist aber in all den Jahren noch keine SSD ausgefallen -- bis auf die
NVME-Variante, die ich jetzt als Ersatz für die X25-M bestellt hatte.
Die ist mir ärgerlicherweise nach wenigen Tagen komplett verstorben. Das
war aber mit Sicherheit kein Problem der Überlastung.
(Nach meiner persönlichen Statistik versterben überhaupt keine
Datenträger mehr, nicht mal die Festplatten. Das sage ich jetzt aber
lieber nicht zu laut.)
J.
--
I cannot comprehend the idea of chemical and biological weapons.
[Agree] [Disagree]
<http://archive.slowlydownward.com/NODATA/data_enter2.html>
Gerhard Wolfstieg
May 22, 2021, 11:50:03 AM5/22/21
to
Hallo Helge, hallo zusammen!
On Tue, 04 May 2021 19:12:23 +0200
Helge Reimer <hrn...@onlinehome.de> schrieb:
> Die Einheit 'tmp.mount' scheint aber standardmässig nicht verfügbar zu sein.
> Man muss erst einen Symlink von '/usr/share/systemd/tmp.mount' nach '/etc/
> systemd/system/' erstellen.
> Dann kann man das ganze aktivieren.
>
> # systemctl enable tmp.mount
>
> $ systemctl status tmp.mount
> ● tmp.mount - Temporary Directory (/tmp)
> Loaded: loaded (/etc/systemd/system/tmp.mount; enabled; vendor preset:
> enabled)
> Active: active (mounted) since Tue 2021-05-04 15:47:54 CEST; 3h 21min ago
Dies hier:
> Where: /tmp
veranlaßt mich zur Rückfrage: ist das dann wirklich im RAM?
> What: tmpfs
> Docs: https://systemd.io/TEMPORARY_DIRECTORIES
> man:file-hierarchy(7)
> https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
> Tasks: 0 (limit: 19089)
> Memory: 60.0K
> CPU: 1ms
> CGroup: /system.slice/tmp.mount
Grüße, Gerhard
On Tue, 04 May 2021 19:12:23 +0200
Helge Reimer <hrn...@onlinehome.de> schrieb:
> Die Einheit 'tmp.mount' scheint aber standardmässig nicht verfügbar zu sein.
> Man muss erst einen Symlink von '/usr/share/systemd/tmp.mount' nach '/etc/
> systemd/system/' erstellen.
> Dann kann man das ganze aktivieren.
>
> # systemctl enable tmp.mount
>
> $ systemctl status tmp.mount
> ● tmp.mount - Temporary Directory (/tmp)
> Loaded: loaded (/etc/systemd/system/tmp.mount; enabled; vendor preset:
> enabled)
> Active: active (mounted) since Tue 2021-05-04 15:47:54 CEST; 3h 21min ago
> Where: /tmp
veranlaßt mich zur Rückfrage: ist das dann wirklich im RAM?
> What: tmpfs
> Docs: https://systemd.io/TEMPORARY_DIRECTORIES
> man:file-hierarchy(7)
> https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
> Tasks: 0 (limit: 19089)
> Memory: 60.0K
> CPU: 1ms
> CGroup: /system.slice/tmp.mount
Stefan Krusche
May 23, 2021, 5:40:03 AM5/23/21
to
Am Samstag, 22. Mai 2021 schrieb Gerhard Wolfstieg:
> Hallo Helge, hallo zusammen!
>
> On Tue, 04 May 2021 19:12:23 +0200
>
> Helge Reimer <hrn...@onlinehome.de> schrieb:
> > Die Einheit 'tmp.mount' scheint aber standardmässig nicht verfügbar
> > zu sein. Man muss erst einen Symlink von
> > '/usr/share/systemd/tmp.mount' nach '/etc/ systemd/system/'
> > erstellen.
> > Dann kann man das ganze aktivieren.
> >
> > # systemctl enable tmp.mount
> >
> > $ systemctl status tmp.mount
> > ● tmp.mount - Temporary Directory (/tmp)
> > Loaded: loaded (/etc/systemd/system/tmp.mount; enabled; vendor
> > preset: enabled)
> > Active: active (mounted) since Tue 2021-05-04 15:47:54 CEST;
> > 3h 21min ago
>
> Dies hier:
> > Where: /tmp
>
> veranlaßt mich zur Rückfrage: ist das dann wirklich im RAM?
>
> > What: tmpfs
^^^^^^^^^^^
> Hallo Helge, hallo zusammen!
>
> On Tue, 04 May 2021 19:12:23 +0200
>
> Helge Reimer <hrn...@onlinehome.de> schrieb:
> > Die Einheit 'tmp.mount' scheint aber standardmässig nicht verfügbar
> > zu sein. Man muss erst einen Symlink von
> > '/usr/share/systemd/tmp.mount' nach '/etc/ systemd/system/'
> > erstellen.
> > Dann kann man das ganze aktivieren.
> >
> > # systemctl enable tmp.mount
> >
> > $ systemctl status tmp.mount
> > ● tmp.mount - Temporary Directory (/tmp)
> > Loaded: loaded (/etc/systemd/system/tmp.mount; enabled; vendor
> > preset: enabled)
> > Active: active (mounted) since Tue 2021-05-04 15:47:54 CEST;
> > 3h 21min ago
>
> Dies hier:
> > Where: /tmp
>
> veranlaßt mich zur Rückfrage: ist das dann wirklich im RAM?
>
> > What: tmpfs
Hallo Gerhard, demzufolge wohl ja.
HTH, Stefan
Gerhard Wolfstieg
May 23, 2021, 11:20:03 AM5/23/21
to
On Sun, 23 May 2021 11:39:42 +0200
Stefan Krusche <li...@stefan-krusche.de> schrieb:
> > Dies hier:
> > > Where: /tmp
> >
> > veranlaßt mich zur Rückfrage: ist das dann wirklich im RAM?
> >
> > > What: tmpfs
> ^^^^^^^^^^^
> Hallo Gerhard, demzufolge wohl ja.
>
> HTH, Stefan
Danke! Gruß, Gerhard
Stefan Krusche <li...@stefan-krusche.de> schrieb:
> > Dies hier:
> > > Where: /tmp
> >
> > veranlaßt mich zur Rückfrage: ist das dann wirklich im RAM?
> >
> > > What: tmpfs
> ^^^^^^^^^^^
> Hallo Gerhard, demzufolge wohl ja.
>
> HTH, Stefan
0 new messages