安装systemd后，系统拒绝SSH并停留在“启动”状态

我有一个在Azure中创建的Linux Ubuntu VM（14.04 LTS）上可重现的问题。

systemd通过脚本安装软件包后，系统将无限期拒绝新的ssh连接。

系统正在启动。

连接被xxx.xxx.xxx.xxx关闭

但是，活动的ssh连接会保留。/etc/nologin系统中没有文件。

我看到的唯一选择是硬重置，它可以解决问题。但是如何避免呢？

这是我正在使用的脚本：

#!/bin/bash

# Script input arguments
user=$1
server=$2

# Tell the shell to quote your variables to be eval-safe!

printf -v user_q '%q' "$user"
printf -v server_q '%q' "$server"
#

SECONDS=0
address="$user_q"@"$server_q"

function run {
    ssh "$address" /bin/bash "$@"
}

run << SSHCONNECTION
    # Enable autostartup

        # systemd is required for the autostartup
        sudo dpkg-query -W -f='${Status}' systemd 2>/dev/null | grep -c "ok installed" > /home/$user_q/systemd-check.txt
        systemdInstalled=\$(cat /home/$user_q/systemd-check.txt)

        if [[ \$systemdInstalled -eq 0 ]]; then
            echo "Systemd is not currently installed. Installing..."

            # install systemd
            sudo apt-get update
            sudo apt-get -y install systemd

        else
            echo "systemd is already installed. Skipping this step."
        fi

SSHCONNECTION

我怀疑有一个/etc/nologin文件（其内容为“系统正在启动。”）在systemd安装后没有被删除。

[更新]影响您的是去年12月在Ubuntu的BTS上报告的一个错误。这是由于在systemd安装结束时未删除/var/run/nologin文件（=，/run/nologin因为/var/run是符号链接/run）。

/etc/nologin是标准的nologin文件。/var/run/nologin是nologinPAM模块（man pam_nologin）可以使用的备用文件。

请注意，这些nologin文件均不影响用户root用户的连接，仅阻止普通用户登录。

@xhienne给了我正确的方向。

搜索文件系统后，我找到了文件/run/nologin（@xhienne建议使用/ etc / nologin），删除该文件可以解决问题。

条件存在于 /usr/lib/tmpfiles.d/systemd.conf

我将在脚本中包含此步骤。

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.

Mageia发行错误跟踪器似乎有一个相关的问题： 重新启动后，错误21080-ssh登录由/ run / nologin禁用。

经常遇到此问题后，找到跟踪器有助于确定一种解决方法，该解决方法比简单地删除/ run / login文件更为合适。

以下是与该错误跟踪器中的信息查询相关的一些数据：

$ 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=
Before=getty@tty1.service 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 user@983.service shutdown.target user@1000.service 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

错误跟踪器和上面的信息似乎表明该问题实际上是由于无法启动systemd-user-sessions.service守护程序造成的。

实际上这就是我的情况，因此以下变通办法可以临时纠正禁止的登录条件：

$ sudo systemctl start systemd-user-sessions.service

完成此操作后，/ run / nologin文件将不再存在，并且可以从另一系统进行SSH。但是请注意，这是不可靠的，因为有时用户无法访问受影响系统的控制台。

我遇到了完全相同的问题，但是我认为有几种情况可以创建它。

就我而言，要再次启用远程访问，我必须请求KVM直接访问我们的远程服务器，然后：

# 1. Start SSH service
/etc/init.d/ssh start

# 2. Remove the nologin file
rm /run/nologin

但是在KVM屏幕上，我实际上可以看到它已启动进入紧急模式！

以前，我一直在进行一些磁盘/分区更改（增加了inode），这些更改生成了新的UUID，却忘记将其添加到/ etc / fstab文件中。

发出命令后：

blkid

...然后将新的UUID复制并粘贴到fstab文件中，我可以再次重新启动服务器而没有任何问题，之后可以进行远程SSH访问。

在/ etc / ssh / sshd_config中将UsePAM设置为no

UsePAM no