[erledigtPause nach systemd reached target shutdown, wieso ?

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
schwedenmann
Beiträge: 5529
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

[erledigtPause nach systemd reached target shutdown, wieso ?

Beitrag von schwedenmann » 21.11.2016 18:25:47

Hallo



mein System (debian-Sid, 64Bit, Debian-unstable, wmaker, kernel 4.7xyz) macht rund 90s und mehr Pause, egal ob shutdown -h oder shutdown -r.

im journalctl steht dort folgendes
Nov 20 21:16:03 nathan64 systemd[1]: Reached target Shutdown.
Nov 20 21:16:03 nathan64 systemd[1]: Reached target Final Step.
Nov 20 21:16:03 nathan64 systemd[1]: Starting Reboot...
Nov 20 21:16:03 nathan64 systemd[1]: Shutting down.
Nov 20 21:16:03 nathan64 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Nov 20 21:16:03 nathan64 systemd-journald[370]: Journal stopped
-- Reboot --
Nov 21 17:19:16 nathan64 kernel: Linux version 4.7.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.1 20160904 (Debian 5.4.1-2) ) #1 SMP Debian 4.7.8-1 (2016-10-19)
das sind rund 3min Pause !!


Bein einem anderen System (selber PC, auch debian-unstable) erfolgt ein shutdown -r oder -h sehr schnell (gefühlt nur einige Sekunden).

Wie kann ich Das Problem weiter eingrenzen, oder das journal aufbohren, sodaß es sagt, was in den 3min passiert .


mfg
schwedenmann


P.S.
Das System hat luks + lvm, aber die weren ja schon vor reached target shutdown korrekt unmountet.
Zuletzt geändert von schwedenmann am 04.12.2016 12:48:06, insgesamt 1-mal geändert.

dufty2
Beiträge: 1711
Registriert: 22.12.2013 16:41:16

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von dufty2 » 21.11.2016 18:58:08

Zwischen "Nov 20 21:16:03" und "Nov 21 17:19:16 " sind etwas mehr als drei Minuten,
gefühlt fast ein ganzer Tag ;)
Das
-- Reboot --
steht quasi immer da, egal ob Hochfahren oder "echter Reboot", wenn ich mein journal so anschaue.
Während des eigentlichen Rebooten kann das journal trivialerweise natürlich nichts loggen.

schwedenmann
Beiträge: 5529
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von schwedenmann » 21.11.2016 19:04:04

Hallo



Das blöde ist nur

Es vergehen merh als 90s wenn am Bildschirm "reached target shutdown steht (ist das letzte was ich vom reboot, oder shutdown -h sehe), dann gute 90s oder
mehr nichts, die Lüfter laufen und dan anch einer Ewiugkeit geht der PC aus.

Wie gesagt, selber PC, auch unstable, da fährt der PC nach einigen Sekunden runter und ist muksmäuschen still.

mfg
schwedenmann

Ich versuche mal die nächsten Tage ein shutdown -r zu posten, dann sieht man ja, wenn shutdown.taget erreicht wird und wann der Linux-kernel wieder gebootet wird.

TomL

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von TomL » 21.11.2016 19:42:17

schwedenmann hat geschrieben:Ich versuche mal die nächsten Tage ein shutdown -r zu posten,
Versuchs mal mit ... ob das Verhalten gleich ist.

Code: Alles auswählen

systemctl poweroff
Ansonsten.... Poettering sagt, ist ein Kernel-Problem..... zumindest sehen hier die Ausgaben gleich aus:
https://github.com/systemd/systemd/issues/2868

schwedenmann
Beiträge: 5529
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von schwedenmann » 22.11.2016 15:31:30

Hallo


Hab gestern beim Shutdowen -r now mal die Zeit bis zum erscheinen der POST-Meldungen gestoppt: 88s hat es gedauert.

Teste heute abend mal systemctl poweroff, mal schauen.

mfg
schwedenmann

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von scientific » 24.11.2016 09:21:36

Läuft in der Zeit noch die debug-shell, wenn sie prinzipiell aktiviert wurde?
Da könntest du dann nachschauen, welche unit noch hängt.
Oder hängt ev. irgend ein Dateisystem?
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

schwedenmann
Beiträge: 5529
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von schwedenmann » 24.11.2016 15:16:10

Hallo

Läuft in der Zeit noch die debug-shell, wenn sie prinzipiell aktiviert wurde?
ich weiß gar nicht was das ist, deshalb kann ich es auch nicht aktiviert haben



.
Oder hängt ev. irgend ein Dateisystem?
Nö, eigentlich nicht, denn wenn
"reached target shutdown" erreicht iust, sind alle LVM. luks und andere System korrekt ausgehängen, vorher wird zwar imme rgemeckert, aber das ist m.M. bei Systemd mit luks + lvm normal.


Wenn ich systemctl poweroff im Terminal eingebe, dauert es 88-90s bis "reached target shutdown" erreicht wurde (also die letze Bildschirmmeldung und dann dauert es wieder 88-90s bis der PC aus ist.

mfg
schwedenmann

TomL

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von TomL » 24.11.2016 15:43:46

Könntest Du zum Testen unmittelbar vor dem "shutdown" oder dem "poweroff" einmal folgendes Script starten:

Code: Alles auswählen

/etc/init.d/umountnfs.sh
Nur mal so aus Neugier, um zu sehen, ob das einen Einfluss hat.

schwedenmann
Beiträge: 5529
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von schwedenmann » 24.11.2016 16:00:20

Hallo


@TomL
Könntest Du zum Testen unmittelbar vor dem "shutdown" oder dem "poweroff" einmal folgendes Script starten:
Klar mach ich heute abend.

Nur, ich habe kein nfsv4-share , also auch keine exports auf dem System.

In der fstab ist zwar ein exports von einem anderen PC eingetragen, aber steht auf noauto in der fstab , da ich ich sowas, incl. CDROM + DVD-ROM(RAM) manuell per wmaker-app mounte.

ich machs mal, aber an nffsv4 sollte es nicht liegen.

mfg
schwedenmann

TomL

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von TomL » 24.11.2016 18:13:26

schwedenmann hat geschrieben:
Könntest Du zum Testen unmittelbar vor dem "shutdown" oder dem "poweroff" einmal folgendes Script starten:
Klar mach ich heute abend. Nur, ich habe kein nfsv4-share , also auch keine exports auf dem System.
OK, ich denke, das kannst Du Dir dann sparen...das bringt vermutlich nix. Wobei ich nicht meine, dass Dein Rechner Laufwerke/Freigaben shared, sondern das Du Laufwerke/Freigaben von anderen Rechner gemountet hast.

Irgendein Prozess lebt noch... und weil ich perse ein gesundes Misstrauen gegenüber der in mount-units übersetzten fstab habe....

Code: Alles auswählen

Nov 20 21:16:03 nathan64 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
... würde ich da noch mal genauer hinsehen.
schwedenmann hat geschrieben:denn wenn "reached target shutdown" erreicht iust, sind alle LVM. luks und andere System korrekt ausgehängen, vorher wird zwar imme rgemeckert, aber das ist m.M. bei Systemd mit luks + lvm normal.
Vielleicht besteht bei dem Problem trotzdem ein Zusammenhang mit den Mounts... auch wenn es keine Remote-Mounts gibt, vielleicht ist es das LUKS-Device. Ich würde mal testen, wenn ich das Luks-Device vor dem Shutdown manuell aushänge und zusätzlich auch wirklich den dazu gehörigen Müll beseitige.... also
1 . umount
2. cryptsetup luksClose
3. losetup -d (wenn es ein Container ist)

Vielleicht hat das eine Auswirkung. :roll:

Alternativende
Beiträge: 2091
Registriert: 07.07.2006 18:32:05

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von Alternativende » 24.11.2016 21:35:31

Die Fehlermeldungen bei LUKS sind wirklich normal oder? Sieht hässlich aus, aber ich habe das an allen 4 Rechnern mit der Fehlermeldung.

TomL

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von TomL » 24.11.2016 22:24:46

Ich halte das durchaus für möglich, wenn das luksdevice über die fstab gestartet wird. Früher unter sysvinit mit starrer Reihenfolge war das problemlos, aber die fstab ist unter systemd m.M.n. nicht mehr in starrer Reihenfolge. Es werden nämlich mount-units generiert, die in üblicher paralleler systemd-denkweise abgearbeitet werden. Insofern ist das durchaus möglich, dass es da knallt.

Wäre das die Ursache, wäre wahrscheinlich eine simple eigene Mount-Unit für ein (lokales) Luks-Device die Lösung... und zwar einfach durch das damit mögliche Statement :

Code: Alles auswählen

After=local-fs.target

Benutzeravatar
Dogge
Beiträge: 1895
Registriert: 13.09.2010 11:07:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von Dogge » 25.11.2016 09:35:08

Ich habe in dem Thread jetzt keine LUKS Fehlermeldungen gesehen. Bei meinen Systemen werden beim Herunterfahren aber Fehlermeldungen von LVM/LUKS ausgegeben, aber das geht so schnell, dass ich die nicht lesen kann. Da auch alles einwandfrei funktioniert habe ich da auch nicht weiter recherchiert.

Soweit ich weiß ist es eine Kombination von LVM/LUKS/dm-crypt, was der Installer halt anlegt wenn man Vollverschlüsselung auswählt.

Ich vermute also, dass das nicht die Ursache für dein Problem ist, da ich auch Meldungen von LVM/LUKS bekomme, das Hoch- oder Herunterfahren jedoch nicht verzögert wird und auch sonst keine Probleme zu beobachten sind.
Debian Testing + Gnome | Linux-Anfänger seit 04/2003
http://files.mdosch.de/2014-07/0xE13D657D.asc

Benutzeravatar
Profbunny
Beiträge: 592
Registriert: 04.04.2004 11:12:29
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Bautzen

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von Profbunny » 25.11.2016 10:21:21

Alternativende hat geschrieben:Die Fehlermeldungen bei LUKS sind wirklich normal oder? Sieht hässlich aus, aber ich habe das an allen 4 Rechnern mit der Fehlermeldung.
habe ich bei mir auch. scheint aber nichts wirklich problematisches zu sein. trotzdem beunruhigt mich das ein wenig.

ich habe sogar das Problem, dass der Rechner nicht ausgeschaltet wird. systemd wartet erst mal 1:30 min und dann jeweils 3 min und
dann passiert nichts mehr. Bin leider nicht am Rechner, so dass ich keine Logs posten kann.
Rechner / Server Debian sid

TomL

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von TomL » 25.11.2016 12:25:48

Dogge hat geschrieben:Ich habe in dem Thread jetzt keine LUKS Fehlermeldungen gesehen. Bei meinen Systemen werden beim Herunterfahren aber Fehlermeldungen von LVM/LUKS ausgegeben, aber das geht so schnell, dass ich die nicht lesen kann.
Ich hätte gar keine Luks-Fehler erwartet... weil cryptsetup imho vielleicht gar keine Gelegenheit bekommt, einen Fehler zu produzieren. Die Ursache ist möglicherweise eine ganz andere.... eben genau die Parallelisierung. Das ist eigentlich ganz einfach zu verstehen. Allerdings ist das jetzt auch nur eine Vermutung. Ich würde das jedoch durch eine eigene Uncrypt-Unit bestätigen oder ausschließen.

Mein vermuteter Ansatz:
Üblicherweise ist die Reihenfolge bei umount's eigentlich völlig egal.... bei mir haben z.B. weder die lokalen noch die remote-Mounts irgendwelche Abhängigkeiten untereinander. Nur bei Cryptsetup bzw. dem loop-device ist das möglicherweise anders. Nehmen wir an, ich hätte nen Luks-Container auf der Platte liegen, den ich mounten will. Die Reihenfolge beim Start ist also einfach, erst die Platte mounten, dann den Container, weil der ja auf der Platte liegt. Aber vor dem Hintergrund, dass die Platte nur ein "mount" ist und der Container am Ende auch nur ein "mount" ist, kann es einfach passieren, das beim Shutdown die Platte vor dem Container umounted wird. In den generischen Mount-Units durch die fstab bestehen ja imho keine definierten Abhängigkeiten.... alle Mounts sind eben nur Mounts.

Was passiert also...?... der umount des Containers hängt und hängt und hängt, weil die Platte dummerweise zu früh umounted wurde und er deshalb den Container jetzt nicht sauber aushängen kann. Bis systemd dann den Prozess nach Ablauf des Timeouts einfach killt.

Code: Alles auswählen

Nov 20 21:16:03 nathan64 systemd-shutdown[1]: Sending SIGTERM to remaining processes..
Der Effekt ist ganz ähnlich, wenn man remote-mounts über eine wlan-Verbindung hat und der Networkmanager das wlan-nic schliesst...da hängt der umount auch.

Ob das so richtig ist... keine Ahnung... versuch macht kluch.... ich würds über ne eigene Unit probieren....

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von scientific » 25.11.2016 15:06:28

Das mit der debug-shell ist so eine Sache...
Schwer zu finden. Ich helf mal

https://lmgtfy.com/?q=systemd+debug-shell
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Profbunny
Beiträge: 592
Registriert: 04.04.2004 11:12:29
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Bautzen

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von Profbunny » 25.11.2016 17:26:24

TomL hat geschrieben: Was passiert also...?... der umount des Containers hängt und hängt und hängt, weil die Platte dummerweise zu früh umounted wurde und er deshalb den Container jetzt nicht sauber aushängen kann. Bis systemd dann den Prozess nach Ablauf des Timeouts einfach killt.

Code: Alles auswählen

Nov 20 21:16:03 nathan64 systemd-shutdown[1]: Sending SIGTERM to remaining processes..
Der Effekt ist ganz ähnlich, wenn man remote-mounts über eine wlan-Verbindung hat und der Networkmanager das wlan-nic schliesst...da hängt der umount auch.

Ob das so richtig ist... keine Ahnung... versuch macht kluch.... ich würds über ne eigene Unit probieren....
sieht so aus, als hättest du recht:
Nov 23 17:22:52 sysiphus kernel: nouveau 0000:02:00.0: disp: conn 02:0261: func 52 lookup failed, -2
Nov 23 17:22:58 sysiphus bluetoothd[672]: Failed to obtain handles for "Service Changed" characteristic
Nov 23 17:22:58 sysiphus bluetoothd[672]: Sap driver initialization failed.
Nov 23 17:22:58 sysiphus bluetoothd[672]: sap-server: Operation not permitted (1)
Nov 23 17:23:49 sysiphus pulseaudio[1704]: [pulseaudio] pid.c: Daemon already running.
Nov 23 23:16:58 sysiphus automount[914]: umount_autofs_indirect: ask umount returned busy /media/net/autofs
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-84c0e2c03d9b4df0a0c140f68bc2d6b6-media.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/dm-2.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /sys/devices/virtual/block/dm-3.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-uuid/1cd130d4-84f7-4e2f-99b6-86f81f4d4e0c.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-id/dm-name-media.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/dm-0.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /sys/devices/virtual/block/dm-0.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /sys/devices/virtual/block/dm-1.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-1d3e7f4658e74175bf4d3c753c267ea2-sdb1_crypt.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-uuid/1dfe96a0-981c-4282-8def-70e934ada364.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/dm-3.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /sys/devices/virtual/block/dm-2.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-uuid/2d8a4807-b8ae-42b1-8497-6d4ae3efad5f.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-uuid/52455b10-bbe7-423b-bc68-7c7a09a6e693.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/dm-1.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-id/dm-name-sdb5_crypt.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-9120569da641448ab92e58ac74a1ffcc-backup.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-1c7481bf16414b4ba36af569766c16e7-sdb5_crypt.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-id/dm-name-backup.
Nov 23 23:18:16 sysiphus systemd[1]: Timed out stopping /dev/disk/by-id/dm-name-sdb1_crypt.
Nov 23 23:18:17 sysiphus systemd[1]: Failed unmounting /media/net/autofs/vuplus.
Nov 23 23:18:17 sysiphus systemd[1]: bluetooth.service: Cannot watch bus name org.bluez: Transport endpoint is not connected
Nov 23 23:18:17 sysiphus systemd[1]: lightdm.service: Cannot watch bus name org.freedesktop.DisplayManager: Transport endpoint is not connected
Nov 23 23:18:17 sysiphus systemd[1]: systemd-logind.service: Cannot watch bus name org.freedesktop.login1: Transport endpoint is not connected
Nov 23 23:18:17 sysiphus systemd[1]: ModemManager.service: Cannot watch bus name org.freedesktop.ModemManager1: Transport endpoint is not connected
Nov 23 23:18:17 sysiphus systemd[1]: avahi-daemon.service: Cannot watch bus name org.freedesktop.Avahi: Transport endpoint is not connected
Nov 23 23:18:17 sysiphus systemd[1]: iio-sensor-proxy.service: Cannot watch bus name net.hadess.SensorProxy: Transport endpoint is not connected
Nov 23 23:18:17 sysiphus systemd[1]: Failed to get initial list of names: Transport endpoint is not connected
Nov 23 23:18:17 sysiphus systemd[1]: Stopped (with error) /dev/mapper/backup.
Nov 23 23:18:18 sysiphus systemd[1]: Stopped (with error) /dev/mapper/sdb1_crypt.
Nov 23 23:18:22 sysiphus systemd-cryptsetup[17983]: Failed to deactivate: Device or resource busy
-- Reboot --
sysiphus:~$ uname -a
Linux sysiphus 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux
@schwedenmann
was hast du für einen kernel und vor allem ändert es was wenn du einen anderen bootest?
Rechner / Server Debian sid

schwedenmann
Beiträge: 5529
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von schwedenmann » 25.11.2016 17:49:12

Hallo

@profbunny
was hast du für einen kernel und vor allem ändert es was wenn du einen anderen bootest?
joerg@nathan64:~$ uname -a
Linux nathan64 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 GNU/Linux
Mit einem anderen Kernel boote ich Sa ode So mal, werde dann berichten.

mdfg
schwedenmann

P.S. Wie gesagt selber PC aber auch eine andere Debian-Sid + Arch Installation, jeweils mit 4.8 Kernel, kein luks und kein lvm, da fährt der PC in sekundenschnelle runter.

Benutzeravatar
Profbunny
Beiträge: 592
Registriert: 04.04.2004 11:12:29
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Bautzen

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von Profbunny » 28.11.2016 08:00:28

ich habe jetzt auch mal den kernel 4.7.0 getestet und seit dem, funktioniert es auch wieder im 4.8 wie es soll.

so richtig versteh ich es nicht. aber ich habe auf einer Festplatte massive Probleme, sodass da mein btrfs Dateisystem,
anscheinen hinüber ist. bftrsck bringt nichts. Ich habe aber irgendwo gelesen, dass die btrfs Dateisystemtools ziemlicher murks sein sollen.
Mal schauen ob das auswirkungen auf systemd hat, falls ich es repariert bekomme.
Rechner / Server Debian sid

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von scientific » 28.11.2016 09:23:34

Kleiner Exkurs zu btrfs.

Code: Alles auswählen

 btrfs check... 
kann bei kaputten btrfs in der Tat mehr kaputtmachen als reparieren.
Und btrfs ist auf hãufiges mounten/unmounten sehr sensibel.
Hab da mit der externen Platte oft meine liebe Not, wenn ich sie zum testen meiner Software oft aus- und einstecke.

Meine Recherchen ergaben, dass ein unterbrochener automatischer balance-Vorgang in Kombi mit dem Löschen mehrerer Subvolumes und einem Unmounten btrfs so beschädigen kann, dass btrfs-cleaner dann einen Kernelfehler (Taints Kernel...) verursacht und das FS ro remounted wird.

Ein neuerlicher balance-Vorgang sowohl auf Metadaten - wie auch Daten-Chunks mit aufsteigender usage in 5%-Schritten bis Chunks rewritten werden, hat als ersten Schritt jetzt schon mehrmals geholfen.
Dann noch scrub laufen lassen, und das FS war geheilt. Sonst hilft nur neu formatieren...

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Profbunny
Beiträge: 592
Registriert: 04.04.2004 11:12:29
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Bautzen

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von Profbunny » 28.11.2016 20:54:25

scientific hat geschrieben:Kleiner Exkurs zu btrfs.

Code: Alles auswählen

 btrfs check... 
kann bei kaputten btrfs in der Tat mehr kaputtmachen als reparieren.
Und btrfs ist auf hãufiges mounten/unmounten sehr sensibel.
Hab da mit der externen Platte oft meine liebe Not, wenn ich sie zum testen meiner Software oft aus- und einstecke.

Meine Recherchen ergaben, dass ein unterbrochener automatischer balance-Vorgang in Kombi mit dem Löschen mehrerer Subvolumes und einem Unmounten btrfs so beschädigen kann, dass btrfs-cleaner dann einen Kernelfehler (Taints Kernel...) verursacht und das FS ro remounted wird.

Ein neuerlicher balance-Vorgang sowohl auf Metadaten - wie auch Daten-Chunks mit aufsteigender usage in 5%-Schritten bis Chunks rewritten werden, hat als ersten Schritt jetzt schon mehrmals geholfen.
Dann noch scrub laufen lassen, und das FS war geheilt. Sonst hilft nur neu formatieren...

Lg scientific
also mein btrfs volume scheint nicht mehr zu retten zu sein. insgesamt hinterlässt das bei mir ein ziemlich ungutes gefühl.
https://btrfs.wiki.kernel.org/index.php/Btrfsck
http://marc.merlins.org/perso/btrfs/pos ... epair.html
btrfs scrub is actually an online fsck everyone should run. It cannot fix anything unless you have raid1
muss mich dazu erstmal komplett einlesen. besser dann einen eigenen thread aufmachenl.

da ich nichts zuordnen kann warum das passiert ist, fällt mir nur die unsaubere unmout geschichte von systemd als mögliche ursache ein.
daher @TomL wie würdest du denn so eine unit anlegen um systemd da auf die sprünge zu helfen?
Rechner / Server Debian sid

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von scientific » 28.11.2016 21:26:28

Soviel ich über systemd-mounts weiß, muss man keine expliziten Abhängigkeiten anlegen, denn systemd erkennt, in welcher Reihenfolge die Mounts vorzunehmen sind.

Irgendwo in den Tiefen des Forums findest du von mir einige Units zum Thema cryptsetup mit luks und mount im Umfeld von systemd.
Ich hatte damals das Problem, dass ich den Key auf einem USB-Stick in den ersten Sektoren vor den Partitionen abgelegt hatte und bei der Umstellung auf systemd klappte das Entsperren nicht mehr richtig. Hab dann die entsprechenden Einträge von der fstab und crypttab mittels systemd-generator und einigen Kunstgriffen in direkte systemd-units unter /etc/systemd/system herausextrahiert. Und dann hat das ganze auch wunderbar geklappt. Sowohl beim booten als auch beim shutdown.

Hab mich grad erinnert, sogar einen Wiki-Artikel dazu verfasst zu haben: https://wiki.debianforum.de/Cryptsetup_ ... _USB-Stick
Der Artikel ist zwar noch als Baustelle gekennzeichnet, weil ich nicht mehr fertiggeworden bin... Sorry... Aber im Prinzip ist der Artikel auch fertig :)

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von TomL » 28.11.2016 22:19:39

Profbunny hat geschrieben:wie würdest du denn so eine unit anlegen um systemd da auf die sprünge zu helfen?
Das ist gar nicht soooo kompliziert. Wobei ich das jetzt nur für meine verschlüsselten externen USB-Platten und einen Container gelöst habe. Für den Container sieht das so aus:

Code: Alles auswählen

nano /etc/systemd/system/luks-container.service

Code: Alles auswählen

[Unit]
Description=thlu:luks-container.service:   Open local Luks-Container
DefaultDependencies=no
After=local-fs.target remote-fs.target
ConditionPathExists=/home/toml/.CryptCredentials

[Service]
Type=forking
RemainAfterExit=yes

ExecStartPre=/sbin/losetup /dev/loop0 /home/toml/MyContainer.vol
ExecStartPre=/sbin/cryptsetup luksOpen /dev/loop0 MyContainer --key-file "/home/toml/.CryptCredentials"
ExecStart=/bin/mount /dev/mapper/MyContainer /mnt -t ext4 -o rw   

ExecStop=/bin/umount /dev/mapper/MyContainer -f
ExecStopPost=/sbin/cryptsetup luksClose MyContainer
ExecStopPost=/sbin/losetup -d /dev/loop0

[Install]
WantedBy=multi-user.target
Hier ist nur das loop-device "0" als konstante zu beachten. Hat man mehrere Container und dann noch alle gleichzeitig auf, muss man das anders lösen, z.B. fest durchnummerieren oder mit "-f" laut man-page. Ich brauche das aber nicht und komme mit konstant "0" prima klar. Das zweite sind die .CryptCredentials. Bei mir liegt der Container auf ner Netzplatte und die CryptCredentials auf meinem Rechner. Das kann aber genauso gut ein USB-Srick sein. Wenn die Datei .CryptCredentials aber nicht "präsent" ist (siehe ConditionPathExists) wird der Container halt nicht geöffnet.

Und hier anschließend die Service-Unit für eine externe USB-Platte. Hier gilt das gleiche hinsichtlich .CryptCredentials.... nicht da=kein Device.

Code: Alles auswählen

nano /etc/systemd/system/luks-device.service

Code: Alles auswählen

[Unit]
Description=thlu:luks-device.service:   Open local Luks-Device
DefaultDependencies=no
After=local-fs.target
ConditionPathExists=/home/toml/.CryptCredentials

[Service]
Type=forking
RemainAfterExit=yes

#ExecStartPre=/sbin/cryptsetup luksOpen /dev/sdb1 Crypt_HD --key-file "/home/toml/.CryptCredentials"
 ExecStartPre=/sbin/cryptsetup luksOpen "/dev/disk/by-uuid/aaaaa-bbbb-cccc-dddd-eeeeeeee" Crypt_HD --key-file "/home/toml/.CryptCredentials"
 ExecStart=/bin/mount /dev/mapper/Crypt_HD /mnt -t ext4 -o rw   

 ExecStop=/bin/umount /dev/mapper/Crypt_HD -f
 ExecStopPost=/sbin/cryptsetup luksClose /dev/mapper/Crypt_HD

[Install]
WantedBy=multi-user.target
Hier sind die beiden Execstart-Varianten zu beachten... einmal mit "zufälligen" Device-Symlink, einmal mit UUID. Hat man mehrere USB-Platten würde ich versuchen, diese Unit mit "@" zu instanziieren und die UUID als Parameter übergeben... ggf. ist dann auch noch ein Support-Wrapper für die Mount-Points erforderlich. Oder man erstellt einfach für jede Platte 'ne eigene Unit mit festem Mount-Point und generiert einen konstanten Device-Symlink über UDEV. Dann gibts auch keine Kollisionen.

Wenn die .CryptCredentials auf nem externen Stick liegen, kann man die Devices auch prima von Hand öffnen und wieder schließen, oder via UDEV-Regel automatisch beim Einstecken des Sticks.... auch das ist ne einfache Geschichte....

Code: Alles auswählen

systemctl start luks-device.service
systemctl status luks-device.service
systemctl stop luks-device.service
Für den Systemstart aktivieren:

Code: Alles auswählen

systemctl enable luks-device.service
Ach so...fast vergessen... noch zwei Anmerkungen... der "thlu"-Identifier in allen meinen Services ist nur ne Suchhilfe für journalctl. Die /etc/crypttab nutze ich nicht, ich halte die für meine Anforderungen für entbehrlich.... ich parametrisiere stattdessen direkt. Die After-Statements in den Services sollten sicherstellen, dass die Luks-Devices IMMER vor den lokalen und remoten-Platten geschlossen werden. Ein "Stop-Job-Hänger" sollte also nicht passieren.

Also.... es gibt viele viele Möglichkeiten.... ich kann leider hier nur 'ne Startlinie markieren. :roll:

Benutzeravatar
Profbunny
Beiträge: 592
Registriert: 04.04.2004 11:12:29
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Bautzen

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von Profbunny » 30.11.2016 07:52:35

Nov 23 23:16:58 sysiphus automount[914]: umount_autofs_indirect: ask umount returned busy /media/net/autofs
Nov 23 23:18:17 sysiphus systemd[1]: Failed unmounting /media/net/autofs/vuplus.
Ich zitiere mich mal selbst. Das ist ein Bug in der autofs.service, dies ist recht leicht zu beheben, einfach bei After=remote-fs.target hinzufügen.
Dadurch fährt das system jetzt erstmal wieder zügig runter und schaltet sich auch aus.

Für die Problematik mit dem cryptsetup habe ich mir jetzt verschieden mounts angesehen
und so wie ich die Sache verstehe, RequiresMountsFor= müsste das tun was ich will.

Eine Frage noch dazu, die mount units sind alle aufs mounten ausgerichtet. Bei unmounten werden die einfach "rückwärts" benutzt?
So richtige Infos dazu konnte ich noch nicht finden.

Generell scheint es jedoch wirklich so zu sein, dass das kein Einfluss auf die Dateisysteme oder Cryptodevices hat.
Werde das die Tage mal weiterverfolgen sowie ich Zeit habe.
Rechner / Server Debian sid

TomL

Re: Pause nach systemd reached target shutdown, wieso ?

Beitrag von TomL » 30.11.2016 15:54:49

Profbunny hat geschrieben:dies ist recht leicht zu beheben, einfach bei After=remote-fs.target hinzufügen.
Genau das halte ich auch für die Lösung. Und genau das habe ich ja auch in meinen beiden Units oben eingetragen. Aber je nach dem spielt auch local-fs.target eine Rolle.
Profbunny hat geschrieben:und so wie ich die Sache verstehe, RequiresMountsFor= müsste das tun was ich will.
Ja!
Profbunny hat geschrieben:Bei unmounten werden die einfach "rückwärts" benutzt?
Ja, ich tue das so. Was spricht dagegen, die Kontrolle über ein odentliches "Schließen" selber zu übernehmen und sich nicht allein auf systemd zu verlassen? Ich behandele das exakt so wie ich einen USB-Stick handhabe: Ich mounte ihn vor dem Arbeiten, und am Ende, bevor ich die Hardware entferne, schließe ich alle offenen Dateien und führe den umount aus. Was kann falsch daran sein, das bei Luks-Devices genauso zu tun? :?

Antworten