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