Serveur SSH et extinction de la machine : non-fermeture de la connexion TCP

Support Debian
#1

Bonsoir,

Depuis que j’utilise Debian 8 (comparé à Debian 7), je remarque que, quand je lance un poweroff via ssh, la machine s’éteint, mais le serveur SSH ne ferme pas proprement la connexion et le client SSH reste à attendre des nouvelles du serveur.

J’ai pensé que ça pouvait venir du fait que le réseau est désactivé avant le serveur SSH, mais je n’en suis pas sûr et si c’est ça, je ne sais pas comment le corriger.

Petite note, quand je fais un reboot, le client SSH me retourne un Broken pipe au redémarrage du serveur SSH.

Problème reboot, shutdown et halt
#2

Bonjour,

C’est dû au fait que Jessie utilise systemD par défaut alors que Wheezy utilisait sysvrc .

Pour remédier à cela tu peux installer libpam-systemd sur le serveur SSH. http://unix.stackexchange.com/questions/216950/after-sending-shutdown-command-ssh-session-doesnt-terminate

Sinon tu peux aussi forcer la fermeture d’une session SSH de la même manière (ou presque) que cela se fait pour des sessions telnet, cu, rsh : http://blog.infertux.com/2012/12/20/properly-close-a-frozen-ssh-session/

On peut également virer systemd, son système de logs déficient, ses options en lignes de commande imbuvables, ses fichiers de configuration illisibles et autres. (Je ne critique pas le concept derrière systemD mais son instanciation)
Sur un serveur, c’est moins problématique que pour un poste avec un environnement graphique.

–
AnonymousCoward

#3

En fait, il est déjà installé.

#4

Ai tenté de reproduire le problème avec une VM, sans succès.

Est-ce que tu peux indiquer la commande que tu utilises pour ordonner au serveur de s’arrêter / redémarrer ?

De même, est-ce que tu pourrais fournir le temps que prend un ping entre ton poste et le serveur ?
J’en suis à me demander si ça ne jouerait pas un rôle.

–
AnonymousCoward

#5

J’ai commencé par le ping :
— host ping statistics —
1000 packets transmitted, 1000 received, 0% packet loss, time 283ms
rtt min/avg/max/mdev = 0.167/0.210/0.830/0.037 ms, ipg/ewma 0.283/0.200 ms
La connexion se fait par du câble ethernet via des switches, au mieux, via une connexion VPN, au pire, mais le résultat est le même quelque soit le cas.

Pour arrêter, je fais ça :
ssh root@host poweroff
Pour redémarrer, c’est pareil, mais avec reboot à la place.

#6

Bonjour

En vous lisant, je me disais…(genre : “Quelqu’un d’autre peut pas le faire ?”)

at peut exécuter la commande poweroff après que la session ssh ait été fermée.

Essaye avec la ligne de commandes qui suit :

#7

Et
# shutdown -h now
ne ferait pas l’affaire ?

#8

Je ne comprend pas, c’est quoi la différence entre poweroff, halt, shutdown -h now, telinit 0, systemctl start halt.target et systemctl start poweroff.target. Peut-être que poweroff demande au système de s’arrêter trop vite et qu’il faut plutôt lancer une des autres commandes.

#9

Pascal t’expliquera mieux que moi.
La seule chose que je sais, c’est que la commande ‘shutdown -h now’ est souvent recommandée .

#10

Est-ce que tu peux vérifier que l’option UsePAM vaut bien yes dans le fichier /etc/ssh/sshd_config sur le serveur ?

Et si tu fais un systemctl list-units , tu vois que tu utilises bien ssh.service ?

Pour ce qui est des commandes reboot, poweroff ETC, brièvement…

  • Les runlevels 0 et 6 correspondent respectivement à arrêt du système et à un redémarrage.
  • Les commandes poweroff, halt et reboot sont normalement appelées après que le gestionnaire d’initialisation (dans ce cas systemd) a fini de basculer vers un runlevel 0 ou 6.
  • Quand les commandes citées ci-dessus ne sont pas appelées alors que le runlevel est 0 ou 6, celles-ci appellent la commande shutdown. Reboot ajoute l’option -r à shutdown ETC.
  • La commande shutdown utilise la commande telinit pour demander au gestionnaire d’initialisation de basculer vers le runlevel 0 ou 6. Ensuite soit via les commandes poweroff, halt, reboot soit via des appels système (syscall) l’ordi s’éteint ou redémarre effectivement.

–
AnonymousCoward

2 J'aime
#11

J’ai testé avec shutdown -h now, le résultat est sensiblement le même.

Oui, je te confirme, le serveur SSH utilise bien PAM.[quote=“AnonymousCoward, post:10, topic:70570”]
Et si tu fais un systemctl list-units , tu vois que tu utilises bien ssh.service ?
[/quote]
L’unité ssh.service est marquée loaded active running.[quote=“AnonymousCoward, post:10, topic:70570”]
Pour ce qui est des commandes reboot, poweroff ETC, brièvement…

  • Les runlevels 0 et 6 correspondent respectivement à arrêt du système et à un redémarrage.- Les commandes poweroff, halt et reboot sont normalement appelées après que le gestionnaire d’initialisation (dans ce cas systemd) a fini de basculer vers un runlevel 0 ou 6.
  • Quand les commandes citées ci-dessus ne sont pas appelées alors que le runlevel est 0 ou 6, celles-ci appellent la commande shutdown. Reboot ajoute l’option -r à shutdown ETC.
  • La commande shutdown utilise la commande telinit pour demander au gestionnaire d’initialisation de basculer vers le runlevel 0 ou 6. Ensuite soit via les commandes poweroff, halt, reboot soit via des appels système (syscall) l’ordi s’éteint ou redémarre effectivement.
    [/quote]
    Ah, merci pour cette explication.
#12

Almtesh, est-ce que tu pourrais réessayer après avoir modifié le fichier /etc/network/interfaces pour ajouter un petit délai lorsque la carte réseau doit être déconfigurée ?

Comme ci-dessous :

# The primary network interface
auto eth0
iface eth0 inet dhcp
	pre-down sleep 1

(juste ajouter la ligne contenant pre-down)

J’avoue ne pas être arrivé à reproduire le problème avec une machine virtuelle.
Cependant, je me demande si cela ne viendrait pas du fait que systemD arrête ssh mais qu’il reste des données non envoyées sur les sockets TCP alors que systemD est déjà passé au fait de déconfigurer les interfaces réseau.

–
AnonymousCoward

#13

Bon, très bien, il faut dire qu’on a fait quelques bidouilles dans le système, ça ne m’étonnerai pas que ça vienne de là.
Je vais bosser à standardiser un peu ça et je reviens quand j’aurai un installation un peu moins bidouillée.