lange Auszeit beim Einloggen (gelöst)

[fischig]

Da du immer noch nicht (für mich) verständlich dein spezielles Loginverfahren beschrieben hast

Was gibt's da eigentlich viel zu beschreiben, was man sich nicht denken könnte, wenn's denn ohne Loginmanager passiert?
Aber ok: genauer gesagt ist mit Auszeit die Zeit gemeint, die zwischen Abschluss der Passworteingabe und dem Widererscheinen des Prompts verstreicht (tty). Gleiches Spielchen, wenn im GUI-Terminal ein Wechsel mit su (-) oder anderem Benutzter ansteht. Gewohnt bin ich, auch als Nutzer sehr alter Hardware, Sekundenruchteile. Jetzt dauert's (abgezählt via biologischem Hirn) ca. 20s.

Ich hätte mir schon längst mal einen zweiten Rechner geschnappt und mich darüber per SSH beim Problemkind eingelogt, um den Loginvorgang an der Konsole zu beobachten.

Da muss ich mich wohl wieder wegen meiner unzureichenden geistigen Fähigkeiten entschuldigen, denn auf die Idee war ich bisher nicht gekommen.

Das Ergebnis ist das gleiche, vorbehaltlich des Vertrauens in die geringen Fähigkeiten meines Hirns: 90s glaube ich nicht zu beobachten: dmesg auf dem ssh-Klienten (bookworm) unmittelbar nach dem Einloggen:

Code: Alles auswählen

...
[    9.646253] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[   11.191634] fuse init (API version 7.27)
[   11.212934] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   11.241859] PPP Deflate Compression module registered
[   11.265496] usbcore: registered new interface driver usbserial_generic
[   11.265520] usbserial: USB Serial support registered for generic
[   11.271872] usbcore: registered new interface driver option
[   11.271898] usbserial: USB Serial support registered for GSM modem (1-port)
[   11.759685] ttyS0: LSR safety check engaged!
[   11.760720] ttyS0: LSR safety check engaged!
[   11.762899] ttyS1: LSR safety check engaged!
[   11.763880] ttyS1: LSR safety check engaged!
[   12.135166] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input12
[   19.240721] random: crng init done
[   19.240726] random: 7 urandom warning(s) missed due to ratelimiting
[   19.623633] NFSD: starting 90-second grace period (net f0000097)

auf der ssh-server-Maschine (chimaers) sehe ICH mit dmesg nichts Auffälliges.

[MSfree]

Code: Alles auswählen

...
[   12.135166] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input12
[   19.240721] random: crng init done
...

Da sehe ich zumindest mal rund 7 Sekunden. crng ist ein Cryptographic random number generator. Das erinnert an ähnliche Probleme vor ein paar Jahren, als Maschinen, bei denen haveged nicht installiert war, ebenfalls plötzlich lange zum Booten benötigt haben.

[fischig]

haveged ist weder auf dem bookworm noch auf dem daedalus installiert. Und nochmal: der Boot-Vorgang ist unauffällig. Beim Einloggen auf dem daedalus hängt's. In jeder Form. Das einzige, was mir einfällt, ist, dass es mit einer durch Steckerziehen beendeter GRML-Sitzung vor einigen Wochen zusammenhängen könnte.

[fischig]

Eigentlich wollte ich's mal mit einer Neuinstallation versuchen (im Prinzip upgrade ich immer), aber nachdem ich mal wieder erfolglos versucht hatte, die devuan-netinst.iso für daedalus als Abbild mit brasero zu brennen und ich das Teil dann endgültig vom Rechner verbannen wollte (xorriso machte den Job), fielen mir die für mich altbekannten Problemkinder elogind (Pendant für Debian-logind, wenn ich recht sehe) und udisks2 auf. Die sind offenbar vordringlich dazu da, Probleme zu lösen, die man ohne sie nicht hätte. Nachdem die via apt-get deinstalliert wurden, war der Spuk mit der 20-Sekunden-Auszeit endlich vorbei.

Falls es noch jemand interessiert: Ich nutze Eigenbau-Kerne. Mit einem alten Standard-Kernel 4.19.0 trat die Auszeit auch vorher nicht auf. Ich war leider zu wenig kompetent, anhand der Modulliste (lsmod) einen Fehler zu entdecken.

[rhHeini]

Bei mir läuft auf allen meinen Rechnern, nicht nur meinem UEFI-Haupt-PC das Daedalus mit elogind und udisk2 mit den Stock- und Backportskerneln problemlos. Und das ist seit ASCII der Fall. Allerdings habe ich nie andere als die Distributionskernel verwendet.

[fischig]

Bei mir läuft auf allen meinen Rechnern [...] das Daedalus mit elogind und udisk2¹⁾ [...] problemlos.

Das glaub' ich wohl. Und irgendwie fängt der Standard-Kern ja auch bei mir die Störung ab. Ich's hab's aber gern möglichst minimalistisch und da frag' ich mich halt, wer das bewusst wozu nutzt. Ich benötige es eigentlich nicht. Ich habe mit woody angefangen und nach der KDE-Revolution (>3.5) auf jegliche DE verzichtet. Aber ja: Standardinstallationen mit systemd sind meine Systeme bis auf eines nicht.
Ich hatte auch hier 'ne interessante Diskussion zu udisks2. Der hier ist auch ganz interessant. Wohltuend sachlich und fast ohne eh allwissende Verunglimpfungen.

¹⁾ Schreibfehler: udisks2?

[tobo]

fielen mir die für mich altbekannten Problemkinder elogind (Pendant für Debian-logind, wenn ich recht sehe) und udisks2 auf. Die sind offenbar vordringlich dazu da, Probleme zu lösen, die man ohne sie nicht hätte.

Für elogind würde ich das direkt unterschreiben! Nachdem ich im Debian-Wiki über den bevorzugten Nicht-Systemd-Weg mit elogind gelesen hatte, dachte ich, das kann ja nicht so verkehrt sein!? Tja, es hat dann bestehende Skripte der Anmeldung, Suspend und Laptop-Deckel_schließen torpediert und lies sich auch nicht ansatzweise ordentlich steuern. Also musste man entscheiden - ohne läuft alles perfekt und mit funktioniert vieles nicht. Das Teil bietet (für mich) keinen einzigen Mehrwert, aber einen Haufen Nachteile.

[rhHeini]

Ich hab auf meinem Reiselaptop Devuan Chimaera und Daedalus im Dualboot laufen. Klappt alles mit Anmeldung, Suspend, Deckel schliessen mit einer Default-Installation einschliesslich elogind und udisks2. Cinnamon/Lightdm als DE.

Anfangs, also zu ASCII-Zeiten was Stretch entspricht, gab es Hakeleien zwischen consolekit und elogind. Da wurde per Default noch consolekit installiert, was Rechteprobleme verursachte. Mit den elogind-Libraries gings dann.

[fischig]

Auf meiner Arbeitsmaschine (bookworm, kein devuan!) existiert weder logind, noch udisks2, allerdings auch keine DE und auch kein Loginmanager. Ich bin eigentlich ganz zufrieden:

Code: Alles auswählen

# apt-get -s install logind
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paket logind ist ein virtuelles Paket, das bereitgestellt wird von:
  libpam-systemd 252.33-1~deb12u1 (= 252.33-1~deb12u1)
  libpam-elogind 246.10-1debian1 (= 246.10-1debian1)
Sie sollten eines explizit zum Installieren auswählen.

E: Für Paket »logind« existiert kein Installationskandidat.
# apt-get -s install udisks2
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  gdisk libatasmart4 libblockdev-fs2 libblockdev-loop2 libblockdev-part-err2
  libblockdev-part2 libblockdev-swap2 libblockdev-utils2 libblockdev2
  libpolkit-agent-1-0 libpolkit-gobject-1-0 libudisks2-0 parted
Vorgeschlagene Pakete:
  parted-doc btrfs-progs f2fs-tools libblockdev-mdraid2 mdadm nilfs-tools
  reiserfsprogs udisks2-bcache udisks2-btrfs udisks2-lvm2 udisks2-zram
  xfsprogs
Empfohlene Pakete:
  libblockdev-crypto2 polkitd libpam-systemd exfatprogs
Die folgenden NEUEN Pakete werden installiert:
  gdisk libatasmart4 libblockdev-fs2 libblockdev-loop2 libblockdev-part-err2
  libblockdev-part2 libblockdev-swap2 libblockdev-utils2 libblockdev2
  libpolkit-agent-1-0 libpolkit-gobject-1-0 libudisks2-0 parted udisks2
0 aktualisiert, 14 neu installiert, 0 zu entfernen und 91 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Inst gdisk (1.0.9-2.1 Debian:12.9/stable [amd64])
Inst libatasmart4 (0.19-5 Debian:12.9/stable [amd64])
Inst libblockdev-part-err2 (2.28-2 Debian:12.9/stable [amd64])
Inst libblockdev-utils2 (2.28-2 Debian:12.9/stable [amd64])
Inst libblockdev-fs2 (2.28-2 Debian:12.9/stable [amd64])
Inst libblockdev-loop2 (2.28-2 Debian:12.9/stable [amd64])
Inst libblockdev-part2 (2.28-2 Debian:12.9/stable [amd64])
Inst libblockdev-swap2 (2.28-2 Debian:12.9/stable [amd64])
Inst libblockdev2 (2.28-2 Debian:12.9/stable [amd64])
Inst libpolkit-gobject-1-0 (122-3 Debian:12.9/stable [amd64])
Inst libpolkit-agent-1-0 (122-3 Debian:12.9/stable [amd64])
Inst libudisks2-0 (2.9.4-4 Debian:12.9/stable [amd64])
Inst parted (3.5-3 Debian:12.9/stable [amd64])
Inst udisks2 (2.9.4-4 Debian:12.9/stable [amd64])
Conf gdisk (1.0.9-2.1 Debian:12.9/stable [amd64])
Conf libatasmart4 (0.19-5 Debian:12.9/stable [amd64])
Conf libblockdev-part-err2 (2.28-2 Debian:12.9/stable [amd64])
Conf libblockdev-utils2 (2.28-2 Debian:12.9/stable [amd64])
Conf libblockdev-fs2 (2.28-2 Debian:12.9/stable [amd64])
Conf libblockdev-loop2 (2.28-2 Debian:12.9/stable [amd64])
Conf libblockdev-part2 (2.28-2 Debian:12.9/stable [amd64])
Conf libblockdev-swap2 (2.28-2 Debian:12.9/stable [amd64])
Conf libblockdev2 (2.28-2 Debian:12.9/stable [amd64])
Conf libpolkit-gobject-1-0 (122-3 Debian:12.9/stable [amd64])
Conf libpolkit-agent-1-0 (122-3 Debian:12.9/stable [amd64])
Conf libudisks2-0 (2.9.4-4 Debian:12.9/stable [amd64])
Conf parted (3.5-3 Debian:12.9/stable [amd64])
Conf udisks2 (2.9.4-4 Debian:12.9/stable [amd64])
Conf initramfs-tools (0.142+deb12u1 Debian:12.9/stable [all])

Ich werd' mich hüten!