Ich vermute, es gibt einen /etc/nologin Datei (deren Inhalt "System is booting up.") wäre, die nach der systemd-Installation nicht entfernt wird.
[Update] Was Sie betrifft, ist ein Fehler, der letzten Dezember auf Ubuntus BTS gemeldet wurde. Es liegt an einer /var/run/nologin Datei (=/run/nologin seit /var/run ist ein symbolischer Link zu /run ), die am Ende der systemd-Installation nicht entfernt wird.
/etc/nologin ist die standardmäßige nologin-Datei. /var/run/nologin ist eine alternative Datei, die von nologin verwendet werden kann PAM-Modul (man pam_nologin ).
Beachten Sie, dass keiner der nologin Dateien beeinflussen Verbindungen durch Benutzer root, nur normale Benutzer werden daran gehindert, sich anzumelden.
@xhienne hat mir die richtige Richtung gegeben.
Nachdem ich das Dateisystem durchsucht hatte, fand ich /run/nologin (@xhienne schlug /etc/nologin) Datei vor, deren Entfernung das Problem löste.
Die Bedingung existierte in /usr/lib/tmpfiles.d/systemd.conf
Ich werde diesen Schritt in mein Skript aufnehmen.
sudo rm /run/nologin
Note: This answer is applicable whether or not systemd was recently installed or not.
The issue was observed even after systemd had been installed a long time.
Der Bug-Tracker der Mageia-Distribution scheint ein verwandtes Problem offen zu haben:Bug 21080 - ssh-Anmeldung durch /run/nologin nach einem Neustart deaktiviert .
Nachdem dieses Problem ziemlich häufig aufgetreten ist, hat die Suche nach dem Tracker geholfen, eine Problemumgehung zu finden, die geeigneter sein könnte, als einfach /run/login zu entfernen Datei.
Hier sind einige Daten zu Abfragen nach Informationen in diesem Bugtracker:
$ ls -l /run/nologin
-rw-r--r-- 1 root root 42 Mar 6 10:11 /run/nologin
$ cat /run/nologin
"System is booting up. See pam_nologin(8)"
$ date
Tue Mar 6 11:10:38 CST 2018
$ uptime
11:15:10 up 1:04, 0 users, load average: 0.07, 0.07, 0.08
$ systemctl status systemd-user-sessions.service
● systemd-user-sessions.service - Permit User Sessions
Loaded: loaded (/usr/lib/systemd/system/systemd-user-sessions.service; static
Active: inactive (dead)
Docs: man:systemd-user-sessions.service(8)
$ systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After systemd-user-sessions.service --no-pager
Requires=system.slice sysinit.target
Requisite=
Wants=
BindsTo=
PartOf=
[email protected] prefdm.service crond.service multi-user.target plymouth-quit-wait.service session-c2.scope display-manager-failure.service systemd-ask-password-wall.service session-c1.scope [email protected] shutdown.target [email protected] user-983.slice user-1000.slice plymouth-quit.service
After=system.slice systemd-journald.socket remote-fs.target network.target systemd-journal-flush.service sysinit.target nss-user-lookup.target basic.target
Der Bugtracker und die obigen Informationen scheinen zu zeigen, dass das Problem tatsächlich auf einen Fehler beim Starten von systemd-user-sessions.service zurückzuführen ist Dämon.
Dies ist in meinem Fall tatsächlich der Fall, daher korrigiert die folgende Problemumgehung vorübergehend die gesperrte Anmeldebedingung:
$ sudo systemctl start systemd-user-sessions.service
Danach wird die Datei /run/nologin Datei ist nicht mehr vorhanden, und man kann SSH von einem anderen System aus ausführen. Beachten Sie jedoch, dass dies nicht zuverlässig ist, da der Benutzer manchmal keinen Zugriff auf die Konsole des betroffenen Systems hat.