BERTRAND Joël <joel.bertrand@systella.fr> wrote on 23/09/2022 at 09:41:24+0200: > 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 Une ligne de log, quelque chose qui montre que systemd a bien tué X et éventuellement pourquoi, ou bien on est juste sur yet another mail de baseless FUD? -- PEB
Attachment:
signature.asc
Description: PGP signature