Après l'envoi de la commande d'arrêt, la session ssh ne se termine pas

12

Chaque fois que j'envoie la commande pour éteindre ou redémarrer mes serveurs Debian, mon shell reste suspendu et ne répond pas (ne peut taper aucune commande).

entrez la description de l'image ici

L'exécution de la même action dans Ubuntu entraîne la fermeture de la session, donc je n'ai pas de terminal attaché accroché là-bas. Y a-t-il un paquet que je dois installer ou un changement de configuration à faire pour que je puisse obtenir ce même comportement sur Debian?

Programster
la source
Le même comportement se produit-il avec sudo shutdown -h now(pour la mise hors tension) et / ou sudo reboot(pour le redémarrage)?
eyoung100
oui, cela se produit également avec ceux-ci.
Programster du
2
NB vous pouvez tuer une de ces sessions ssh bloquées en tapant <enter>, tilde et period (~.).
Kenster

Réponses:

11

Cela a fonctionné pour moi:

apt-get install libpam-systemd dbus

Assurez-vous également que vous avez UsePAM yesdans votre configuration ssh.

grep -i UsePAM /etc/ssh/sshd_config

Malheureusement, vous devez redémarrer pour que la solution prenne effet ...

Explications détaillées sur le défaut du serveur .

mivk
la source
J'ai juste eu le même problème sur Ubuntu 16.04 pour lequel la solution précédente ne fonctionnait pas mais celle-ci l'a fait.
Programster
7

On dirait que c'est un systemdproblème actuellement suivi sous le bogue # 751636 .

Lorsque l'hôte est arrêté ou redémarré, systemdpeut arrêter le réseau avant qu'il ne tue la session ssh.

Il existe quelques solutions mais rien de concret:

  1. Utiliser acpid/acpi-support-basepour gérer les événements d'alimentation et ajouter ce qui suit au/etc/acpi/powerbtn-acpi-support.sh

    else
    -       # Normal handling.
    -       /sbin/shutdown -h -P now "Power button pressed"
    +
    +       if [ -x /bin/systemctl ] ; then
    +           echo "\nPower button pressed\nThe system is going down for system halt NOW!" |\
    +            /usr/bin/wall -n
    +           /bin/systemctl --force poweroff
    +       else
    +           # Normal handling.
    +           /sbin/shutdown -h -P now "Power button pressed"
    +       fi
    +
    fi
    

    puis créez des alias dans votre ~/.bashrc:

    alias reboot='echo "The system is going down for system reboot NOW!" |\
    /usr/bin/wall -n ; /bin/systemctl --force reboot'
    
    alias poweroff='echo "The system is going down for system halt NOW!" |\
    /usr/bin/wall -n ; /bin/systemctl --force poweroff'
    
  2. Création /etc/systemd/system/ssh-user-sessions.serviceavec les éléments suivants:

    [Unit]
    Description=Shutdown all ssh sessions before network
    After=network.target
    
    [Service]
    TimeoutStartSec=0
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=/bin/true
    ExecStop=/usr/bin/killall sshd
    
neurone
la source
il est bon de savoir que c'est un bug connu. J'ai essayé la deuxième solution, mais elle ne semble pas fonctionner pour moi lors de l'envoi de la commande de redémarrage. Je me suis assuré de le rendre exécutable.
Programster du
1
Rechargez le démon systemd:, systemctl daemon-reloadégalement afin d'activer le service systemd immédiatement: systemctl start ssh-user-sessions.serviceet d'activer le service au démarragesystemctl enable ssh-user-sessions.service
neuron
L'exécution des 2 premières commandes a fait l'affaire. L'exécution de la troisième commande a entraîné: The unit files have no [Install] section. They are not meant to be enabled using systemctl.mais ne semble pas être nécessaire.
Programster le
Oui, j'ai oublié de mentionner que le fichier d'unité peut inclure une "[Install]"section, qui contient des informations d'installation pour l'unité. Cette section n'est pas interprétée par systemdpendant l'exécution. Il est utilisé exclusivement par les activer et de désactiver les commandes de l' systemctloutil lors de l' installation d'une unité.
neurone
J'ai ajouté [Install]suivi WantedBy=multi-user.targetdu fichier, ce qui a entraîné le systemctl enable ssh-user-sessions.servicenon-lancement d'une erreur et entraîne la prise d'effet du service lors des redémarrages. Y a-t-il quelque chose de mal à faire ça?
Programster