SSH coupé lors d'un dist-upgrade

[lol]

Salut,
J’étais en train de faire une mise à jour sur une Squeeze distante (il était en train de générer le initramfs d’un nouveau kernel), j’ai été coupé…
Evidemment, maintenant j’ai droit à un beau

E: Impossible d'obtenir le verrou /var/lib/dpkg/lock - open (11: Ressource temporairement non disponible) E: Impossible de verrouiller le répertoire d'administration (/var/lib/dpkg/). Il est possible qu'un autre processus l'utilise.

Je rm /var/lib/dpkg/lock et je recommence ? Ou j’attend encore ?
En fait je ne sais pas si apt travaille encore… (htop m’indique qu’un apt-get dist-upgrade est lancé, mais il n’est pas très actif…).

Merci pour vos conseils avisés…

[fran.b]

Tue le apt et relance quitte à faire avant un dpkg -configure -a

[lol]

Salut,
Bon, j’ai pas attendu vos conseils avisés, et…

[code]# lsof /var/lib/dpkg/lock
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dpkg 8227 root 3uW REG 9,1 0 24903702 /var/lib/dpkg/lock

kill 8227

dpkg --configure --pending[/code]

Paramétrage de samba-common (2:3.5.6~dfsg-3squeeze9) ... debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Ressource temporairement non disponible dpkg : erreur de traitement de samba-common (--configure) : le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1 dpkg : des problèmes de dépendances empêchent la configuration de smbclient : smbclient dépend de samba-common (= 2:3.5.6~dfsg-3squeeze9) ; cependant : Le paquet samba-common n'est pas encore configuré. dpkg : erreur de traitement de smbclient (--configure) : problèmes de dépendances - laissé non configuré Traitement des actions différées (« triggers ») pour « python-central »... dpkg : des problèmes de dépendances empêchent la configuration de samba-common-bin : samba-common-bin dépend de samba-common (>= 2:3.4.0~pre1-2) ; cependant : Le paquet samba-common n'est pas encore configuré. dpkg : erreur de traitement de samba-common-bin (--configure) : problèmes de dépendances - laissé non configuré Paramétrage de rails (2.3.5-1.2+squeeze7) ... dpkg : des problèmes de dépendances empêchent la configuration de samba : samba dépend de samba-common (= 2:3.5.6~dfsg-3squeeze9) ; cependant : Le paquet samba-common n'est pas encore configuré. dpkg : erreur de traitement de samba (--configure) : problèmes de dépendances - laissé non configuré Paramétrage de perl-modules (5.10.1-17squeeze5) ... Paramétrage de perl (5.10.1-17squeeze5) ... Paramétrage de apt-show-versions (0.16+squeeze1) ... ** initializing cache. This may take a while ** Des erreurs ont été rencontrées pendant l'exécution : samba-common smbclient samba-common-bin samba

Ceci m’amène à une question subsidiaire: Est il possible de récupérer une session SSH, et comment ?
J’ai lu ceci et ça à l’air d’être possible:

In future I recommend to try running through screen where-ever possible. I have made a habit of screen (or byobu, which is a wrapper around screen that defines some useful behaviours) being the first thing I run when SSHing to anywhere then I can reconnect if there are issues. You can set it up to start or reattach automatically, though I’ve never got around to doing that anywhere - there are a number of examples online (this one for instance) if you want to try that.

Merci.

Edit: Merci François, mais je crois que j’ai un grain de sable dans ma belle mécanique. dpkg --configure -a me ramène au même pb: /var/cache/debconf/config.dat is locked by another process

[fran.b]

Regarde par lsof qui possède ce fichier, sinon essaye un ps ax -H pour avoir l’arborescence des processus et flingue. Je fais tout ce genre de truc par screen qui conserve la console si il y a deconnexion.

[PascalHambourg]

Est il possible de récupérer une session SSH, et comment ?

Réponse courte : non.

Réponse longue : en lançant une console virtuelle persistante de type screen sur la machine distante, on peut se reconnecter à cette console cas de perte de la session SSH. Mais ce n’est pas la session SSH qu’on récupère, d’où ma réponse courte négative.

On peut également trouver divers outils ou méthodes pour rattacher un processus dont le terminal s’est coupé à un autre terminal, mais aucun ne semble fiable à 100%, le résultat n’est pas garanti.

[Mimoza]

Il n’est pas possible de récupérer une connexion SSH qui a coupé. Si elle est coupé tous tes process dépendant doivent se tuer normalement, ou au pire ils tombent en zombies.

Pour palier à ce problème il est tout a fait possible d’utiliser “screen” ou sa surcouche “byobu” (c’est ce que je fait).
Quand je me connecte en ssh, on me demande directement si je veux reprendre la session byobu en cours. Donc même si la connexion ssh se coupe, byobu lui continu de tourner tranquillement et je peux le récupérer à tout moment.

[Clochette]

Regarde par lsof qui possède ce fichier, sinon essaye un ps ax -H pour avoir l’arborescence des processus et flingue. Je fais tout ce genre de truc par screen qui conserve la console si il y a deconnexion.

Je préfère un ps faux, mais je garde de côté ta commande fran.B.

Maintenant lol je serais toi je me ferais directement un petit bash.rc ou zsh.rc pour gérer ta connexion à tes machines ou groupes de machines.

J’utilise en exemple pour me connecter directement via l’utilisation de clé dans un screen à tous les serveurs de la dite plateforme.

# pf nom_de_ma_plateforme 

‘pf’ étant un raccourci, j’en profite pour dire qu’un ‘pf list’ me sort la liste des plateforme et qu’un ‘pf update’ me permet de recharger la liste depuis une BDD contenant les accès au différentes machines des différentes plateforme (ce qui permet d’être portable sur plusieurs poste mais centralise la gestion des accès).

Ce qui permet de reprendre même après coupure des transfert ou autre manipulation de gestion ou d’administration.

Je peu filer un exemple dès que je serai de retour au taff (pour l’instant s’est mini congé ).

[lol]

Salut,
Merci pour les réponses. J’ai résolu le problème de dpkg (mais ce n’était un gros soucis):

15400 ? S 0:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/samba-common.postinst configure 2:3.5.6~dfsg-3squeeze8 15420 ? S 0:00 /bin/sh /var/lib/dpkg/info/samba-common.postinst configure 2:3.5.6~dfsg-3squeeze8 15436 ? S 0:00 /bin/bash /usr/bin/ucf --three-way --debconf-ok /var/run/samba/upgrades/smb.conf /etc/samba/smb.conf

[code]# kill 15400

apt-get dist-upgrade[/code]

C’était bien la question subsidiaire qui m’intéressait le plus: Comment ne pas se faire piéger par une coupure dans une opération délicate avec une connexion SSH.

Je retiens donc screen et byobu (que je ne connaissais pas)
Clochette, je suis très intéressé par ta solution, ça a l’air séduisant (et je multiplie les “clients” auxquels il faut que je me connecte, une centralisation serait la bienvenue).

Merci!

PS: Je passerais en résolu quand j’aurais finalisé mes accès avec screen ou byobu.

[lol]

Salut,
J’ai trouvé ceci (il suffisait de chercher, et pas loin en plus)…
taint.org/wk/RemoteLoginAutoScreen

C’est carrément le top!
Comment ais-je pu m’en passer…

[Mimoza]

Byobu te le fait par défaut !
Juste après la connexion il te propose de reprendre le session déjà ouverte ou de basculer sur une console “classique”.

[lol]

[quote=“Mimoza”]Byobu te le fait par défaut !
Juste après la connexion il te propose de reprendre le session déjà ouverte ou de basculer sur une console “classique”.[/quote]
Je viens de le tester, pas mal non plus…
Je vais jouer avec les deux solutions pendant quelque temps, je choisirais celle qui me convient le mieux…

Merci!