Dotaz: systemd: provede "mount -a" po nějakém čase

[Jendа]

• Všiml jsem si, že na jednom stroji nemám namountované /tmp jako tmpfs, i když bych to tak kvůli iracionálnímu šetření SSD chtěl. Proto jsem přidal do /etc/fstab následující:

  tmpfs /tmp tmpfs defaults,size=12G,nofail 0 0

  Dále jsem to neřešil (musel bych přesouvat stávající obsah /tmp do nového), protože se do konce září plánoval reboot toho stroje. Řekl jsem si, že po novém bootu se to namountuje jako tmpfs a tím bude vyřešeno.
• Po nějaké době jsem instaloval bezpečnostní upgrady nesouvisejících balíčků. Během toho došlo (z nějakého důvodu 2x) k reloadu systemd, protože jeden balíček obsahoval systemd unitu a měl tak nejspíš v post-install hoocích reload:

  2023-09-17T21:44:05.712191+00:00 radar-meziklasi systemd[1]: Reloading.
  2023-09-17T21:44:06.042402+00:00 radar-meziklasi systemd[1]: Reloading.

• Během této události to z fstabu vygenerovalo mount unitu pro to nové /tmp, s očekávaným obsahem.

  # stat /run/systemd/generator/tmp.mount
  [...]
  Birth: 2023-09-17 21:44:06.205356369 +0000

  Stahují se mračna, ale zatím žijeme.
• Po 25 minutách se to z ničeho nic rozhodlo, že to tu unitu aktivuje a namountuje:

  2023-09-17T22:09:00.007085+00:00 radar-meziklasi systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
  2023-09-17T22:09:00.046507+00:00 radar-meziklasi systemd[1]: Mounting tmp.mount - /tmp...
  2023-09-17T22:09:00.049198+00:00 radar-meziklasi systemd[1]: Mounted tmp.mount - /tmp.

  Nikde jsem nenašel žádnou zmínku co se stalo v 22:09, proč se to zrovna najednou rozhodlo mountovat. Žádné relevantní řádky v journalu mezi 21:44 a 22:09 nejsou.
• Následně popadaly služby, které měly v /tmp nějaká data a najednou jim „zmizela“.

Moje dotazy:

• Co jsem zase udělal špatně? Jak se to mělo udělat správně?
• Čím bylo způsobeno to náhlé namountování po nějaké době?

Jedná se o aktuální Debian stable.

Odpovědi

[Jendа]

Všiml jsem si, že se tou dobou (každou hodinu v :09) spouští phpsessionclean pomocí systemd timeru. Tato služba má v service souboru PrivateTmp=true.

# systemctl cat phpsessionclean
# /lib/systemd/system/phpsessionclean.service
[Unit]
Description=Clean php session files

[Service]
Type=oneshot
ExecStart=/usr/lib/php/sessionclean
ProtectHome=true
ProtectSystem=true
PrivateTmp=true

Moje druhá otázka by tedy mohla být zodpovězena tím, že systemd zjistil, že chce přistoupit k /tmp (vytvořit tam třeba nějaké dočasné privátní adresáře), zjistil, že na to je potřeba ho namountovat (když už tam má mount unitu), ale namountované „není“ (systém běžel s originálním /tmp adresářem přímo na rootfs), tak ho namountoval.

[X]

Bude to tak. systemd.exec:

Similarly, units with PrivateTmp= enabled automatically get mount unit dependencies for all mounts required to access /tmp/ and /var/tmp/. They will also gain an automatic After= dependency on systemd-tmpfiles-setup.service(8).

[Peter Golis]

Asi bolo dobré po takejto zmene fstab aj pregenerovať mount unity, a rovno reštartnúť služby používajúce daný prípojný bod. Holt, je to dynamické.

[ewew]

Podľa mňa to vyzerá, na to, že tam máš dva krát /tmp. Predchádzajúcu definíciu /tmp musíš vymazať. To znamená celý obsah pôvôdného /tmp. Systemd počas bootu generuje jednotlivé mount súbory. Keďže tam máš zrejme ešte súborový systém /tmp, tak ten detekuje a mountne obidva. Preto tam máš hlásenie o tom, že /tmp nie je prázdny.

Myslím, že to nedáš do poriadku bez rebootu alebo cez kexec.

V mojom prípade keď som dal do tmpfs /tmp, tak som zrušil daný lvm s tmp. Neviem presne okolnosti ako som zistil duálny mount. Možno som videl hlášku o tom, že to má dve mount definície alebo som bol dôsledný a upratal som po sebe.

[Jendа]

Podľa mňa to vyzerá, na to, že tam máš dva krát /tmp. Predchádzajúcu definíciu /tmp musíš vymazať.

Nemám tam 2x /tmp. Předtím tam /tmp vůbec nebylo, používalo se /tmp přímo fyzicky na rootfs.

Preto tam máš hlásenie o tom, že /tmp nie je prázdny.

Ne, to hlášení je tam proto, že v běžícím systému, kde /tmp samozřejmě není prázdný, to přes tento neprázdný /tmp začalo mountovat nový /tmp.

(problém teď už samozřejmě žádný není, vyřešil se restartem dotčených služeb a pak raději i rebootem stroje)