Qui a tué screen et tmux sur mon VPS ?

Publié le mer. 26 septembre 2012 par Feth Arezki

TL; DR [*]

Sur les VPS de type kimsufi, screen ou tmux ne fonctionnent pas toujours : c'est parce qu'udev ne fonctionne pas. Sautez au paragraphe "La rustine" pour la solution.

Un VPS bien mérité

Je m'étais loué un VPS pour mes loisirs. C'est économique et ils en font en Debian stable. 500 Mo de RAM ce n'est pas beaucoup, mais pour ce que je comptais en faire c'était déjà trop. Une fois en possession des clefs, je lui donnai un petit nom (non, pas Samsufi, quand même) et réaménageai /etc/apt/sources.list afin de me sentir un peu chez moi dans la simplicité du confort moderne :

deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free

J'enclenchai la mise à jour avec aptitude, qui ne me demanda qu'une fois mon avis, et, après un long voyage à travers d'épaisses couches géologiques (Debian stable et testing), le système émergea enfin dans le présent de l'informatique.

Je triturai un peu la serrure avec FwBuilder, créai un utilisateur nommé 'fwadmin' et remisai les outils dans un gitolite. Tout allait bien, on allait pouvoir commencer à profiter du lieu.

tmux claqué, screen grillé

Tout allait trop bien ; et j'avoue que je trouvais ça louche. J'installai et lançai tmux ; le programme quitta immédiatement : c'était donc ça l'embrouille.

~$ tmux
~$ #argh

Je relançai tmux, qui rendait la main obstinément. Statut 1. Hm.

Pourquoi ne pas essayer screen ?

Lui aussi se terminait instantanément : décidément, la vie est difficile pour les gestionnaires de terminal sur ce VPS : screen réinitialisait le terminal et me narguait dans son agonie.

[screen is terminating]

Je me doutais qu'il s'était passé quelque chose avec les permissions, puisque ça fonctionnait en root. Et malheureusement, je ne voyais pas comment débrouiller cela puisque même strace ne m'était d'aucun secours : un programme setgid (ici utmp) perd son super gid s'il est poursuivi par strace [†].

Où, d'un mince indice, l'on déroule la pelote jusqu'au noyau

Après une longue recherche, c'est grace à l'aide de #debianfr sur freenode que je trouvai la trace du coupable, en vérifiant minutieusement les permissions de fichiers périphériques dont j'ignorais l'existence pour certains.

Voilà :

crw-r--r-- 1 root root 5, 2 sept. 26 19:22 /dev/ptmx

À comparer avec les permissions attendues

crw-r--rw- 1 root root 5, 2 sept. 26 19:55 /dev/ptmx

ptmx ? je ne connaissais pas, mais Debian contient une page de man très claire (ptmx(4)) [‡]:

Le fichier /dev/ptmx est un fichier spécial caractère
avec un numéro majeur 5 et un numéro mineur 2,
habituellement en mode 0666, appartenant à root.root.
Il sert à créer une paire de pseudoterminaux maître et esclave.

Je pense que p signifie pseudo, t signifie terminal, et mx multiplexeur.

Comment ceci fonctionne-t-il ?:

Lorsqu'un processus ouvre /dev/ptmx, il reçoit un descripteur
de fichier pour le pseudoterminal maître (PTM),
et un périphérique est créé pour le pseudoterminal esclave (PTE)
dans le répertoire /dev/pts. Chaque descripteur obtenu
en ouvrant /dev/ptmx est un PTM indépendant avec son PTE associé,
dont le chemin d'accès peut être obtenu en passant le descripteur à ptsname(3)
[...]

Le coupable était udev, qui, ne démarrant pas, ne faisait pas ce que demande la ligne suivante de /lib/udev/rules.d/91-permissions.rules

KERNEL=="ptmx",                 MODE="0666",    GROUP="root"

Et pourquoi ne démarrait-t-il donc pas, udev ?

~$ sudo /etc/init.d/udev restart
[sudo] password for feth:
[FAIL] udev requires hotplug support, not started ... failed!
failed
~$ #gasp

Tout était clair maintenant. Le noyau du VPS avait été compilé au plus secret du labo OVH sans le support de hotplug, or le script d'init vérifie que ce support est présent. J'eus un frisson en imaginant ce qui se serait passé avec systemd !

La rustine

Je ne pouvais vaincre le problème définitivement et avec certitude à ce stade ; en tout cas pas sans redémarrer le système. Mais je pouvais l'empêcher de nuire simplement, et c'est ce que je fis en insérant la ligne suivante dans /etc/rc.local (avant exit 0) :

chmod 0666 /dev/ptmx

Enfin tranquille ?

Vais-je enfin goûter le repos dans mon cher VPS ? Peut-on installer un noyau standard sur ces petits joujous ?

Mise à jour [§]: non, les VPS ne booteront pas de kernel personalisé. Ce sont des OpenVZ, sans modules.

~# aptitude install virt-what
...
~# virt-what
vmware
openvz
~# # Voilà : openvz

Merci !

Merci à cthuluh et luxman pour leur aide dans le déplombage, et un grand bravo à enikar pour avoir trouvé ce qui clochait et m'avoir dit où taper !

Je cède la parole à ce dernier pour la conclusion :

<enikar> et un truc que je conseille à tous ceux qui ne connaissent pas les bases d'unix : http://www.linux-kheops.com/doc/dalox/unix01.htm

[*]Too long; did'nt read / trop long, je n'ai pas lu
[†]On peut aussi créer un utilisateur jetable appartenant au groupe cible, ici utmp.
[‡]Auteurs francophones de man ptmx: Christophe Blaess (1996-2003), Alain Portal (2003-2006). Simon Paillard et l'équipe francophone de traduction de Debian (2006-2009).
[§]Merci à misc pour l'info.