[erledigtPause nach systemd reached target shutdown, wieso ?

[scientific]

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

https://lmgtfy.com/?q=systemd+debug-shell

[Profbunny]

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?

[schwedenmann]

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.

[Profbunny]

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.

[scientific]

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

[Profbunny]

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?

[scientific]

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

[TomL]

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.

[Profbunny]

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.

[TomL]

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.

und so wie ich die Sache verstehe, RequiresMountsFor= müsste das tun was ich will.

Ja!

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?

[schwedenmann]

Hallo



Das Problem hat sich seit gestern (d-u) erledigt. Es muß wohl an der momentane Transition bei Sid gelegen haben. Jedenfalls hatte ich das Sytem von nvidia-legacy340xx auf nouveau umgestellt , was noch keine Verbesserung brachte, erst seit dem gestrigen d-u und update-grub bootet das System korrekt und ein shutdown -r oder -h macht das was es soll.

Danke nochmals für euren Einsatz ud die Tips.

mfg
schwedenmann