[gelöst] Probleme mit ReDirect /var/log nach tmpfs

[TomL]

Moin

Ganz zufällig habe ich heute bemerkt, dass meine varlog-Service-Unit nix gescheites (um nicht Mist zu sagen) macht .... und seit Stunden komme ich nicht dahinter, warum das so ist Der Job ist eigentlich nicht sonderlich kompliziert und schnell erklärt: ein Script soll in der Boot-Phase /var/log auf ein HD-Verzeichnis mounten, und zwar bevor das Journal läuft.

Verkürzt auf den wichtigen Kern sieht das Script wie folgt aus:

Code: Alles auswählen

NewVarLogDir="/media/var/$HOSTNAME/log"

case $action in
    start)
        if [ -z "$(grep /var/log /proc/mounts)" ]; then                         # already mounted?
           [ -d /var/TrueLogDir ] || mkdir -p /var/TrueLogDir
           chmod 755 /var/TrueLogDir; chown root:root /var/TrueLogDir
           mount --bind /var/log /var/TrueLogDir

           mount --bind $NewVarLogDir /var/log
           chmod 755 /var/log; chown root:root /var/log

           cp -Rpu /var/TrueLogDir /var/log >/dev/null 2>&1
        fi
    ;;
exit 0

1. retten des originalen /var/log via bind nach /var/TrueLogDir, um später drauf zugreifen zu können, oder auch zur Kontrolle
2. über-mounten von /var/log durch Harddisk-Dir
3. kopieren des "geretteten" Inhaltes von /var/log auf das neue Harddisk->/var/log

Gestartet wird das Script via Service-Unit:

Code: Alles auswählen

[Unit]
Description=Start/stop logfile saving, redirect to HardDisk or tmpfs
Before=systemd-journald-dev-log.socket umount.target shutdown.target
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
KillMode=process
RemainAfterExit=yes
ExecStart=/usr/local/bin/varlog start
ExecStop=/usr/local/bin/varlog stop

[Install]
WantedBy=multi-user.target

Das Script wird korrekt gestartet, die mounts/binds passieren mit richtigem Ergebnis, /var/log kommt sogar auf der Harddisk an.... nur ist es leider das falsche /var/log. Denn systemd-journald hat sich (vermutlich wegen meines Eingriffs) entschieden, das Journal kurzerhand an anderer Stelle anzulegen, mit dem Erfolg, dass ich ne Leiche auf die HD verschoben habe.

Code: Alles auswählen

journalctl --header | grep "File Path\|state" -i
File Path: /run/log/journal/078b3b81f451482fbdd572b3b015e2e5/system.journal
State: ONLINE
File Path: /var/log/journal/078b3b81f451482fbdd572b3b015e2e5/system.journal
State: OFFLINE

Warum das ganze überhaupt....?... weil ich gerne die SDC vor unnötigen Schreibzugriffen schützen möchte. Hat jemand ne Idee, wegen welcher Ursachen mein Script und Journald hier scheitern?

Interessant ist noch dieser Effekt, zur Laufzeit (bei diesen falschen Gegebenheiten) ein Restart des Journals....

Code: Alles auswählen

systemctl restart systemd-journald

journalctl --header | grep "File Path\|state" -i
File Path: /var/log/journal/078b3b81f451482fbdd572b3b015e2e5/system.journal
State: ONLINE

[smutbert]

kennst du ramlog?
http://www.tremende.com/ramlog/

(zum abkupfern oder direkt verwenden - kenne es aber nur vom cubietruck von wheezy also noch ohne systemd)

[TomL]

Moin

Jetzt habe ich doch tatsächlich ein paar Tage gebraucht, um ein -eigentlich ziemlich kleines- Problem zu lösen.... und ich muss gestehen, nach dieser Zeit nun doch ein wenig mehr Verständnis für die unzähligen "negativen Freundschaften" bezüglich systemd zu haben. Meine bisherige "Zuneigung" hat jetzt einige Prüfungen hinter sich, bei denen ich mehr als einmal fast verzweifelt bin... an mir, aber auch an systemd. Ich habe jetzt ne Vorstellung davon, wie die Situation zu Anfang gewesen sein könnte, als die Jessie noch nicht die Jessie war, sondern noch Testing hieß und das Monster systemd auf die User losgelassen wurde.... und als das Web noch nicht die heutigen ausführlichen Dokumentationen und unzählige Lösungsalternativen zum Nachschlagen enthielt.

Nachwievor denke ich aber trotzdem, dass systemd wirklich eine grossartige Kiste ist.... aber systemd ist auch eine Kiste mit grossartigen Überraschungen... an denen man nicht zwangsläufig immer Freude hat. Das, was möglich ist, ist phänomenal, aber phänomenal sind auch die Probleme oder Effekte, wenn man möglicherweise einem (eigenen) falschen Gedanken folgt.... oder wie man früher sagte, auf dem Holzweg ist.

kennst du ramlog?

Nee, kannte ich nicht. Ich habs mir runtergeladen und in den Code reingesehen... und dann schnell aufgegeben. Sich da einzuarbeiten, um letzten Endes dann doch nur ne Lösung für sysvinit aus dem Jahr 2010 zu haben, war mir zu aufwendig. Ich habe mich dann entschieden, eine Lösungen mit aktuellen Mitteln zu bekommen, und habe sie auch gefunden. Und wie so oft steckte der Teufel im Detail..... ein Detail was es allerdings notwendig machte, mehrere Aspekte losgelöst vom Problem zu betrachten. das also im Großen Ganzen zu sehen.

2 Probleme bestanden. Als erstes fand der Start nicht direkt nach dem Boot statt, so wie es jetzt hier ist, sondern viel später, und zwar nach basic.target.

Code: Alles auswählen

systemd-analyze plot >~/Uploads/$HOSTNAME.svg

http://www.directupload.net/file/d/4359/y9wvqf2s_jpg

Und als zweites hatte ich ein "asynchrones" Problem, was ich aber erst mal verstehen musste.... und was dazu geführt hat, dass journald in /run/log gewerkelt hat und alle anderen Prozesse im (eigentlich ordentlich) eingerichteten tmpfs->/var/log ihre Logs angelegt haben.

Code: Alles auswählen

systemd-analyze dot 'varlog.service' | dot -Tjpg -o ~/Uploads/varlog-service.jpg

http://www.directupload.net/file/d/4359/qsz5a5l4_jpg

Code: Alles auswählen

systemd-analyze dot 'umount.target' | dot -Tjpg -o ~/Uploads/umount-target.jpg

http://www.directupload.net/file/d/4359/ptr4ogwj_jpg

Von den von systemd zur Verfügunggestellten Analyse- und Diagnose-Tools bin ich jedenfalls echt beeindruckt. Das ist wirklich klasse, wenn man da erst einmal durchgeblickt hat. Aber egal, diese Baustelle ist erst mal gelöst.

Code: Alles auswählen

journalctl --header | grep "File Path\|state" -i

Code: Alles auswählen

File Path: /var/log/journal/440a68c6f28d3e287c6b6c7b554a9684/user-1001.journal
State: ONLINE
File Path: /var/log/journal/440a68c6f28d3e287c6b6c7b554a9684/system.journal
State: OFFLINE
File Path: /var/log/journal/440a68c6f28d3e287c6b6c7b554a9684/system@0005331ea3b86e22-74890cc25fcd45c9.journal~
State: OFFLINE