Re: ssh-login auf einen Server ohne logind
Am Dienstag, 23. Februar 2016, 20:03:43 CET schrieb Sven Hartge:
> Uwe Kleine-König <uwe+debian@kleine-koenig.org> wrote:
> > On 02/23/2016 07:26 PM, Sven Hartge wrote:
> >> Marc Haber <mh+debian-user-german@zugschlus.de> wrote:
> >>> in jessie scheint ein ssh-Server 25 Sekunden lang auf logind zu
> >>> warten, wenn man sich per ssh aus der Ferne einlogged.
> >>
> >> Da hat jemand dbus neugestartet. Das triggert diesen Bug. Lösung:
> >> systemd-logind neu starten, dann klappt der Login wieder sofort.
> >
> > Ich habe die Frage von Marc zwar anders verstanden, aber auch gleich an
> > dieses Problem gedacht. Der dazugehörige Bug ist
> >
> > http://bugs.debian.org/770135
>
> Ich hatte dieses Problem bei der Benutzung von needrestart auf
> Jessie-Systemen welches nach Updates von bestimmten Libs dann dbus
> durchgestartet hat. Danach war der Login eben um 25 Sekunden verzögert.
> Ein Blacklisten von dbus in needrestart behebt das Problem dann.
>
> (Das man bestimmte Services von systemd, unter anderem journald, logind
> und dbus nicht neu starten darf, oder es bröselt an mehrere Ecken ist
> unschön, gelinde gesagt. Für journald soll das Problem behoben sein, der
> Fix ist IIRC und AFAIR sowie AFAIK aber nicht im Jessie systemd
> enthalten.)
Das zusammen damit, dass systemd im Rettungs-Modus nicht mal erlaubt, via
systemctl oder service den SSH-Daemon zu starten finde ich schon ziemlich
heftig. So war das zumindest bei CentOS 7, wo systemd in den RettungsModus
wechselte, nachdem ich für /boot als Gerät LABEL=boot in die /etc/fstab
eintrug, vergaß das Label zu setzen und dann neu startete. Ich hab den SSH
dann allen ernstes mit /usr/bin/sshd manuell gestartet.
Mittlerweile habe ich daher alles an Dateisystemen, das nicht kritisch ist,
mit "nofail" markiert. Ja, das ist in den Releasenotes dokumentiert, es wäre
meines Erachtens aber eine dicke, fette Debconf-Warnung wert gewesen.
So oder so bleibt unschön, dass Systemd beim Versuch im Rettungsmodus ssh zu
starten, einfach erneut versucht, das Dateisystem zu mounten, 120 Sekunden auf
das Blockgerät wartet und dann wieder in den Rettungsmodus geht.
Ich hatte das auch auf der Debconf in Heidelberg angesprochen und da hieß es,
dass Debian da höchstwahrscheinlich auch betroffen ist. Es gab die Idee, einen
Rettungsmodus bereit zu stellen, der wenigstens versucht das Netzwerk
irgendwie hochzubringen und SSH zu starten.
Für Server in weiter entfernten Rechenzentren kann das erhebliche Konsequenzen
nach sich ziehen. Auch wenn natürlich immer sinnvoll ist, eine Art Out of
Band-Management zu haben.
Ich lasse meine persönliche Server-VM derzeit noch mit Sysvinit laufen.
Systemd läuft nur auf meinen Desktop-Systemen.
Ciao,
--
Martin
Reply to: