Le système refuse SSH et reste bloqué au démarrage après l'installation de systemd

J'ai un problème reproductible sur les machines virtuelles Linux Ubuntu (14.04 LTS) créées dans Azure.

Après avoir installé le systemdpackage via le script, le système refuse infiniment les nouvelles connexions ssh.

Le système démarre.

Connexion fermée par xxx.xxx.xxx.xxx

La connexion ssh active est cependant maintenue. Aucun /etc/nologinfichier n'est présent dans le système.

La seule option que je vois est une réinitialisation matérielle qui résout le problème. Mais comment l'éviter?

Voici le script que j'utilise:

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

Je soupçonne qu'il existe un /etc/nologinfichier (dont le contenu serait «Le système démarre») qui n'est pas supprimé après l'installation de systemd.

[mise à jour] Ce qui vous affecte est un bug qui a été signalé sur le BTS d'Ubuntu en décembre dernier. Cela est dû à un /var/run/nologinfichier (= /run/nologinpuisqu'il /var/runs'agit d'un lien symbolique vers /run) qui n'est pas supprimé à la fin de l'installation de systemd.

/etc/nologinest le fichier nologin standard. /var/run/nologinest un autre fichier qui peut être utilisé par le nologinmodule PAM ( man pam_nologin).

Notez qu'aucun des nologinfichiers n'affecte les connexions par racine utilisateur, seuls les utilisateurs réguliers ne peuvent pas se connecter.

@xhienne m'a donné la bonne direction.

Après avoir cherché dans le système de fichiers, j'ai trouvé le fichier /run/nologin(@xhienne suggéré / etc / nologin), ce qui a résolu le problème.

La condition existait dans /usr/lib/tmpfiles.d/systemd.conf

Je vais inclure cette étape dans mon 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.

Le suivi des bogues de distribution de Mageia semble avoir un problème connexe ouvert: Bogue 21080 - connexion ssh désactivée par / run / nologin après un redémarrage .

Après avoir rencontré ce problème assez fréquemment, la recherche de l'outil de suivi a permis d'identifier une solution de contournement qui pourrait être plus appropriée que la simple suppression du fichier / run / login .

Voici quelques données relatives aux requêtes d'informations dans ce traqueur de bogues:

$ 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

L'outil de suivi des bogues et les informations ci-dessus semblent montrer que le problème est dû en fait à l'échec du démarrage du démon systemd-user-sessions.service .

C'est en fait ce qui se passe dans mon cas, donc la solution de contournement suivante corrige temporairement la condition de connexion interdite:

$ sudo systemctl start systemd-user-sessions.service

Après cela, le fichier / run / nologin n'est plus présent et on peut SSH depuis un autre système. Notez, cependant, que ce n'est pas fiable car parfois l'utilisateur n'a pas accès à la console du système affecté.

J'ai eu exactement le même problème mais je pense que plusieurs scénarios peuvent le créer.

Dans mon cas, pour réactiver l'accès à distance, j'ai dû demander à KVM un accès direct à notre serveur distant, puis:

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

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

Mais sur l'écran KVM, j'ai pu voir qu'il avait démarré en mode d'urgence!

Auparavant, j'avais fait des changements de disque / partition (augmentation des inodes) qui ont généré un nouvel UUID et oublié de l'ajouter le fichier / etc / fstab.

Après avoir lancé la commande:

blkid

... et copiez en collant le nouvel UUID sur le fichier fstab, j'ai pu redémarrer le serveur sans aucun problème et l'accès SSH à distance allait bien après cela.

Dans le fichier / etc / ssh / sshd_config, définissez UsePAM sur no

UsePAM no