Coucou !
Allez, pour ceux qui l'ont raté : https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
En gros, ça part d'un bon gros bug bien sale. C'est vrai, il est moche. Et après ça trolle bien fort sur systemd.
Extrait :
The systemd developers [opte] to cram an enormous amount of unnecessary complexity into PID 1, which runs as root and is written in a memory-unsafe language.
Bref, l'auteur mélange des bonnes idées (comme l'analyse de données utilisateurs dans autre chose que le PID 1) avec tout un tas d'idées trollesques (comme « Systemd is defective by design »)
Ça rend l'article difficile à être convaincant. Néanmoins, c'est intéressant.
# Quoi d’intéressant?
Posté par Zenitram (site web personnel) . Évalué à -7.
C'est sûr, ça va quand même être difficile de convaincre en parlant d'un bug que personne n'a vu en 2 ans alors que c'est en prod partout, pour en faire "defective par design" juste à cause d'une erreur (il saute direct de l’erreur à defective by design)
J'ai arrêté de lire ensuite. e bug sera corrigé et voila.
Si il y a vraiment un truc intéressant, peux-tu donner un "avant-goût"?
[^] # Re: Quoi d’intéressant?
Posté par Christophe . Évalué à 10.
Le bug sera corrigé, mais la critique sur l'exécution de certains traitements au sein du PID 1 reste tout à fait valable. La question qu'il pose "le cœur de systemd est-il trop complexe" est pertinente.
Tu devrais lire le reste, pour une fois c'est (relativement) nuancé, et avec des arguments concrets.
[^] # Re: Quoi d’intéressant?
Posté par Zenitram (site web personnel) . Évalué à -6.
J'ai lu en diagonale, admettons qu'il y a de quoi lire plus sérieusement, mais j'ai bloqué sur :
La, on est dans la même connerie que "defective by design même si tout le monde l'a adopté après en avoir testé d'autres" (mon premier reproche).
Il vend de l'espoir, ce qui ne change rien au problème à résoudre, il ne propose rien.
Tout ce qu'il montre, c'est que systemd est le pire logiciel pour ce taf à l'exception de tous les autres. On est bien avancé. Je n'appelle pas ça quelque chose de nuancé (il tape, mais ne propose rien d'autre qu'un futur hypothétique), à moins que me donne plus de raisons pour que je passe plus de temps à lire malgré les phrases basiques que j'ai vu.
[^] # Re: Quoi d’intéressant?
Posté par Christophe . Évalué à 10.
Tu n'as pas lu en diagonale, tu as cherché la petite bête dans le texte (peut-être inconsciemment). Et si l'alternative future était un systemd dont le coeur a été modularisé, réécrit en Rust, en appliquant des principes comme de toujours choisir les privilèges les plus bas (exemple sur umask(0) ) ? Un coeur plus résistant, sachant s'auto-redémarrer, etc.
Si tu ignore ce genre de critiques, alors tu t'es déjà enfermé dans une bulle.
[^] # Re: Quoi d’intéressant?
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 29 septembre 2016 à 18:10.
Tu expliques autant que lui ce que tu fais en attendant le futur (hypothétique, évidement).
Les besoins sont maintenant, pas dans le futur.
Tu fais comme lui : tu râles et "vends" du rêve, qui ne nourrit personne. C'est tout.
Si tu ignores ce genre de critiques, alors tu t'es déjà enfermé dans une bulle.
[^] # Re: Quoi d’intéressant?
Posté par Christophe . Évalué à 10.
Et bien, en attendant le futur, tu utilises l'existant (systemd), avec ses avantages et ses défauts. C'est évident, non ?
Résumons donc ton point de vue: si on critique (on "râle"), c'est pas la peine de lire. Si on propose (on "vend du rêve"), c'est pas immédiatement fonctionnel. Donc on met des oeillères et on fonce. Voilà, j'ai bien pris en compte ton genre de critiques… Je n'ai pas l'impression d'avoir avancé.
[^] # Re: Quoi d’intéressant?
Posté par Yth (Mastodon) . Évalué à 8.
Sauf que de ce que j'ai compris de son texte, les « better alternatives » ne concernent pas obligatoirement tout systemd, mais les services annexes fournis par systemd, comme le cache DNS qui est son exemple principal.
Et en l'occurrence, il y a de meilleures alternatives dans le passé et dans le présent, pas besoin d'attendre le futur.
C'est pareil pour le NTP, quel rapport avec le système d'init de l'OS ? Et avec une interface perso non standard alors que des standards existent et fonctionnent très bien depuis des décennies, soutenus par des logiciels qui marchent sans aucun problème ?
Ici je découvre un peu l'ampleur de systemd, et je suis heureux de ne pas l'avoir…
Parce que l'avantage majeur que je vois à systemd, c'est un démarrage plus rapide de la machine, ce qui me sert une poignée de fois par an (ça n'accélère pas la sortie de veille ou de veille prolongée, ma machine reboote complètement lors d'un changement de kernel).
Les « produits » annexes genre le redémarrage de démons, ça existe déjà par ailleurs, la valeur ajoutée reste assez faible s'il y en a une.
Vu de l'extérieur, je ne comprend toujours pas l'intérêt de systemd, pourtant j'essaie de piger ! Mais je ne vois pas à quoi ça pourrait bien me servir…
Yth.
[^] # Re: Quoi d’intéressant?
Posté par Sébastien Le Ray . Évalué à 5.
Faut sortir du schéma de pensée où systemd est un système d'init. C'est un ensemble d'outils qui utilise les spécificités offertes par le noyau Linux. L'un de ces outils est un init. Le principal intérêt est d'avoir un système normalisé où les interactions entre les différents composants ne tournent pas au cauchemar (et pour ça il faut faire des choix: renoncer à la portabilité et ne pas chercher à prendre en charge 10 000 outils extérieurs plus ou moins bien conçus)
[^] # Re: Quoi d’intéressant?
Posté par Yth (Mastodon) . Évalué à 10.
Utiliser des trucs spécifiques à Linux, j'approuve.
Même avoir un système d'init non portable qui exploite des spécificités Linux pour faire les choses bien.
Mais pourquoi foutre en l'air la philosophie KISS ?
Pourquoi est-ce que la couche systemd pour son resolveur DNS ne se base pas sur une interface standard - sur laquelle on pourrait brancher n'importe quel resolver - en fournissant à côté un resolveur indépendant, mais Linux-centrique ?
Pourquoi ne pas utiliser ntpd pour le NTP, et fournir à côté une alternative à ntpd non portable ?
De ce que je lis, et personne ne le contredit ici, systemd a un resolveur DNS et un outil NTP intégrés (même s'ils tournent dans des processus séparés), qui ne sont pas remplaçables par des outils existants parce qu'ils se basent sur une interface fabriquée par systemd, non standard, et donc parfaitement susceptible de changer n'importe quand.
Quid de mon choix ?
Systemd c'est forcément un bloc à prendre ou à laisser, et pour profiter de quelques améliorations spécifiques au noyau Linux on se coupe de plein d'outils qui répondent parfaitement à leur fonction, et surtout du choix de l'outil à utiliser ?
C'est cher payer non ?
Yth.
[^] # Re: Quoi d’intéressant?
Posté par Sébastien Le Ray . Évalué à 7.
Parce qu'en fait KISS quand tu essaies de gérer un système complexe comme un OS de base d'aujourd'hui ben ça fini par devenir un amoncellement de rustines infâmes… Alors c'est sûr vu que tout le bordel est caché par les gens qui font les distros on s'en rend pas bien compte, mais bon entre un système où je peux filtrer mes logs avec des requêtes naturelles et une chaîne de grep | grep -v | sed | oh-merde-c-est-encore-un-autre-format-de-timestamp, le choix est vite fait
Cadeau et cadeau
Bah justement c'est ton choix, pour paraphraser Zenitram, ne demande pas aux autres de l'assumer, RedHat et Poettering ont eu le choix entre suivre ta voie et refaire les outils… bizarrement je pense qu'ils ont un tout petit peu réfléchi auparavant. Tu veux plugger les sytèmes existants ? Pas de soucis, t'as juste à rajouter le thin layer pour la compat' DBus. Vu que c'est des outils « KISS » ça doit être trivial non ?
[^] # Re: Quoi d’intéressant?
Posté par benja . Évalué à 6.
Mauvais exemple… Pourquoi un daemon qui n'utilisait pas syslog(3) va se mettre à l'utiliser tout d'un coup ?
PS: si tu as des besoins particuliers au niveau du logging, je pourrais te conseiller quelques solutions qui prédatent systemd/journald. Tu dois juste dire quel est ton use-case réel, pas un exemple inventé qui ne correspond à rien sauf à essayer de justifier ton argumentaire.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quoi d’intéressant?
Posté par benja . Évalué à 2.
;-)
[^] # Re: Quoi d’intéressant?
Posté par louiz’ (site web personnel) . Évalué à 1.
J’ai pas compris. Si ton daemon est lancé par systemd, t’as rien à faire, t’as pas à utiliser syslog(3) ni rien. T’écris sur la sortie standard, et systemd te journalise ça comme il faut¹ avec la date et tout ça.
(C’est d’ailleurs tout l’intérêt que je vois à systemd : c’est lui qui s’occupe de tout la “daemonization”. Le logiciel a juste à se lancer (pas besoin de se forker plusieurs fois, ni d’utiliser daemon(3) à la noix), écrire sur la sortie standard, et tout va bien).
1: « comme il faut », bon, sauf que c’est dans une archive ultra-lente qu’on gère à l’aide d’un logiciel moisi qui met 3 plombes à faire quoi que ce soit (journalctl). L’implémentation pue du cul, mais l’idée est cool.
[^] # Re: Quoi d’intéressant?
Posté par gouttegd . Évalué à 10. Dernière modification le 30 septembre 2016 à 12:11.
Si tu as un problème avec un programme qui utilise « encore-un-autre-format-de-timestamp », c’est que c’est un programme qui ne passe pas par syslog pour écrire ses logs (s’il passait par syslog, il utiliserait automatiquement le même format que tous les autres programmes utilisant syslog).
La question est : pourquoi un programme qui a son propre système de log se mettrait subitement, en présence de systemd, à renoncer à son propre système et à se mettre à juste écrire sur la sortie standard ?
Le problème posé par un tel programme vient entièrement du fait qu’il n’utilise pas le démon journalisateur du système,¹ peu importe que le démon en question soit syslog ou journald. Conséquemment, journald ne changera rien à l’histoire, tu devras toujours te dépatouiller avec les journaux de ce programme avec cet-autre-format-de-timestamp.
Je sais que c’est difficile à croire, mais non, systemd ne résoud pas automagiquement tous les problèmes (et il ne fait pas revenir l’être aimé non plus).
¹ Il peut y avoir de bonnes raisons à ça, là n’est pas la question.
[^] # Re: Quoi d’intéressant?
Posté par galactikboulay . Évalué à 10.
Le point de vue "systemd veut faire trop de choses" est à mon sens pertinent: en quoi est-ce le rôle de systemd de faire resolver DNS (et en plus c'est mal fait apparemment) ou client NTP ? Il y a des projets qui travaillent sur ces points depuis des années, pourquoi vouloir les bypasser ?
[^] # Re: Quoi d’intéressant?
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 29 septembre 2016 à 17:58.
A ma connaissance le PID 1 n'a pas ces fonctionnalités et donc on peut les utiliser, ou pas, c'est juste la au cas où pour des besoins sans se prendre la tête.
Après, l’intérêt, ben je dirai que si un mec est payé (cher) pour faire ça c'est que quelqu'un en voit l'utilité, ce n'est pas à toi d'interdire juste parce que ça ne te plait pas à toi, tu es libre. En plus l'auteur de l'article dit que les logiciels peuvent utiliser la même interface (pas standard? Oui, ben si j'avais dit ça de OpenOffice format, ça aurait hurlé, c'est pas une raison pour hurler à la mort comme l'auteur fait), donc tout est super, tu es libre de proposer une alternative comme tu veux (pas faire comme l'auteur qui hurle mais ne propose rien, genre Devuan).
Ce qui me dérange dans les critiques, c'est le "c'est inutile / pas le bon endroit" sans essayer de comprendre pourquoi des gens passent du temps (et de l'argent) à le faire.
Je te retourne la question :
Ils ont leur raisons, la question serait donc : avez-vous essayé de comprendre pourquoi les logiciels en place n'ont pas plu? ("NIH" pourrait être une réponse, mais encore faut-il s'être renseigné avant de le dire; perso je peux dire "je ne sais pas")
[^] # Re: Quoi d’intéressant?
Posté par shbrol . Évalué à 5.
Merci, j'ai bien ri.
[^] # Re: Quoi d’intéressant?
Posté par Sufflope (site web personnel) . Évalué à 4.
Il a pas dit c'est utile selon l'échelle absolue d'Utilité que voici (par contre apparemment toi tu l'as, cette échelle ?), il a dit quelqu'un en voit l'utilité. Ensuite, les mirages, ça existe.
[^] # Re: Quoi d’intéressant?
Posté par galactikboulay . Évalué à 8.
Je me demande bien dans mon post où j'ai parlé d'interdire quoi que ce soit (déjà je ne vois pas par quel miracle j'aurais ce pouvoir).
Ecrire un client NTP ou un resolver DNS, c'est casse-gueule et ce n'est pas le "coeur de métier" de systemd. Si les développeurs systemd avaient un besoin spécifique, ça me paraissait effectivement plus logique d'aller discuter avec des projets existants que de réinventer la roue. L'ont ils fait et/ou ont ils d'autres arguments je ne sais pas non plus, mais ce genre de discussion n'est pas forcément publique ou facile à retrouver.
Après, même remarque que celle que j'ai faite plus bas: en quoi un client NTP ou un resolver DNS devraient-ils être spécifiques systemd ?
[^] # Re: Quoi d’intéressant?
Posté par Renaud . Évalué à 10.
"en quoi est-ce le rôle de systemd de faire resolver DNS"
De tous les reproches que l'on peut faire à systemd, je pense que c'est bien le moindre. La résolution de noms est devenue quelque chose de chaotique sous Linux. Si tu fais un gethostbyname("foo"), il faut regarder dans /etc/hosts, demander éventuellement à mDNS (avahi?), demander au serveur DNS local, etc… Le resolveur de la glibc tente d'avoir une architecture "ouverte" pour rajouter d'autres méthodes plus ou moins dinosauresques (telles que NIS ou WINS) et c'est en partie à cause de lui qu'il est peu recommandé / impossible de faire des binaires statiques sous Linux.
Le problème pour un dévelopeur c'est que tellement de couches ont été empilées que gethostbyname() devient dangereux à utiliser. Lorsque je codais encore (je suis vieux maintenant :), on a commencé à remarqué des problèmes de stabilité énorme dans notre programme multithreadé, pour réaliser que le resolveur WINS (installé rarement mais chez certains clients) n'était pas thread-safe. Ensuite on a du patcher à la volée la glibc pour interdire la lecture de /etc/hosts car on a aussi remarqué que dans un environment hautement multi-threadé, ouvrir le fichier et le lire bloquait notre programme (sans parler de la performance). Et difficile de diagnostiquer le problème—à la fin, gethostbyname() c'est un mini programme qui tourne dans le contexte de notre programme, avec ses allocations de mémoire, etc… Et il y a d'autres problèmes—notre programme fait énormément d'I/O réseau sur un grand nombre de sockets, je ne peux pas appeler select() (limite MAX_FD), je n'ai pas de garantie que gethostbyname() ne le fasse pas, je peux juste espérer que les développeurs de la glibc (et des modules dynamiques!) codent proprement et utilisent poll().
Du coup, il est 100 fois plus propre de modifier gethostbyname() pour envoyer un simple message à un resolveur local et d'attendre la réponse plutôt que d'allouer de la mémoire, ouvrir des fichiers et des sockets, etc… Et comme on ne veut absolument pas que le resolveur local soit en panne, autant le mettre dans systemd :)
Voilà, c'était mes 2 centimes.
(Disclaimer: je n'ai aucune action systemd et je ne gère aucun système le faisant tourner :)
[^] # Re: Quoi d’intéressant?
Posté par gouttegd . Évalué à 10. Dernière modification le 29 septembre 2016 à 20:45.
Déjà, si le développeur utilise
gethostbyname, le premier problème est qu’il a au moins quinze ans de retard. Cette fonction était déjà deprecated à la sortie de POSIX.1-2001.Ah bon. Moi je trouve 100 fois plus propre d’écrire
nameserver 127.0.0.1dans/etc/resolv.confet d’installer un quelconque résolveur DNS standard en écoute sur localhost. Pas besoin ni de modifiergethostbyname, ni d’ajouter une fonction de résolution DNS à un programme dont ce n’est pas le job.Que systemd se contente de démarrer et monitorer le résolveur DNS, ça c’est son boulot.
[^] # Re: Quoi d’intéressant?
Posté par Renault (site web personnel) . Évalué à 1.
Je ne comprends pas, on reproche à systemd de ne pas se conformer à POSIX, de remettre en cause 40 ans d'architecture logicielle, etc. Alors qu'en fait, il est peut être plus proche de l'origine que bien d'autres programmes. :o
[^] # Re: Quoi d’intéressant?
Posté par Renaud . Évalué à 1.
s/gethostbyname/getaddrinfo/g—j'avais oublié que sur LinuxFR, il est plus important de pinailler sur les détails que sur le fond, merci de me le rappeler. (il y a aussi des fautes d'orthographe/conjugaison dans mon message précédent)
Le coeur du problème que j'essayais de soulever, c'est que la résolution de noms, ça n'est pas forcément DNS de nos jours. Il y a d'autres mécanismes (mDNS, etc…) et on veut TOUT déléguer à un tiers, pas juste DNS. Mais oui, un service dont la présence est garantie par systemd ça ne me gêne pas. Le problème c'est que personne ne semble se pencher sur ce problème, systemd est le seul a se diriger vers cette architecture.
[^] # Re: Quoi d’intéressant?
Posté par shbrol . Évalué à 10.
Est-ce vraiment du pinaillage ? Dans la section 'attributes' du man de ces deux fonctions on a:
gethostbyname Thread Safety MT-Unsafe race:hostbyname env localegetaddrinfo Thread Safety MT-Safe env locale
alors forcément, si tu as des problemes après avoir utilisé la première dans un programme multi-thread, c'est pas fait pour surprendre. Avec la seconde, c'est plus surprenant.
[^] # Re: Quoi d’intéressant?
Posté par Renaud . Évalué à 3.
Oui, on utilise getaddrinfo() depuis le début. La fonction peut appeler gethostbyname(_r)() ensuite. Ou peut être pas, une fois qu'on regarde l'implémentation de ce code on commence à douter de tout de toute façon.
Mais bonne remarque :)
[^] # Re: Quoi d’intéressant?
Posté par galactikboulay . Évalué à 3.
Effectivement, déléguer cette résolution de nom à un programme tiers dédié parait être la bonne approche. Maintenant, pourquoi intégrer ce morceau obligatoirement dans systemd alors que celui-ci n'est pas portable ? Avoir un resolver capable de gérer du DNS, du mDNS, du /etc/hosts, du WINS, etc. ça peut intéresser d'autres systèmes, je ne vois pas pourquoi ça devrait être spécifique systemd. Ca rejoint un peu la problématique "udev" déjà évoquée par le passé.
[^] # Re: Quoi d’intéressant?
Posté par Sufflope (site web personnel) . Évalué à -1.
Ah merde je pensais que systemd mettait tout dans PID 1.
[^] # Re: Quoi d’intéressant?
Posté par galactikboulay . Évalué à 4.
Et c'est quoi le rapport avec le n° du PID dis-moi ? Est-ce j'ai dit que systemd est un seul gros blob tournant sous la forme d'un seul process ?
[^] # Re: Quoi d’intéressant?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 1.
Toi non, mais le blogpost lié dans le journal, oui.
[^] # Re: Quoi d’intéressant?
Posté par karteum59 . Évalué à 5.
Donc c'est un souci sur l'implémentation glibc de gethostbyname()/getaddrinfo() et non sur l'API, si je comprends bien ? Pas grave, suffit de changer de crêmerie.
Ah oui, sauf que…
[^] # Re: Quoi d’intéressant?
Posté par Laurent Mouillart . Évalué à 4.
Il l'est : https://bugzilla.redhat.com/show_bug.cgi?id=1380286
[^] # Re: Quoi d’intéressant?
Posté par dyno partouzeur du centre . Évalué à 7.
Si j'ai bien compris, n'importe qui a un shell non privilégié sur à un serveur de prod tournant sous RHEL peut planter le serveur. J'avoue que je trouve "medium" un peu underrated. Pour moi c'est un bug critique.
[^] # Re: Quoi d’intéressant?
Posté par Quinane . Évalué à 1.
Je suis bien incapable d'intervenir sur le sujet directement, à peine de comprendre un peu. Donc je m'abstiens sauf pour mentionner le post de Clément Lefèbvre, fondateur de Linux Mint qui parle de FUD sur Mint, Ubuntu (& Amazon) et aussi Systemd. Cela dit en substance de ne parler qu'en connaissance de cause. Une évidence qu'il estime devoir rappeler.
sur Segfault
[^] # Re: Quoi d’intéressant?
Posté par Dabowl_75 . Évalué à 0.
RHEL 7
# t'as besoin d'un dico
Posté par Guillaume Knispel . Évalué à -4.
et confondre un argumentaire technique trivialement convainquant avec du trolling, ça relève de quoi exactement ? d'ineptie technique ?
[^] # Re: t'as besoin d'un dico
Posté par benja . Évalué à -2.
Marrant la note de ton commentaire :D (ou pas… on se croirait en plein meeting politique) J'imagine que les premiers à crier au complot anti-systemd sont malheureusement aussi les derniers à savoir argumenter.
[^] # Re: t'as besoin d'un dico
Posté par Storm . Évalué à 2.
Je ne suis pas inapte techniquement (c'est moi qui le dit, donc faut me croire !), et pour moi c'est du troll (encore moi qui le dit, alors faut me croire !).
# Serveur DHCP
Posté par jfmartin . Évalué à 3.
J'ai appris récemment que systemd incluait aussi un serveur DHCP.
Enfin systemd-netword l'inclut pour être exact.
[^] # Re: Serveur DHCP
Posté par Christophe B. (site web personnel) . Évalué à 10.
Et alors emacs aussi … ou est le problème
Le TROLL du XXIeme siecle => Emacs vs systemd
eh oui on est dredi :)
[^] # Re: Serveur DHCP
Posté par Sufflope (site web personnel) . Évalué à 1.
systemd le projet oui. À ce compte-là, OpenBSD ou même Debian en tant que projet incluent des serveurs DHCP. systemd le binaire PID 1 fourni par le projet systemd, non.
# Réponse d'un dev systemd
Posté par Christophe . Évalué à 3.
David Strauss, un des développeurs de systemd, répond à tout ça ici:
https://www.facebook.com/notes/david-timothy-strauss/how-to-throw-a-tantrum-in-one-blog-post/10108242959884190
C'est une réponse assez complète. Les points faibles de l'argumentation sont pointés du doigt, même si on peut regretter quelques attaques ad-hominem et une tendance à minimiser les points forts soulevés ("c'est subjectif", "ça ne justifie pas l'abandon de systemd", "c'est pas si critique que ça"…).
[^] # Re: Réponse d'un dev systemd
Posté par Glandos . Évalué à 3.
Une meilleure adresse : https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d
[^] # Re: Réponse d'un dev systemd
Posté par Glandos . Évalué à 4.
Et enfin, une bonne conclusion, avec laquelle, je n'ai pas peur de le dire, je suis bien d'accord : https://www.scrye.com/wordpress/nirik/2016/10/01/how-to-reignite-a-flamewar-in-one-tweet-and-i-still-dont-get-it/ (Lien envoyé par un membre timide qui ne voulait pas l'envoyer lui-même ;) )
Je vous laisse lire, bande de flemmards. Bon, c'est vrai, c'est un peu pédant pour ceux qui ne lisent pas l'anglais.
# systemctl reboot --force --force
Posté par Sylvain Blandel . Évalué à 3.
Le bug est présent chez moi (Archlinux 64 bits, noyau 4.7.5, systemd 231-1).
La boucle suivante rend mon système « instable » :
while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; doneCe bug fonctionne même lorsque cette commande est lancée par un simple utilisateur ; et le système reste instable lorsqu'on est sorti de cette boucle avec un
Ctrl+CPour redémarrer, la commande
systemctl rebootne fonctionnait pas, je m'en suis sorti avecsystemctl reboot --force --force(attention, cela correspond à un redémarrage brutal).Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.