System refuses SSH and stuck on 'booting up' after systemd installation

I suspect there is a /etc/nologin file (whose content would be "System is booting up.") that is not removed after the systemd installation.

[update] What affects you is a bug that was reported on Ubuntu's BTS last December. It is due to a /var/run/nologin file (= /run/nologin since /var/run is a symlink to /run) that is not removed at the end of the systemd installation.

/etc/nologin is the standard nologin file. /var/run/nologin is an alternate file that may be used by the nologin PAM module (man pam_nologin).

Note that none of the nologin files affect connections by user root, only regular users are prevented from logging in.

@xhienne gave me the right direction.

After searching through the file system I found /run/nologin (@xhienne suggested /etc/nologin) file, removing which solved the problem.

The condition existed in /usr/lib/tmpfiles.d/systemd.conf

I will include this step in my script.

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.

The Mageia distribution bug tracker seems to have a related issue open: Bug 21080 - ssh login disabled by /run/nologin after a reboot .

After experiencing this problem quite frequently, finding the tracker helped identify a workaround that could be more appropriate than simply removing the /run/login file.

Here is some data related to queries for information in that bug tracker:

$ 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

The bug tracker and the information above seems to show that the problem is actually due to a failure to start the systemd-user-sessions.service daemon.

This is in fact what happens in my case, so the following workaround temporarily corrects the banned login condition:

$ sudo systemctl start systemd-user-sessions.service

After doing this, the /run/nologin file is no longer present, and, one can SSH from another system. Note, however, that this is not reliable as sometimes the user does not have access to the console of the affected system.