Directory /var/run - tmpfs oder persistent?

Rosendoktor

Well-Known Member
Hi,

ich hatte bisher auf allen FreeBSD Installationen das Verzeichnis /var/run als tmpfs in der /etc/fstab gemountet. Jetzt hab' ich aber einen Dienst (postgrey) am Laufen der offensichtlich erwartet dass dieses Verzeichnis persistent ist. Es wird bei der Installation des Pakets ein Verzeichnis /var/run/postgrey angelegt, welches nach einem Neustart des Servers (falls tmpfs verwendet wird) nicht mehr da ist, und dann startet der Dienst nicht.

Frage, sollte /var/run wirklich persistent sein, oder gibt es vielleicht einen Standardweg, hier Verzeichnisse/Dateien vor dem Start eines Dienstes zu erzeugen?

Danke & Gruß,

Robert
 
Theoretisch muss /var/run nicht über Reboots hinweg persistent sein. In der Doku steht dazu: "system information files describing various info about systemsince it was booted". In der Praxis sind aber einige Services zu blöd, sich die benötigten Verzeichnisstrukturen selbst anzulegen oder erwarten, dass dort gespeicherte Daten über Reboots hinweg erhalten bleiben. Daher würde ich es nicht auf ein tmpfs legen.
 
wie wäre es mit einem Link, den man bei einem Systemstart dann natürlich immer erst legen müsste?
Umgekehrt hatte ich das jedenfalls schon gemacht, um einige Dateien ins tempfs zu schieben, so dass ich sie eben durch einen Neustart auch los sein würde. Und bei einem FreeBSD auf einem USB-Stick habe ich so /var auch auf eine Festplatte gelegt, die zwar erst vom System des Sticks eingebunden werden muss, was aber der Standard-Fall ist. Ich wollte Dinge, wie die Logs, die zT viel schreiben, nicht auf dem Stick landen lassen. Das hat beides sehr gut funktioniert und wäre vielleicht auch ein machbarer Kompromiss für dich.
 
Ich habe /var/run als tmpfs und lege wegen der Problematik einige Verzeichnisse aus der /etc/rc.local an:

Code:
/bin/mkdir -p /var/run/tor
/bin/mkdir -p /var/run/dhclient
/usr/sbin/chown -R _tor:_tor /var/run/tor
/bin/mkdir -p /var/run/squid
/usr/sbin/chown -R squid:squid /var/run/squid
 
Ich habe /var/run als tmpfs und lege wegen der Problematik einige Verzeichnisse aus der /etc/rc.local an:

Code:
/bin/mkdir -p /var/run/tor
/bin/mkdir -p /var/run/dhclient
/usr/sbin/chown -R _tor:_tor /var/run/tor
/bin/mkdir -p /var/run/squid
/usr/sbin/chown -R squid:squid /var/run/squid

Ha, squid! Stimmt, squid ist auch so ein Kandidat... hatte ich völlig vergessen. Der legt das aber nicht mal während der Installation an, postgrey schon (was aber nichts nützt bei tmpfs...).

Für squid hatte ich mir damals ein rc.d Skript geschrieben das das macht, und das vor dem Starten von squid (BEFORE = squid) ausgeführt wird. Hab das jetzt einfach mit dem für postgrey Nötigen ergänzt (und eben BEFORE = squid postgrey).

Bei der rc.local war ich mir damals nicht sicher wann genau die beim Booten ausgeführt wird.

Danke Euch für die Tips!

Robert
 
Also ich würde kein tmpfs für /var/run nehmen. Kamikaze's Ausschnitt aus seiner /etc/rc.local reicht mir da schon als Argument aus. Und letztens ist ja auch MariaDB hinzugekommen, das unbedingt sein eigenes Verzeichnis unter /var/run haben möchte und sonst die Arbeit verweigert. Dann wird die von Hand zu pflegende Liste in /etc/rc.local immer länger...
 
Dann wird die von Hand zu pflegende Liste in /etc/rc.local immer länger...

Das ist schon richtig. Nur, auch ohne tmpfs muss man korrigieren, der postgrey legt z.B. ein Unix Socket unter /var/run/postgrey an, auf dieses kann postfix aber nicht zugreifen wegen falscher Rechte auf dem Verzeichnis. Wer weiß ob das nach einem Upgrade nicht wieder kaputt geht. Unsauber ist es so oder so. Meiner Meinung nach sind das ganz einfach Bugs, und der Workaround das manuell zu machen ist okay und lässt sich durchaus sauber pflegen.
 
Ich finde /var/run auf einem tmpfs zu haben ist völlig richtig. Jedesmal, wenn ein service damit nicht klar kommt, schreibe ich einen bug report (z.B. squid, dhclient, wenn möglich mit patch). IMHO muss man solche Fehler in den service scripts nicht hinnehmen. Das workaround mit einem script in rc.local ist auch eine praktikable Lösung. Das Argument, die Liste würde ja immer länger, ist m.E. nicht so stark: wie viele services laufen denn normalerweise auf einer Maschine? Maximal 100, davon erzeugen die meisten ihre benögtigten Verzeichnisse. Macht max. 10-20 Einträge. Das ist doch noch gut überschaubar.
EDIT Richtig gut wäre das workaround von @Kamikaze mit einer mtree Datei.
 
Zuletzt bearbeitet:
Zurück
Oben