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

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

Após instalar o systemdpacote por meio de script, o sistema recusa novas conexões ssh infinitamente.

O sistema está inicializando.

Conexão fechada por xxx.xxx.xxx.xxx

A conexão ssh ativa é mantida. Não há /etc/nologinarquivo presente no sistema.

A única opção que vejo é uma reinicialização completa 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

Eu suspeito que existe um /etc/nologinarquivo (cujo conteúdo seria "O sistema está inicializando".) Que não é removido após a instalação do systemd.

O que afeta você é um bug relatado no BTS do Ubuntu em dezembro passado. Isso ocorre devido a um /var/run/nologinarquivo (= /run/nologinuma vez que /var/runé um link simbólico para /run) que não é removido no final da instalação do systemd.

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

Observe que nenhum dos nologinarquivos afeta as conexões por raiz do usuário; apenas usuários regulares são impedidos de efetuar login.

@xhienne me deu a direção certa.

Após pesquisar no sistema de arquivos, encontrei o arquivo /run/nologin(@xhienne sugerido / etc / nologin), removendo o que resolveu o problema.

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

Vou incluir esta etapa no meu 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.

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

Depois de enfrentar esse problema com muita 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 de informações nesse rastreador de erros:

$ 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 erros e as informações acima parecem mostrar que o problema é devido a uma falha ao iniciar o daemon systemd-user-sessions.service .

Isso é de fato o que acontece no meu caso, portanto, a seguinte solução alternativa corrige temporariamente a condição de logon banido:

$ sudo systemctl start systemd-user-sessions.service

Depois de fazer isso, o arquivo / run / nologin não está mais presente e é possível fazer o SSH de 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.

Eu tive exatamente o mesmo problema, mas acho que vários cenários podem criá-lo.

No meu caso, para ativar o acesso remoto novamente, tive que solicitar ao KVM acesso direto ao nosso servidor remoto e, em seguida:

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

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

Mas na tela do KVM eu pude ver que ele inicializou no modo de emergência!

Anteriormente, eu estava fazendo algumas alterações no disco / partição (aumento de inodes), o que gerou um novo UUID e esqueci de adicioná-lo ao arquivo / etc / fstab.

Após emitir o comando:

blkid

... e copiar colando o novo UUID no arquivo fstab, consegui reiniciar o servidor novamente sem problemas e o acesso SSH remoto ficou bom depois disso.

No / etc / ssh / sshd_config, defina UsePAM como não

UsePAM no