FAILED Meldung beim runterfahren von unmount /var

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
TomL
Beiträge: 2804
Registriert: 24.07.2014 10:56:59

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von TomL » 16.02.2017 10:22:39

carlchen hat geschrieben:Das ignorieren dieser Meldung mag vielleicht eine Methode sein, aber ich würde es schon sehr gerne behoben haben.
Ich versuchs noch mal zu erklären..... das ist an dieser Stelle NICHT möglich. Das Journal behandelt das Schreiben von Meldungen vor dem Hintergrund, dass /var/log im Normalfall ein Bestandteil des lokales Filesystems ist und damit fast bis zum Abfall der Stromspannung verfügbar ist. Das sind die allerletzten Zeilen des Journals vor dem Poweroff, die bei lokalem Standort /var deutlich nach dem Unmount der Filesysteme erstellt wurden:

Code: Alles auswählen

Feb 15 22:36:25 thomaspc systemd[1]: Reached target Shutdown.
Feb 15 22:36:25 thomaspc systemd[1]: Reached target Final Step.
Feb 15 22:36:25 thomaspc systemd[1]: Starting Power-Off...
Feb 15 22:36:25 thomaspc systemd[1]: Shutting down.
Feb 15 22:36:25 thomaspc kernel: systemd-shutdow: 31 output lines suppressed due to ratelimiting
Feb 15 22:36:25 thomaspc systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Feb 15 22:36:25 thomaspc systemd-journald[692]: Journal stopped
Bevor also der Strom abgeschaltet wird, müssen jedoch zuerst alle Filesysteme, die nicht "lokales Filesystem" sind, ordentlich beendet bzw. geschlossen bzw. unmounted werden - und dazu gehört jetzt eben hier auch das gemountete "/var". Und natürlich müssen alle offene Dateien des lokalen Filesystems auch geschlossen werden. Die einzige Ausnahme bildet hier eben das Journal, was wirklich solange schreibt, wie es möglich ist.

Insofern hast Du selber jetzt mit dem Verlegen von /var/log auf ein Remote-FS einen Interessen-Konflikt erschafft, der darin besteht 'Schreiben bis zu Ende' auf der einen Seite, gegen 'alles nichtbenötigte sicher Schließen vor dem Shutdown' auf der anderen. Die Besonderheit ist hier das Attritbut "nichtbenötigte", weil Du eine zum Shutdown noch benötige Ressource in den Bereich "nichtbenötigte Ressource" verlegt hast, die eben vorher geschlossen wird.

Wie gesagt, an der Stelle hast Du selber die Fehlermeldung erzeugt und weil sie bekannt und definitiv auch folgerichtig (!) ist, würde ich sie deshalb ignorieren.
MSfree hat geschrieben:Du kannst ja auch mal den journald stoppen, bevor du den Rechner runterfährst:
Das ist ganz sicher etwas, was alle Meldungen verhindert, aber genauso sicher halte ich das auch für die schlechteste Option. Weil damit eben nicht nur diese eine jetzt unerwünschte Meldung verschwindet, sondern wirklich ALLE anderen auch, die vielleicht ab Morgen auf Grund einer Änderung im System bei einem Shutdown neu erscheinen können.

Es gibt genau 2 Lösungen für dieses Problem:
1. /var nicht zu mounten, sondern es im Filesystem belassen
2. Die Fehlermeldung ignorieren, weil der Admin diesen Konflikt vorsätzlich und bewusst herbeigeführt hat.

j.m.2.c.
vg, Thomas

MSfree
Beiträge: 2321
Registriert: 25.09.2007 19:59:30

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von MSfree » 16.02.2017 10:42:36

TomL hat geschrieben:Insofern hast Du selber jetzt mit dem Verlegen von /var/log auf ein Remote-FS einen Interessen-Konflikt erschafft
Das vermute ich auch. Allerdings bieten alle Debianinstaller, die ich bisher gesehen habe, an, /var auf einer eigenen Partition einzurichten. Ich habe zwar schon gelesen, daß man seit Einführung von systemd (also Jessie) keine eigenen /usr-Partition mehr verwenden darf, so ein Hiweis fehlt aber bezüglich der /var-Partition. (zumidest wäre mir das bisher nicht aufgefallen)

Wenn es sich wirklich herausstellt, daß das Log das Problem verursacht, dann wäre das sogar einen Bugreport wert, zumindest insoweit, daß man /var, ähnlich /usr, nicht auf eine eigene Partition legen darf.
Das ist ganz sicher etwas, was alle Meldungen verhindert, aber genauso sicher halte ich das auch für die schlechteste Option.
Ich hatte es auch nur für die Ursachenforschung vorgeschlagen. Wie gesagt, es geht hierbei letztlich nicht darum, eine lästige Meldung zu ignorieren, sondern darum, daß ein sauberes umount verhindert wird. Das Dateisystem ist dadurch immer in einem dirty Zustand, was zumidest einen fsck verursacht und/oder das Zurückspielen des Journals (nicht zu verwechseln mit den Journal von journald), um Dateisystemfehler zu beheben.

Man kann sicherlich durch geeignete Einträge in den .service-Dateien von systemd erreichen, daß der journald gestoppt wird, bevor /var ausgehängt wird. Dadurch gehen dann vielleicht ein paar Meldungen nicht mehr ins Log, das Dateisystem ist aber sauber, was ich für wesentlich wichtiger halte.

TomL
Beiträge: 2804
Registriert: 24.07.2014 10:56:59

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von TomL » 16.02.2017 10:48:41

MSfree hat geschrieben:die ich bisher gesehen habe, an, /var auf einer eigenen Partition einzurichten.
Eine eigene Partition ist ja auch gar kein Problem... als physisches Laufwerk ist die genauso lange verfügbar, wie das Laufwerk des OS. Das ist aber etwas anderes als ein Remote-FS via Netzwerkverbindung... das muss natürlich viel früher ordentlich geschlossen werden. Und genau da besteht der Konflikt.

Aber ein Bug-Report ergibt sich daraus nicht. Was soll denn das Journal mit den Einträgen machen, die gespeichert werden müssten, aber nicht gespeichert werden können, weil der Speicher geschlossen wurde? Ich empfinde das Verhalten als absolut korrekt und ordnungsgemäß. Der hier unerwünschte Effekt ist definitiv hausgemacht.
MSfree hat geschrieben:Man kann sicherlich durch geeignete Einträge in den .service-Dateien von systemd erreichen, daß der journald gestoppt wird, bevor /var ausgehängt wird. Dadurch gehen dann vielleicht ein paar Meldungen nicht mehr ins Log, das Dateisystem ist aber sauber, was ich für wesentlich wichtiger halte.
Noch mal... man muss sich entscheiden... entweder ich will alle Meldungen, so lange es technisch möglich ist, oder ich verzichte auf ggf. wichtige Meldungen, weil ich das Journal viel zu früh stoppe. Eine andere Alternative gibt es nicht. Und ich will auf gar keinen Fall, dass das Journal dann wieder als Fallback direkt auf lokale FS schreiben würde... weil mir das beispielsweise über kurz oder lang meine SD-Card schrotten würde oder vielleicht an anderer Stelle im Shutdown eine Verschlüsselung des FS aushebelt. Das, wie es jetzt gehandhabt wird, ist imho perfekt.
vg, Thomas

MSfree
Beiträge: 2321
Registriert: 25.09.2007 19:59:30

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von MSfree » 16.02.2017 11:51:49

TomL hat geschrieben:Das ist aber etwas anderes als ein Remote-FS via Netzwerkverbindung.
Von Remote war gar keine Rede, /var ist in diesem Fall über /dev/sda7 lokal eingehängt.
ich empfinde das Verhalten als absolut korrekt und ordnungsgemäß.
Es kann nicht korrekt sein, ein Dateisystem schlicht nicht auszuhängen und im dirty Zustand zu belassen und dann den Strom abzuschalten.

Entweder, man verhindert, daß /var auf eine eigene Partition kommt, so daß der Konflikt gar nicht entstehen kann. Oder man würgt den journald vor dem umount ab und akzeptiert, daß die letzten paar Logmeldungen im Nirvana verschwinden, so, wie man es zu SysV-Init-Zeiten mit rsyslogd auch gemacht hat.

Benutzeravatar
carlchen
Beiträge: 493
Registriert: 03.03.2012 05:13:32

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von carlchen » 16.02.2017 12:02:18

Als ich mit Linux begonnen habe, damals schon 2008, hat man mir immer gesagt, das beim herunterfahren sämtlicher Partitionen ein sauberes aushängen wichtig sei. Das sei genauso wichtig für bei einem USB Stick. Beim aushängen einer externen Platte wird ja auch vom System ein Warnhinweis angezeigt, wenn z.B. noch Daten übertragen werden, dann leuchtet bei mir im Xfce Desktop zumindest oben rechts immer ein Fenster auf was sagt "Daten werden noch auf Datenträger geschrieben" oder so ähnlich. Daher verschwindet diese meldung ja auch erst automatisch wenn die Platte wirklich fertig ist.

Mir fiel z.B. auch auf, das meine anderen Partitionen wie /home, /, /tmp etc beim herunterfahren mit einem grünen OK aufleuchten und dahinter steht irgendwas mit:

Code: Alles auswählen

[FAILED] unmount /var
[OK] unmount /home
[OK] unmount /tmp
Irgendwie sowas steht da für nicht einmal 1 Sekunde. Muss ich sonst mal aufnehmen. Deswegen kam mir die Frage auch wieso bei /var das nicht gehen kann.

EDIT: Hier mal ein Screenshot.

Grüße,
Carlchen
Debian GNU/Linux 9.0 Stretch, Xfce 4.12, als 64-Bit 8)

TomL
Beiträge: 2804
Registriert: 24.07.2014 10:56:59

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von TomL » 16.02.2017 12:12:40

MSfree hat geschrieben:Von Remote war gar keine Rede, /var ist in diesem Fall über /dev/sda7 lokal eingehängt.
Uuups... sorry, da hatte ich irgendwas falsch in Erinnerung.... :hail:
carlchen hat geschrieben:Hier mal ein Screenshot.
Du kannst Dir die Meldungen einfach im Terminal ansehen....

Code: Alles auswählen

journalctl -b -1
und dann mit der "Ende"-Taste ans Ende springen.
vg, Thomas

MSfree
Beiträge: 2321
Registriert: 25.09.2007 19:59:30

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von MSfree » 16.02.2017 12:16:34

carlchen hat geschrieben:das beim herunterfahren sämtlicher Partitionen ein sauberes aushängen wichtig sei.
Richtig. Wobei inzwischen die meisten Dateisysteme Journaling beherrschen, so daß sich das saubere Aushängen ein wenig relativiert. Allerdings wird bei unsauberem Shutdown das clean-Flag nicht ins Dateisystem geschrieben, was beim Booten dann einen Dateisystemcheck veranlaßt.
Deswegen kam mir die Frage auch wieso bei /var das nicht gehen kann.
Wie gesagt, der Schuldige ist sehr wahrscheinlich journald, der noch offenen Dateihandles auf dem Dateisystem hält, was ein Aushängen verrhindert.

Achso, um keine Mißverständnisse aufkommen zu lassen. Ein "journaling" Dateisystem hat nichts mit journald zu tun. Hier wird nur der Begriff Journal für zwei unterschiedliche Sachen, dem Intakthalten des Dateisystems, und dem Loggen von Fehlermeldungen, benutzt.

Benutzeravatar
carlchen
Beiträge: 493
Registriert: 03.03.2012 05:13:32

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von carlchen » 16.02.2017 14:42:41

TomL hat geschrieben:journalctl -b -1
Okay, das werde ich heute Abend wenn ich wieder Zuhause bin einmal testen.


@ MSfree, diesen Bug Report habe ich gefunden, vom Januar 2017. Der jenige hatte wohl das gleiche Problem. Leider bin ich nicht so der englischen Sprache mächtig, das ich nur Bruchteile verstehen kann. Aber vielleicht hilft dies ja weiter?

Grüße,
Carlchen
Debian GNU/Linux 9.0 Stretch, Xfce 4.12, als 64-Bit 8)

MSfree
Beiträge: 2321
Registriert: 25.09.2007 19:59:30

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von MSfree » 16.02.2017 15:02:56

carlchen hat geschrieben:@ MSfree, diesen Bug Report habe ich gefunden, vom Januar 2017.
Exakt, der beschreibt ziemlich genau dein Problem.

Dort wird allerdings von einem kosmetischen Problem ausgegangen. Zwar versucht systemd beim Shutdown /var zu früh zu unmounten, was wegen der offenen Logfiles vom journald nicht klappt. Beim endgültige umount, der das root-Dateisystem und alle sonst noch gemounteten Dateisysteme unmountet, wird /var dann doch ausgehängt.

Insofern hätte ich mich geirrt, indem ich annahm, daß /var in einem unabgeschlossenen Zustand verbleibt. Das ist wohl aber laut dem von dir verlinkten Thread nicht der Fall. Daher, Lämpchen auf grün und Meldung einfach ignorieren.

TomL
Beiträge: 2804
Registriert: 24.07.2014 10:56:59

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von TomL » 16.02.2017 15:13:13

In dem Bug-Report steht aber als Reaktion von Bieble und im angehängten Link von Poettering auch nix anderes drin, als ich bisher gesagt habe:
Poettering:
"This is actually expected: we keep journald running till the very end of the system, it's not killed during the normal shutdown phase, but only in the final killing spree. At that time it will continue to write to /var/log/journal.
:::
This specific issue is pretty cosmetic actually, as all you see is the EBUSY error messages during shutdown, but the file system will be unmounted during the final killing spree, so all should be good."


Letztendlich kommts nur darauf an: "This specific issue is pretty cosmetic actually". Man kann speziell hier darüber hinwegsehen. Mich würde an der Stelle nur noch kurz interessieren, was hier der Grund ist, um /var nicht im root-FS zu nutzen, sondern eben weggemountet auf eine eigene Partition. Was ist hier überhaupt der Benefit, /boot, /var und /tmp wegzumounten? Gibts dafür technische Gründe?
vg, Thomas

Benutzeravatar
carlchen
Beiträge: 493
Registriert: 03.03.2012 05:13:32

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von carlchen » 16.02.2017 15:30:41

TomL hat geschrieben:Was ist hier überhaupt der Benefit, /boot, /var und /tmp wegzumounten? Gibts dafür technische Gründe?
Warum ich diese Partitionen extra erstellt habe, liegt daran, das ich mir einfach die Installationsanleitungen von Debian zum Vorteil gemacht habe und Debian empfiehlt es in deren empfohlene Partitionsschemata auf eigene Partitionen zu setzen. Bei Einsteigern kann das typische und alt bekannte Verfahren genutzt werden mit / und /swap. Und wegen der /boot Partition hatte das was mit einer LVM Verschlüsselung zu tun, das könnte ich ja in Zukunft noch nachträglich verschlüsseln und da wurde mir empfohlen eine separate Boot Partition zu verwenden und schon mal vorzusorgen.
MSfree hat geschrieben:Insofern hätte ich mich geirrt, indem ich annahm, daß /var in einem unabgeschlossenen Zustand verbleibt. Das ist wohl aber laut dem von dir verlinkten Thread nicht der Fall. Daher, Lämpchen auf grün und Meldung einfach ignorieren.
Also sollte da bei systemd 232-15 ein "kosmetischer Bug" eingeschlichen sein? Meinst du die Chance besteht das in die zukünftigen systemd Versionen was in die Stretch Backports einfließen könnte, wo dies dann "behoben" ist? Ich mein, auf dem dort verlinkten Github Link, wird glaube ich geschrieben, dass ältere systemd Versionen dieses Problem nicht anzeigen beim herunterfahren. Da dieses Problem nun im Januar geschildert wurde in den Debian Bug Trackings, kann man da vllt von ausgehen, das Entwickler dies gelesen haben und versuchen dies noch zu "fixen" für spätere Backports Updates bei Stretch?

Was aus /var/log zu posten wäre dann bestimmt auch überflüssig nehme ich an, da die bestimmt auch beim herunterfahren entfernt werden?

Dann kann ich mich nur nochmal vielmals bei euch und eurer Hilfe bedanken. :THX: :hail:

Grüße,
Carlchen
Debian GNU/Linux 9.0 Stretch, Xfce 4.12, als 64-Bit 8)

MSfree
Beiträge: 2321
Registriert: 25.09.2007 19:59:30

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von MSfree » 16.02.2017 15:35:07

TomL hat geschrieben:was hier der Grund ist, um /var nicht im root-FS zu nutzen
Im /var-Verzeichnis entstehen mit der Zeit immer mehr Daten und der Plattenplatz schrumpft dadurch.

Ich habe auf meinem Debian-Router beispielsweise nur eine 4GB CF-Karte statt einer Festplatte. Durch eine eigene /var-Partition kann ich verhindern, daß durch ein vollgelaufenes /-Dateisystem nicht einmal mehr root sich einloggen kann. Hier kann zwar /var vollaufen, / ist aber davon dann unabhängig.

Bei einem anderen von mit betreuten Debian-Router hat eine fehlerhaftes Shellscript, das per cron regelmässg aufgerufen wurde, /var/log auf über 20GB bis zum berüchtigeten "no space left on device" gebracht. Glücklicherweise war auch hier /var eine separate Partition, so daß ich mich noch einloggen und den Schaden beseitigen konnte.

Aus dem gleiche Grund kann es sinnvoll sein, /home abzutrennen, damit Benutzer nicht das Wurzelsystem füllen können (OK, hier helfen alternativ auch die für root reservierten Blöcke im Dateisystem oder quota).
Meinst du die Chance besteht das in die zukünftigen systemd Versionen was in die Stretch Backports einfließen könnte, wo dies dann "behoben" ist?
Es liegt nicht an systemd ansich sondern an den .service-Dateien in denen die Abhängigkeiten fehlerhaft sind. Eigentlich sollte es keine große Sache sein, die eine fehlerahafte Datei (selbst) anzupassen, auch mit der jetzigen Version von systemd.

Benutzeravatar
carlchen
Beiträge: 493
Registriert: 03.03.2012 05:13:32

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von carlchen » 16.02.2017 15:41:03

MSfree hat geschrieben:Ich habe auf meinem Debian-Router beispielsweise nur eine 4GB CF-Karte statt einer Festplatte. Durch eine eigene /var-Partition kann ich verhindern, daß durch ein vollgelaufenes /-Dateisystem nicht einmal mehr root sich einloggen kann. Hier kann zwar /var vollaufen, / ist aber davon dann unabhängig.

Bei einem anderen von mit betreuten Debian-Router hat eine fehlerhaftes Shellscript, das per cron regelmässg aufgerufen wurde, /var/log auf über 20GB bis zum berüchtigeten "no space left on device" gebracht. Glücklicherweise war auch hier /var eine separate Partition, so daß ich mich noch einloggen und den Schaden beseitigen konnte.
Wo du das gerade ansprichst, kann man das /var Verzeichnis dann bestimmt auch leeren wenn es mal voll laufen sollte oder darf man dort nur bestimmte Daten löschen? Ich lösche auch sehr gerne mittels Debianshred.
MSfree hat geschrieben:Es liegt nicht an systemd ansich sondern an den .service-Dateien in denen die Abhängigkeiten fehlerhaft sind. Eigentlich sollte es keine große Sache sein, die eine fehlerahafte Datei (selbst) anzupassen, auch mit der jetzigen Version von systemd.
Ach so, dann sollte ich mich die Tage mal auf die Suche machen und gucken, wie man das anpassen könnte. Ich bin da schon einmal beruhigt, das dieses FAILED kein schwerwiegendes Problem des System zu sein scheint. :hail:

Grüße,
Carlchen
Debian GNU/Linux 9.0 Stretch, Xfce 4.12, als 64-Bit 8)

MSfree
Beiträge: 2321
Registriert: 25.09.2007 19:59:30

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von MSfree » 16.02.2017 16:07:45

carlchen hat geschrieben:kann man das /var Verzeichnis dann bestimmt auch leeren wenn es mal voll laufen sollte oder darf man dort nur bestimmte Daten löschen?
Als root darf man alles :mrgreen:

Allerdings sollte man wirklich nicht blind drauf loslöschen. Typischerweise läuft /var/log gerne mal voll, je nach dem, welche Serverdienste installiert sind, wohin sie loggen und wie geschwätzig ihr Loglevel eingestellt ist.

Unter /var/lib/apt liegen z.B. die Paketinformation für apt-get, die man lieber nicht löschen sollte.

Benutzeravatar
carlchen
Beiträge: 493
Registriert: 03.03.2012 05:13:32

Re: FAILED Meldung beim runterfahren von unmount /var

Beitrag von carlchen » 17.02.2017 17:26:41

Na gut, dann weiß ich erst einmal Bescheid und möchte mich nochmal bei euch allen für eure tatkräftige Hilfe und geopferte Zeit bedanken. :THX:

@ MSfree, ich werde die /var Partition einfach mal im Auge behalten und wenn diese wirklich irgendwann mal voll sein sollte, dann melde ich mich am besten nochmal bei euch.
MSfree hat geschrieben:Es liegt nicht an systemd ansich sondern an den .service-Dateien in denen die Abhängigkeiten fehlerhaft sind. Eigentlich sollte es keine große Sache sein, die eine fehlerahafte Datei (selbst) anzupassen, auch mit der jetzigen Version von systemd.
Hast du denn auch eine Idee welche Datei dies ist, wo man da etwas anpassen könnte? Dann würde ich da mal rein schauen.

Grüße,
Carlchen
Debian GNU/Linux 9.0 Stretch, Xfce 4.12, als 64-Bit 8)

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 7 Gäste