Grosse fatigue
Bonjour à tous,
Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment,
toutes les applications en cours (me contraignant à repartir de la
sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de
travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au
milieu du chemin, tuant X mais surtout pas les terminaux de contrôles
dépendants de X :
top - 09:03:05 up 3 days, 53 min, 19 users, load average: 48,54, 25,93,
14,15
...
KiB Mem : 65562712 total, 5298100 libr, 24405232 util, 3078024 tamp/cache
KiB Éch : 10066329+total, 71624128 libr, 29039160 util. 7755600 dispo Mem
...
76791 bertrand 20 0 10108 2468 1660 R 76,2 0,0 13:08.04
bash
2418 bertrand 20 0 9988 1792 1648 R 75,2 0,0 13:06.32
bash
79309 bertrand 20 0 9988 2432 1640 R 75,2 0,0 13:30.25
bash
307331 bertrand 20 0 9988 2604 1812 R 75,2 0,0 13:06.87
bash
422686 bertrand 20 0 10104 2564 1768 D 75,2 0,0 13:08.79
bash
475927 bertrand 20 0 10252 2508 1688 R 75,2 0,0 13:08.96
bash
477249 bertrand 20 0 10172 2460 1652 R 75,2 0,0 13:29.82
bash
2114 bertrand 20 0 10108 2016 1680 R 74,3 0,0 13:09.14
bash
2122 bertrand 20 0 10108 2056 1716 D 74,3 0,0 13:09.67
bash
3684 bertrand 20 0 9988 1808 1672 R 74,3 0,0 13:02.70
bash
4944 bertrand 20 0 9988 1892 1732 R 74,3 0,0 13:02.49
bash
77325 bertrand 20 0 9988 2580 1780 R 74,3 0,0 13:10.73
bash
103189 bertrand 20 0 10808 3064 1712 R 74,3 0,0 13:02.45
bash
309027 bertrand 20 0 9988 2496 1708 R 74,3 0,0 12:59.61
bash
429272 bertrand 20 0 10104 2532 1736 R 74,3 0,0 13:08.76
bash
en laissant des zombies partout, des fichiers à moitié ouverts et
corrompus ! Je ne vous ai pas mis toute la liste, la charge est
uniquement due aux bash qui tournent la poignée dans le coin sans rien
faire puisqu'ils ne sont plus associés à un terminal. Le swap de s'est
rempli qu'_après_ que X a été tué par systemd.
Cette machine n'a aucun problème matériel. Je l'ai testée en long, en
large et en travers.
J'avoue que ça commence sérieusement à me fatiguer. systemd se permet
de tuer la session X sans aucune raison (rien dans les logs sinon un
truc du style systemd: kill X). Je tourne en testing à jour pour tout un
tas de raisons que je n'expliciterai pas ici.
Sur ces entrefaites, je passe ne console texte et je m'aperçois que
trois paquets ne peuvent s'installer. Comment ça ? Pour mémoire,
"unattented-upgrade" _N_'est _PAS_ configuré parce que j'ai une version
de KiCAD et une autre de FreeCAD en rolling releases (et
qu'accessoirement lorsque le truc décide de mettre à jour LaTeX, le
réseau rame durant plusieurs heures parce que la station de travail est
diskless). La seule chose qui est faite, c'est un apt update la nuit.
Les mises à jour automatique mettent un bazar là-dedans et je préfère
toujours les passer à la main quand je sais que je ne dérangerai personne.
Je tente donc un apt dist-upgrade et là, je vois que le truc veut
m'installer usrmerge. Mais pour tout un tas de raisons, JE NE VEUX PAS
DE CETTE SALETÉ. Pourquoi ? Toute mon installation est diskless et/ou
embarqué et usrmerge met un bazar incommensurable là-dedans. Pour une
installation diskless, ça multiplie les latences (regardez un peu le
trafic sur un NFS/TCP, c'est effarant) et dans l'embarqué où / et /usr
ne sont pas sur les mêmes partitions, ça oblige à des contorsions pour
espérer démarrer correctement jusqu'au bout.
Est-il possible de refuser usrmerge ? Ou faut-il que j'envisage de
réinstaller cette machine sous autre chose, autre chose qui n'utilise ni
systemd vus les dysfonctionnements du truc ni usrmerge ? D'ailleurs
existe-t-il encore une distribution Linux sans usrmerge ?
À titre personnel, je ne comprends toujours pas que Debian cherche à
imposer systemd vue la fiabilité de la chose dès lors qu'on n'est plus
sur un poste de travail avec un disque en local (la gestion des timeouts
réseau ou des accès réseau concurrents au sens large est... rigologène
pour rester poli et surtout non reproductible d'une version à l'autre).
Quant à ursmerge, dans l'embarqué, on préférerais avoir un répertoire
/rescue à la NetBSD et un /usr séparé pour toujours pouvoir démarrer un
système minimal même lorsque la partition /usr est plantée (/ pouvant
rester en lecture seule). Là, si /usr est corrompue pour une raison ou
pour une autre, on n'est même pas sûr de réussir à démarrer le système
(sauf à se retrouver dans un shell embarqué dans le fumeux initramfs).
Merci pour toutes vos suggestions,
JKB
Reply to: