Hallo,
da mir gerade an anderer Stelle ein aehnliches Problem untergekommen ist, habe ich etwas weiter gesucht und das hier gefunden:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572
tl;dr: Seit Kernel commit 43838a23a0 kann sich ein Prozess nicht mehr darauf verlassen, dass der getrandom() Syscall *nicht* blockiert, obwohl kein Flag GRND_RANDOM gesetzt ist.
getrandom() ist ein relativ neuer Syscall und nicht zu verwechseln mit Lesen aus /dev/random oder /dev/urandom.
Symptom hier ist: System bootet und bleibt noch vor dem Starten der Login-Prompts haengen. Dieser Zustand wird erst verlassen, wenn ausreichend viel auf der Tastatur rumgetippt wurde. Das fuellt den Entropie-Pool im Kernel und fuehrt schliesslich dazu, dass das blockierende getrandom() zurueckkehrt. Der Aufruf von getrandom() scheint in diesem Fall direkt im systemd stattzufinden.
Gruss, Christian
Hallo,
Symptom hier ist: System bootet und bleibt noch vor dem Starten der Login-Prompts haengen. Dieser Zustand wird erst verlassen, wenn ausreichend viel auf der Tastatur rumgetippt wurde. Das fuellt den Entropie-Pool im Kernel und fuehrt schliesslich dazu, dass das blockierende getrandom() zurueckkehrt. Der Aufruf von getrandom() scheint in diesem Fall direkt im systemd stattzufinden.
Hilft es hier dann (auch) z.B. haveged zu installieren? Das mache ich sonst häufig auf Kisten mit zuwenig Zufall.
Ob Christian Recht hat, ließe sich mit einem Blick in /proc/sys/kernel/random/entropy_avail belegen - vielleicht durch einen at/cron-Job, der das im Hintergrund auch vor Login mal testweise protokolliert.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo Ronny,
On Wed, May 08, 2019 at 15:16:58 +0200, Ronny Seffner wrote:
Ob Christian Recht hat, ließe sich mit einem Blick in /proc/sys/kernel/random/entropy_avail belegen - vielleicht durch einen at/cron-Job, der das im Hintergrund auch vor Login mal testweise protokolliert.
...falls das System bis dorthin ueberhaupt kommt. Wie gesagt, hier blockiert systemd intern, deshalb laesst sich das Problem auch kaum mit systemctl/systemd-analyze finden, weil es keine unit ist.
Und ja, wenn man den Inhalt von /proc/sys/kernel/random/entropy_avail sehen will, dann nicht interaktiv per Shell, sondern per cron, weil sonst die Messung das Messergebnis beeinflusst :)
Leider assimiliert systemd ja immer mehr Dienste, so auch cron. Damit koennte es prinzipiell auch *vor* dem Start des cron-Pendant von systemd zum Haenger kommen, und man sieht wieder nichts.
Gruss, Christian
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Ronny Seffner