O sistema recusa o SSH e fica preso na 'inicialização' após a instalação do systemd

Question

Eu tenho um problema que é reproduzível em Linux Ubuntu VMs (14.04 LTS) criadas no Azure.

Depois de instalar o pacote systemd através do script, o sistema recusa novas conexões ssh, infinitamente.

System is booting up.

Connection closed by xxx.xxx.xxx.xxx

A conexão ssh ativa é mantida embora. Não há nenhum arquivo /etc/nologin presente no sistema.

A única opção que vejo é um hard reset que resolve o problema. Mas como evito isso?

Aqui está o script que estou usando:

#!/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

    

Answer 1

Suspeito que exista um ficheiro /etc/nologin (cujo conteúdo seria "O sistema está a arrancar.") que não é removido após a instalação do systemd.

[update] O que afeta você é um bug que foi reportado no BTS do Ubuntu em dezembro passado. É devido a um arquivo /var/run/nologin (= /run/nologin desde que /var/run é um link simbólico para /run ) que não é removido no final da instalação do systemd.

/etc/nologin é o arquivo padrão nologin. /var/run/nologin é um arquivo alternativo que pode ser usado pelo módulo nologin PAM ( man pam_nologin ).

Observe que nenhum dos arquivos nologin afetam as conexões pelo usuário root, apenas usuários regulares são impedidos de efetuar login.

    

Answer 2

@xhienne me deu a direção certa.

Depois de pesquisar pelo sistema de arquivos, encontrei o arquivo /run/nologin (@xhienne suggested / etc / nologin), removendo o problema resolvido.

A condição existia em /usr/lib/tmpfiles.d/systemd.conf

Vou incluir este passo no meu script.

sudo rm /run/nologin

    

Answer 3

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.

O rastreador de erros de distribuição da Mageia parece ter um problema relacionado aberto: Erro 21080 - Login ssh desativado por / run / nologin após uma reinicialização .

Depois de experimentar esse problema com bastante frequência, encontrar o rastreador ajudou a identificar uma solução alternativa que poderia ser mais apropriada do que simplesmente remover o arquivo / run / login .

Aqui estão alguns dados relacionados a consultas por informações no rastreador de bugs:

$ 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

O rastreador de bugs e as informações acima parecem mostrar que o problema é devido a uma falha ao iniciar o daemon systemd-user-sessions.service .

Isso é o que acontece no meu caso, então a seguinte correção corrige temporariamente a condição de login banida:

$ sudo systemctl start systemd-user-sessions.service

Depois de fazer isso, o arquivo / run / nologin não está mais presente, e é possível usar o SSH em outro sistema. Observe, no entanto, que isso não é confiável, pois às vezes o usuário não tem acesso ao console do sistema afetado.