Система отказывается от SSH и зависает при «загрузке» после установки systemd

У меня есть проблема, которую можно воспроизвести на виртуальных машинах Linux Ubuntu (14.04 LTS), созданных в Azure.

После установки 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.

[обновление] На вас влияет ошибка, о которой сообщалось на BTS в Ubuntu в декабре прошлого года. Это связано с /var/run/nologinфайлом (=, /run/nologinпоскольку /var/runэто символическая ссылка /run), который не удаляется в конце установки systemd.

/etc/nologinстандартный файл nologin /var/run/nologinальтернативный файл, который может использоваться nologinмодулем PAM ( 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