Journal rm -rf tue votre bios UEFI

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
32
2
fév.
2016

Hello les manchots, bien la banquise ?

Bon j'ai pas vue de journal sur le sujet et cela me parait important.

Un bug à été ouvert sur systemd concernant les bios UEFI.
https://github.com/systemd/systemd/issues/2402

Systemd monte en lecture/ecriture les variables UEFI dans /sys

Si on fait un rm -rf /, alors on supprime une partie du bios UEFI avec briquage de la carte mere à la clef.

Le bug à été fermé par L.P soit disant que l'on peut niquer aussi son systeme en faisant des choses dirty sur /dev/sda…
Alors que bon il y a un fossé entre détruire les données d'un disque dur et detruire le bios d'une carte mere qui empeche meme le pc de boot.

A votre avis ?
Sur phoronix il y a un debat sur le faite que c'est plutot un bug kernel que systemd.

Source:http://phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory

  • # Tous coupables

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 02 février 2016 à 15:59.

    A votre avis ?

    LP y va bourrin en mettant la chose par défaut, et son excuse est bidon, on flingue les données avec sda, pas le matos lui-même. Dommage que LP y aille parfois aussi bourrinement, ça donne de l'eau au moulin de ses détracteurs
    Les distros seraient coupables si elles n'appliquaient pas un patch pour mettre en lecture seule par défaut en paliatif
    les constructeurs de CM qui ne doivent pas laisser le logiciel faire n'importe quoi, et/ou prévoir un "reset", ils sont coupables si ils ne prévoient pas un reset. Donc à eux de gérer aussi, si il ne le font pas déjà (il y a vraiment de CM qui ne permettent pas de remettre à défaut le BIOS de nos jours?)

    • [^] # Re: Tous coupables

      Posté par  . Évalué à 10.

      Matthew_Garrett qui travaille sur le code UEFI dans le noyau n'est pas d'accord avec toi:
      https://twitter.com/mjg59/status/693494314941288448:

      systemd is not responsible for allowing kernel code that I wrote to destroy your shitty firmware. I think you get to blame me instead.

      Traduction:

      systemd n'est pas responsable de laisser le code que j'ai écrit dans le noyau détruire votre firmware merdique. Je pense que vous devriez m'accuser moi, plutôt.

      Selon lui, c'est bien le kernel qui devrait protéger l'UEFI et pas systemd qui devrait le mettre en read-only (ce qui pourrait poser des problèmes à certaines applications).

      Ceci dit, taper "rm -rf --no-preserve-root /" par erreur, c'est pas de bol.

      Pour se protéger de "rm -rf /*", une bonne idée, c'est :
      alias rm="rm --one-file-system"

      • [^] # Re: Tous coupables

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 02 février 2016 à 16:28.

        Matthew_Garrett qui travaille sur le code UEFI dans le noyau n'est pas d'accord avec toi

        Argh, je l'avais oublié dans ma liste.
        Oui, lui aussi coupable.

        Selon lui, c'est bien le kernel qui devrait protéger l'UEFI et pas systemd qui devrait le mettre en read-only (ce qui pourrait poser des problèmes à certaines applications).

        C'est la où je ne suis pas d'accord : il et tu parlent que d'un point de sécurité. De mon point de vue, la sécurité est collégiale : si un merde, un autre doit empêcher la connerie. Comme aujourd'hui des CM ont un "dual BIOS" etc… C'est la récupération d'incident, c'est la double capote ou tout ce que tu veux comme image de double quelque chose.

        Matthew_Garrett fait une connerie, OK, il corrige, OK, mais la connerie aurait dûe être contenue dans son impact (rest de la CM et hop, pas tout le monde qui peut faire rm / sur l'EFI alors que ce n'est pas utile etc…) avant cette correction. C'est la base de la sécurité (on a bien du chroot, SELinux… Si on considère un seul coupable, il faut arrêter d'utiliser ces outils inutiles car doublons; je ne crois pas que beaucoup de monde va être d'accord, donc gardons les autres coupables avec Matthew_Garrett, il n'est qu'un coupable parmi d'autres sans mettre de "niveau" sur les coupables. Et si on veux être plus sympa, on peut dire "responsable" à la place).

    • [^] # Re: Tous coupables

      Posté par  (site web personnel) . Évalué à 10.

      on flingue les données avec sda, pas le matos lui-même

      En fait même pas, l’argument de Lennart est encore plus falacieux que cela, rm /dev (comparé à rm /sys) ne flingue même pas les données, ça t’oblige seulement à rebooter…

      et son excuse est bidon

      Clairement bidon ! Il écrit par ailleurs :

      Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.

      Donc, il choisit consciemment de laisser un fichier modifiable 100% du temps chez tout le monde pour le cas où un jour quelqu’un a besoin de demander à redémarrer dans le firmware depuis sa distro… C’est complètement taré… Il suffirait très simplement que sa commande systemctl reboot --firmware remonte temporairement le système de fichier de configuration uefi le temps de configurer cela…

      Aussi, d’autres mécanismes de sécurités peuvent être mis en place, par exemple pour dumper le vbios de ma carte graphique (on ne parle ici que de lecture seule, hein !) je dois faire cela :

      cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

      Voir à ce sujet sysfs-pci.txt :

      The 'rom' file is special in that it provides read-only access to the device's ROM file, if available. It's disabled by default, however, so applications should write the string "1" to the file to enable it before attempting a read call, and disable it following the access by writing "0" to the file. Note that the device must be enabled for a rom read to return data successfully. In the event a driver is not bound to the device, it can be enabled using the 'enable' file, documented above.

      Voyez le echo 1 ? c’est l’action « hey, je vais faire un truc inhabituel, mais je sais ce que je fais », c’est un peu comme le flag --yes-i-know-what-i-am-doing de hdparm.

      L’option UEFI utilisée par Systemd pourrait utiliser des mécanismes similaires.

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Tous coupables

      Posté par  (site web personnel) . Évalué à 1.

      LP y va bourrin en mettant la chose par défaut, et son excuse est bidon, on flingue les données avec sda, pas le matos lui-même.

      Non, son excuse c'est que certains applications ont besoin d'accéder en lecture/écriture.

    • [^] # Re: Tous coupables

      Posté par  . Évalué à 4.

      on flingue les données avec sda, pas le matos lui-même

      On ne peut pas briquer un disque dur avec hdparam ?

  • # Et...

    Posté par  (site web personnel) . Évalué à 10.

    Deleting /sys/firmware/efi/efivars/ should thrash your EFI configuration,
    but in a properly implemented EFI this should be recoverable.

    Le point important est là non? Carte mère moisie…

  • # ni kernel ni systemd mais UEFI

    Posté par  . Évalué à 10.

    Moi j'ai plus l'impression que le probleme c'est UEFI qui permet de faire des choses tellement cool que l'on peut arriver a ce genre de manip et exploser son BIOS(UEFI)

    • [^] # Re: ni kernel ni systemd mais UEFI

      Posté par  (site web personnel) . Évalué à 10.

      Bof, un BIOS aussi ça peut se briquer depuis son système d'exploitation, il suffit d'y flasher de la merde.

      La différence, c'est qu'un UEFI expose une structure bien plus sympa, qui du coup peut se monter comme un système de fichiers, ce qui est très pratique et par conséquent largement utilisé. Le problème, c'est que ça implique de monter en lecture-écriture des trucs issus de l'UEFI, ce qui rend beaucoup plus facile de tout bousiller.

  • # Solution

    Posté par  (site web personnel) . Évalué à 8.

    Lennart donne lui-même la solution : si on veut protéger son UEFI en mettant ses variables en lecture seule en usage normal, il suffit de mettre une entrée appropriée dans /etc/fstab.

    • [^] # Re: Solution

      Posté par  . Évalué à -7.

      Ne pas installer systemd c'est une autre solution.

      • [^] # Re: Solution

        Posté par  (site web personnel) . Évalué à 6.

        Ne pas installer systemd c'est une autre solution.

        Rien à voir ! Je n'ai pas systemd, et mon Ubuntu a les variables UEFI en lecture/écriture (pour root).

        Et puis de toutes façons, root il s'en fout normalement des attributs de lecture/écriture. chmod 0 et root passe quand même, root c'est plus fort que toi (sauf si le noyau dit non, ce qui devrait être le cas pour certaines variables UEFI).

        Et puis je suis bien content de pouvoir écrire dans certaines variables UEFI, ça m'a permis de récupérer 700 Mo de RAM que le BIOS avait "perdu" à cause d'un bug idiot dans chez Intel. (Il m'en reste 200 ou 300 Mo à reprendre d'ailleurs, mais c'est pas facile.)

        • [^] # Re: Solution

          Posté par  . Évalué à 10.

          Et puis de toutes façons, root il s'en fout normalement des attributs de lecture/écriture

          Pas ceux du système de fichier lui-même (ce dont il est question ici), essaie un mount -o remount,ro /tmp et essaie d’écrire en root dans /tmp, tu verras que tu vas te faire jeter.

    • [^] # Re: Solution

      Posté par  (site web personnel) . Évalué à 10.

      Non, c’est pour pouvoir flinguer son système qu’on devrait mettre une entrée dans le fstab (i.e. devoir débrayer explicitement les choses quand on sait qu’on prend un risque).

      Perso j’utilise pas EFI, mais il y a quelques moi j’ai fait une connerie, j’ai voulu supprimer une arborescence que j’utilisais pour un chroot, et en fait j’avais mal (c’est à dire pas) démonté des montages en bind à l’intérieur. Bref, quand j’ai fait rm -Rf monchroot/ j’ai rincé /dev, /sys etc.

      Si j’avais été sur une machine comme citée dans le ticket et utilisateur d’UEFI, j’aurai définitivement briqué ma machine.

      Les systèmes /dev, /sys, /proc etc. sont sensé être peuplés au démarrage avec des entrées vers diverses choses, mais pas monter un réel système de fichier. Rincer /sys ne devrait supprimer que ces entrées, pas supprimer des choses en vrai dans une quelconque mémoire de stockage.

      Le problème pose plusieurs questions, notamment celle d’avoir ces montages en écriture par défaut, et celle de monter un système de fichier sous un dossier de /sys. Vous mettriez /boot dans /sys vous ? Ben là c’est un peu pareil (mais en pire vu que c’est pas remplaçable)…

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Solution

        Posté par  (site web personnel) . Évalué à 10.

        NB: pour ma boulette, j’ai eu juste à rebooter pour récupérer un système fiable, c’est ce que j’attends de /dev, /sys etc.

        ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Solution

        Posté par  . Évalué à 3.

        Je me demande si tu n'aurais pas été sauvé par une config de cgroups ou de selinux.

  • # Abstraction des variables dans le système de fichier

    Posté par  . Évalué à 4.

    À mon avis, le problème se situe dans la manière dont le noyau rend accessible ces variables.

    On peut déjà se demander s’il est bien opportun de les mettre dans le système de fichiers; le noyau pourrait proposer une API à base d’ioctl pour les manipuler. Ça empêcherait toutefois la modification des variables depuis un script shell (sauf à proposer un exécutable dédié à cette tâche).

    Une autre solution, qui garderait le mapping des variables dans le système de fichier mais résisterait aux rm intempestifs serait d’empêcher la suppression des pseudo-fichiers de variable et de fournir un fichier delete_var dans lequel on puisse écrire le nom d’une variable pour la supprimer. Ça se rapprocherait d’ailleurs du fonctionnement de /sys/class/gpio.

    • [^] # Re: Abstraction des variables dans le système de fichier

      Posté par  (site web personnel) . Évalué à 2.

      Ça empêcherait toutefois la modification des variables depuis un script shell

      Ou à la main, avec un bon vieux coup de xxd. Ça m'a déjà été bien utile pour récupérer de la RAM "perdue" par le BIOS, alors qu'avec des ioctl, c'est sérieusement moins abordable. Bref, c'est très bien de les avoir sous forme de fichiers, faut juste faire attention à pas déconner en root.

    • [^] # Re: Abstraction des variables dans le système de fichier

      Posté par  (site web personnel) . Évalué à 9.

      À mon avis, le problème se situe dans la manière dont le noyau rend accessible ces variables.

      On peut déjà se demander s’il est bien opportun de les mettre dans le système de fichiers;

      Perso je suis très content du paradigme « tout est fichier », et s’il vous plaît, que cela ne change pas trop vite… Le problème ici n’est pas dans le fait que ce soit exposé comme des fichiers, mais quels sont les droits par défauts sur ce fichiers (i.e. qu’il n’y ai aucun garde-fou, quelque soit la manière dont ce soit exposé).

      ce commentaire est sous licence cc by 4 et précédentes

  • # Boulette

    Posté par  . Évalué à 6.

    C'est une énorme boulette pour Linux (le noyal).
    Limite une faille.
    Péter sa carte mère en faisant l'équivalent d'un format c: même sous Windows on a jamais vu ça.

    • [^] # Re: Boulette

      Posté par  (site web personnel) . Évalué à 0.

      Péter sa carte mère en faisant l'équivalent d'un format c: même sous Windows on a jamais vu ça.

      … :

      Matthew says with about 20 lines of code on Windows, you can cause the same havoc

      … Chez Microsoft, aussi.

      Comme quoi, SystemD ne serait pas seul coupable.

      Le premier de la chaîne étant étant le fabricant de la carte mère ?

      • [^] # Re: Boulette

        Posté par  . Évalué à 10.

        20 lignes de code dédié pour le faire volontairement, ce n'est pas la même chose qu'une simple commande qui le fasse involontairement. Même si, on est d'accord, il serait mieux que la carte-mère n'autorise pas à la flinguer depuis du code logiciel.

        • [^] # Re: Boulette

          Posté par  . Évalué à -9.

          On est en droit de se demander aussi pourquoi rm accepte / comme argument sans demander de confirmer 2 fois qu'on fait pas une connerie.
          Et quiconque tape rm -rf / et valide n'a qu'a s'en prendre a lui meme si quelque chose d'innatendu arrive, pour etre tout a fait honnete.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Boulette

            Posté par  . Évalué à 10.

            Faut pas exagérer… L'utilisateur est en droit de s'attendre à ce que rm -rf / n'affecte que le contenu du disque dur plutôt que le hardware.

            • [^] # Re: Boulette

              Posté par  . Évalué à -2.

              C'est discutable.
              Cmd backspace dans le finder, oui, clairement.

              En root, en ligne de commande dans un systeme ou tout est fichier (et dont la communaute repete a qui veut l'entendre que c'est genial le tout fichier), sur une commande pareille (qui est quand meme deja super limite pour commencer), c'est vachement plus dur de venir se plaindre.
              En tout cas, clairement pas sur un ton "lennart c'est vraiment qu'un gros con, t'as vu il a ferme le bug, c'est un nazi".

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Boulette

              Posté par  . Évalué à 5.

              Certes. Par contre, un rm -rf * tapé au mauvais endroit…

    • [^] # Re: Boulette

      Posté par  (site web personnel) . Évalué à 7.

      Péter sa carte mère

      La carte mère n'est pas (ou ne devrait pas) être pétée. Juste un reset des données à faire, normalement, ou un flash du BIOS au pire. Si la carte mère ne permet ni l'un ni l'autre, c'est elle qui a une faille.

      Que l'OS puisse aller modifier les données UEFI, ben c'est l'objectif quand même. Que la carte mère ne le supporte pas, c'est pas forcément la faute de l'OS. Bien sûr, s'il y a des cartes mères qui gèrent mal, on peut imaginer que l'OS le sache et les gère spécialement, ce ne sera pas la première liste de contournements et de cas spéciaux que l'OS gère.

    • [^] # Re: Boulette

      Posté par  (site web personnel) . Évalué à 0.

      Péter sa carte mère en faisant l'équivalent d'un format c: même sous Windows on a jamais vu ça.

      Si tu avais pris la peine de lire le lien Phoronix, tu aurais vu qu'on peut faire la même chose sous Windows avec 20 lignes de code.

      J'attends le jour où on verra apparaître un "popup.exe" vérolé, téléchargé par Madame Michu, et qui va lui formater en règle son UEFI.

      • [^] # Re: Boulette

        Posté par  . Évalué à 3.

        J'attends le jour où on verra apparaître un "popup.exe" vérolé, téléchargé par Madame Michu, et qui va lui formater en règle son UEFI.

        CIH², le retour de la vengeance.

        Bientôt sur nos écrans.

        • [^] # Re: Boulette

          Posté par  . Évalué à 2.

          Ça arrivera.

          Et si ce défaut de conception est du à UEFI alors il faut arrêter tout de suite et jeter ce truc au placard. Parce que sur papier c'est bien, mais en pratique c'est pas sécurisé et ça donne beaucoup trop de pouvoirs au constructeur avec par exemple secure boot qui vous oblige à utiliser Windows.

          Je ne suis pas anti progrès, j'utilise pulseaudio, systemd, kms… mais uefi non toujours pas. Plus contraignant que le bios qui j'espère va survivre encore quelques temps.

          • [^] # Re: Boulette

            Posté par  (site web personnel) . Évalué à 5.

            par exemple secure boot qui vous oblige à utiliser Windows

            Euh non : tu peux installer tes propres clés, et signer ton propre noyau. D'ailleurs Ubuntu distribue un chargeur UEFI signé, tu peux booter en UEFI Secure Boot sur une machine qui n'a jamais vu un octet Windows sur son disque dur.

            • [^] # Re: Boulette

              Posté par  . Évalué à 3.

              Euh non : tu peux installer tes propres clés, et signer ton propre noyau.*

              * sur certains UEFI.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Boulette

                Posté par  . Évalué à 2.

                Normalement, ça devrait pas.
                Lors du tollé sur secure boot, MS avait été obligé d'ajouter la possibilité de gérer ses clefs à la certification logo windows.

                • [^] # Re: Boulette

                  Posté par  . Évalué à 5.

                  Uniquement pour Windows 8, pour Windows 10, ils ont retiré l'obligation http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secure-boot-alt-os-lock-out-a-reality/

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Boulette

                    Posté par  . Évalué à 6.

                    Sauf qu'en vrai c'est faux. Tout d'abord l'article d'ARS parle de la désactivation de Secure Boot et non de la gestion des clefs par l'utilisateur. Mais même.
                    Le PDF avec les exigences est par là, en bas de la page "download offline …". Il faut regarder page 684(!) la partie qui dit "On non-ARM".
                    Ca dit exactement l'inverse de ce qui est écrit (ou pas) dans l'article d'ARS :
                    - l'utilisateur doit pouvoir gérer ses bases de clef;
                    - l'utilisateur doit pouvoir désactiver secureboot.

                    Sauf si vous êtes sur une plateforme ARM, auquel cas vous puez du groin. Mais vous puiez déjà du groin sous Windows 8.1

          • [^] # Re: Boulette

            Posté par  . Évalué à 3.

            secure boot qui vous oblige à utiliser Windows.

            Secure Boot [a pour but] de protèger des rootkits (genre ceux que Sony a pu mettre sur ses CDs audio), et n'oblige pas à utiliser Windows.

            On peut utiliser une installation d'une distribution Linux compatible SecureBoot dès le départ (exemple : Ubuntu), rajouter la compatibilité SecureBoot soi-même à son bootloader (niveau code c'est déjà fait, mais même aujourd'hui j'ai pas trouvé un seul guide pour le faire facilement sous Archlinux par exemple… :/ ), ou carrément désactiver SecureBoot (option disponible sur toutes les bonnes cartes mères)

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Boulette

            Posté par  (Mastodon) . Évalué à 10.

            Et si ce défaut de conception est du à UEFI alors il faut arrêter tout de suite et jeter ce truc au placard.

            Si tu avais lu l'histoire en entier tu réaliserais que ce problème ou cette "faille" comme tu l'appelles n'est pas universelle à UEFI. C'est le firmware moisi de certaines carte mère qui ne réagit pas correctement. En gros supprimer les fichiers dans ce pseudo filesystem ça équivaut à indéfinir (ça se dit en français?) une variable. Un firmware bien écrit devrait avoir des constantes qui définissent ces variables avec une valeur par défaut dans le cas où elles sont undef.

  • # Incompétence sociale (ce n’est pas une insulte)

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 02 février 2016 à 18:39.

    J’avais failli écrire un journal quand j’ai vu ça mais j’avais fait l’effort de me retenir… Tant pis ce sera un commentaire.

    N’empêche, je suis plutôt content de Systemd et j’ai rien contre Pulseaudio, mais il faut reconnaître que question relation humaine ce Lennart fait tout pour se faire insulter…

    1. Il compare des fichiers dans le dossier /sys/firmware/efi/efivars/ avec l’entrée /dev/sda, ce qui est soit du foutage de gueule, soit de l’incompétence au plus haut point. L’entrée /dev/sda est une simple entrée, si je supprime accidentellement /dev/sda je peux la restaurer avec mknode ou un simple reboot. Supprimer /dev/sda ne touche à aucune donnée, cela retire au contraire l’accès aux données. L’arborescence
      /sys/firmware/efi/efivars/ se comporte comme un système de fichier, donc toute suppression d’un fichier modifie une configuration.

    2. Il compare supprimer un lien dur vers un fichier et écrire dans un fichier, ce qui est soit du foutage de gueule, soit de l’incompétence au plus haut point. Pour rincer /dev/sda il ne faut pas supprimer /dev/sda, il faut écrire dedans. Pour briquer les machines citées, il ne faut pas écrire dans un fichier, il faut supprimer un fichier dans /sys/firmware/efi/efivars/.

    3. Il compare une configuration contenue dans une mémoire sur la carte mère (non redondable, non sauvegardable, non restaurable), à un composant extrêmement standardisé et interchangeable comme un disque dur, ce qui est soit du foutage de gueule, soit de l’incompétence au plus haut point.

    4. Là dessus, il clôt le ticket sans autre forme de procès.

    Le gars fait tout pour que les gens se sentent insultés. Parce que lorsqu’on a en face quelqu’un qui se comporte ainsi il y a trois possibilités :

    1. Soit l’autre est un incompétent technique de première.

    2. Soit l’autre essaie de m’entuber, mais s’il croit m’entuber avec des sophismes de ce si piètre niveau il doit vraiment croire que je suis un incompétent technique de première, ce qui est très insultant.

    3. Soit l’autre est un incompétent social de première.

    Au premier coup d’œil, les gens civilisés ne pensent pas que l’autre est un incompétent technique, surtout que Lennart a tout de même fait ses preuves, et même si beaucoup de monde râle à propos de ces jouets, il y a assez de monde pour les utiliser même en râlant. Au premier coup d’œil, les gens ne pensent pas que l’autre est un incompétent technique de première, surtout quand il est l’auteur de logiciels intégrés partout, et ne pensent pas au premier coup d’œil que l’autre est un incompétent social (c’est un effort difficile que de discerner les difficultés de l’autre pour s’adapter et concilier). Donc que font les gens ? Ils prennent l’option foutage de gueule « ce mec me prend pour un con », les gens se sentent insultés. On ne peut pas employer des arguments fallacieux pour taire un interlocuteur expert sans que cet interlocuteur expert ne se sente insulté par une aussi basse manœuvre, c’est inévitable.

    Bref, ensuite Lennart clôt la discussion (après avoir clôt le ticket) et écrit :

    I am deleting a number of insulting or completely off-topic messages now.

    Il ne se rend pas compte que les gens répondent par l’insulte parce qu’ils se sont sentis insultés par lui dès son premier commentaire.

    Moi de même. Juste à la lecture de son commentaire j’ai l’impression qu’il m’insulte, alors que je suis étranger à la discussion. Quand je lis son premier commentaire cela me fait bondir et j’ai une furieuse envie de le remettre à sa place, alors que je suis étranger à la discussion, que je suis étranger au projet, et que je ne suis pas concerné par ce bug, et que je n’utilise pas UEFI.

    Faudrait vraiment qu’il commence à se poser des questions sur son comportement social et à apprendre à débattre / collaborer en société. C’est comme tout, ça s’apprend, certains partent de plus loin et ont besoin de plus d’efforts que d’autres mais rien n’est insurmontable, avec des règles simples on peut apprendre à éviter de provoquer les autres aussi stupidement.

    En plus de la forme très blessante de son discours s’ajoute sa manière arbitraire de fermer les discussions (qu’il enflamme lui-même sans s’en rendre compte), façon l’enfant pourri-gâté (ou le lama) qui se bouche les oreilles en répétant « je n’entends rien, je n’entends toujours rien ». Vu son comportement, il ne devrait pas avoir le pouvoir de clore un ticket ou une discussion, ce pouvoir devrait être conféré par son employeur à une autre personne, même à une personne moins compétente techniquement mais plus compétente socialement, car il est très clair que ce gars a besoin d’être sous l’autorité d’un autre, quand bien même cet autre n’aurait pas d’autre compétence que celle de savoir assurer l’autorité. Mais ce problème vient de cette pseudo méritocratie qui pourrit nombre de projets libres et qui n’est en fait que la loi du plus fort : « celui qui code est celui qui décide », ce qui fait de véritable ravage quand celui qui code ne sait pas décider ou est un incompétent social.

    Être incompétent social n’est pas une insulte, ce n’est pas un drame, mais il faut en être conscient et prendre les mesures nécessaires pour éviter de blesser les autres et se blesser soi-même. Il y a dans la discussion (sur GitHub et ici sur LinuxFr) des gens qui partent probablement de bien plus loin que lui, mais qui ont appris avec de grands efforts à se comporter convenablement en société et sur Internet. Là encore, ne pas faire les efforts nécessaires pour se permettre de ne pas blesser les gens qui font eux-même ces efforts prend clairement l’apparence du foutage de gueule, et j’ai bien peur que là ce ne soit pas juste une apparence, ça fait trop longtemps que cela dure sans qu’il se remette en question et ne montre pas un seul signe de progression.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

      Posté par  (site web personnel) . Évalué à -8.

      Et toi tu n'as pas forcément tout compris non plus… Lennart a écrit :

      We also expose /dev/sda accessible for root, even though it can be used to hose your system.

      Ce qui se traduit par :

      Nous exposons également /dev/sda accessible à root, bien qu'il puisse être utilisé pour planter votre système.

      Et il a tout à fait raison : il suffit d'un dd if=/dev/zero of=/dev/sda, et boum, les données sont perdues.

      Donc ton point 1, ton point 2, l'essentiel de ton emportement, ben c'est complètement à côté de la plaque. (Et pour ton point 3, ben d'une part c'est sauvegardable, c'est l'intérêt de l'avoir sous forme de fichiers ! Et d'autre part si c'est perdu, il devrait être facile de repartir sur des valeurs par défaut dans le BIOS.)

      • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

        Posté par  (site web personnel) . Évalué à 10.

        Et il a tout à fait raison : il suffit d'un dd if=/dev/zero of=/dev/sda

        Je n’ai pas remis cela en cause, je pointe le fait qu’il compare rm fichier à dd of=fichier, ce qui est fallacieux.

        et boum, les données sont perdues.

        Je n’ai pas remis cela en cause, je pointe le fait qu’il compare supprimer des données et briquer un appareil.

        ben d'une part c'est sauvegardable, c'est l'intérêt de l'avoir sous forme de fichiers !

        Tu n’as surtout qu’une représentation, cette sauvegarde n’a pas vraiment de sens. Je peux aussi sauvegarder le fichier /dev/sda hein, ça ne me rendra pas mes données si je restaure le fichier /dev/sda après avoir réécrit le disque…

        Et d'autre part si c'est perdu, il devrait être facile de repartir sur des valeurs par défaut dans le BIOS.)

        Il est très clair que le constructeur est en faute, mais c’est tant pis et il faut faire avec.

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

          Posté par  (site web personnel) . Évalué à -3.

          Tu n’as surtout qu’une représentation, cette sauvegarde n’a pas vraiment de sens.

          Bah euh si ! Ce sont des fichiers réguliers tout à fait banals d'un point de vue Unix. Tu lis leurs octets (sauvegarde), tu écris leurs octets (restauration). C'est comme ça que j'ai récupéré mon giga de RAM : en restaurant une sauvegarde d'un paramètre du BIOS. (Bon, c'était à partir d'une variable de sauvegarde, mais conceptuellement, j'aurais aussi bien pu réécrire ces octets à partir d'une sauvegarde externe.)

          Là où la sauvegarde n'a peut-être pas de sens, c'est que je ne suis pas sûr que tous les paramètres du BIOS sont bien exposés dans les variables UEFI (même s'il y en a infiniment plus que dans l'IHM du BIOS). Donc restaurer les variables UEFI (tout à fait faisable) ne remet pas forcément ton BIOS dans l'état où il était au moment de la sauvegarde (si des variables non-UEFI ont changé).

          ça ne me rendra pas mes données si je restaure le fichier /dev/sda après avoir réécrit le disque…

          /dev/sda n'est pas un fichier régulier, il y a une confusion sémantique dans tes commentaires. Si tu parles de sauvegarder et restaurer l'entrée « sda » du répertoire « dev », effectivement, ça n'aura aucun effet sur les données du disque dur. Maintenant tu me parles de sauvegarder et restaurer /dev/sda, je pense immédiatement à la commande dd, et ça marche très bien.

          • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

            Posté par  (site web personnel) . Évalué à 10.

            /dev/sda n'est pas un fichier régulier, il y a une confusion sémantique dans tes commentaires.

            La confusion sémantique est dans le message de Lennart. Fais vraiment à cela, c’est un troll très subtile : la confusion sémantique est dans le message de Lennart et c’est cela que je pointe : par cette confusion sémantique Lennart formule un argument fallacieux qui appelle immanquablement des réactions vives qui lui permettent de prendre la posture de la victime et de clore le débat pour raison sociale plutôt que technique. Ce glissement « débat technique » vers « prise de bec » est opéré par l’emploi d’argument fallacieux qui sont vécus comme du foutage de gueule, et c’est très efficace : personne ne peut reprocher à personne de taire un débat après de insultes, quand bien même elles ont été sacrément cherchées. L’avantage de la méthode c’est que le débat technique peut être clôt avec des arguments non techniques, et c’est du pur troll.

            Maintenant tu me parles de sauvegarder et restaurer /dev/sda, je pense immédiatement à la commande dd, et ça marche très bien.

            Tu es complètement tombé dans le troll de Lennart.

            On compare rm /dev/sda et rm /sys/sys/firmware/efi/efivars/qqch.

            Cela signifie aussi que l’on compare cp /dev/sda et cp /sys/sys/firmware/efi/efivars/qqch, et pas dd.

            Le gars qui se plaint de pouvoir briquer un appareil ne se plaint pas de le faire en ayant écrit des octets dans un fichier (comme tu l’as fait pour déplomber ton système), auquel cas on pourrait lui répondre « il fallait être prudent et pas écrire n’importe quoi », il se plaint de pouvoir briquer un appareil en supprimant un fichier virtuel dans /sys, ce qui est sensé être comparable à supprimer le fichier /dev/sda par exemple.

            Dans mon exemple plus haut, si je fais cat /sys/.../rom je dump le vbios de ma carte graphique, mais si je fais rm /sys/.../rom, je ne détruit pas le vbios de ma carte graphique, encore heureux ! Il devrait en être exactement de même pour le firmware de la carte mère.

            Donc restaurer les variables UEFI (tout à fait faisable) ne remet pas forcément ton BIOS dans l'état où il était au moment de la sauvegarde (si des variables non-UEFI ont changé).

            Non, tu peux restaurer certaines valeurs mais pas toutes car dans certains cas la machine est définitivement briquée donc tu ne peux pas restaurer.

            Enfin, tout a déjà été dit, et au delà de la confusion sur les fichier spéciaux, rincer un disque dur n’a pas la même conséquence que de rincer un firmware de carte-mère surtout quand il n’est pas restaurable. J’ai déjà rincé des disques durs, je n’ai jamais perdu de données. j’ai même déjà cramé un disque dur avec une mauvaise manipulation, je n’ai pas perdu de données, je n’ai pas rendu le système indémarrable, j’ai seulement remplacé le disque.

            Au delà des arguments les plus techniques, cet argument est imparable. Même dans le cas où l’on se permet de comparer dd et rm sur un fichier spécial (ce qui n’a pas de sens), la comparaison « donnée standard sur stockage de masse » et « firmware de carte mère » ne tient pas la route, et le faire sciemment tient du troll.

            ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

              Posté par  (site web personnel) . Évalué à -4.

              Tu es complètement tombé dans le troll de Lennart.

              On compare rm /dev/sda et rm /sys/sys/firmware/efi/efivars/qqch.

              Il n'y a pas de troll, et la comparaison entre deux rm, c'est toi qui l'a imaginée. Indique-moi où dans le lien indiqué Lennart parle de faire un rm de /dev/sda ! Cite-donc, sans interpréter !

              en supprimant un fichier virtuel dans /sys, ce qui est sensé être comparable à supprimer le fichier /dev/sda par exemple

              Censé… Selon quelle norme, quelle règle, selon qui ? Il y a des trucs dangereux qui traînent dans /proc et /sys, des variables en écriture seule un peu inquiétantes, des fichiers pas vraiment fichiers, de quoi aller taper très fort dans les périphériques USB et PCI il me semble… Qui va aller s'amuser à faire des rm là-dedans ? C'est très différent d'un /dev qui contient essentiellement des device nodes très classiques.

              rincer un disque dur n’a pas la même conséquence que de rincer un firmware de carte-mère

              Non en effet, dans un cas on perd toutes ses données (irremplaçables), dans l'autre on rachète une carte-mère (de meilleure qualité, au passage). Alors oui, si tu as des super backups et pas d'argent, planter la carte-mère ça peut être pire, mais je pense que pour la plupart des gens, c'est l'inverse.

              • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

                Posté par  (site web personnel) . Évalué à 3.

                Tu pars sur l'idée "données irremplaçable et pas de backup", ça veut juste dire que la personne perdra un jour ou l'autre (panne matérielle DD, vol…) ses données irremplaçable, alors vaut mieux maintenant (pour apprendre avant d'en avoir trop d'irremplaçable) que plus tard.

                Bref, ton cas d'exemple montre que le problème est ailleurs, et est donc HS en plus de montrer que tu penses ne pas avoir un bon exemple pour ton argument donc que ton argument n'est pas crédible même par toi-même.
                Pour info, tu démontres donc l'inverse de ce que tu dis démontrer.

                • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

                  Posté par  (site web personnel) . Évalué à -1.

                  Tu pars sur l'idée "données irremplaçable et pas de backup", ça veut juste dire que la personne perdra un jour ou l'autre (panne matérielle DD, vol…) ses données irremplaçable, alors vaut mieux maintenant (pour apprendre avant d'en avoir trop d'irremplaçable) que plus tard.

                  Heu non, c'était pas vraiment mon argument. Je répondais par un trait forcé (curseur placé complètement sur l'importance des données, carte mère ramenée à une simple question de budget) au trait forcé inverse qui avait été posté auparavant (qui disait que ça n'a aucune importance d'effacer son disque dur car l'auteur du commentaire a des backups d'excellente qualité, et que bloquer la carte mère, c'est beaucoup plus grave).

                  En réalité je pense que les deux sont des problèmes majeurs, et ne souhaite subir ni l'un ni l'autre. Et je suis tout à fait d'accord avec Lennart pour dire que l'un comme l'autre sont actuellement assez faciles à faire par quelqu'un à qui on a donné un terminal en root.

                  D'ailleurs, si cette personne est hostile, il sera trivial de remonter en lecture-écriture les variables UEFI problématiques et de les démolir quand même. La protection demandée ne concerne donc que les administrateurs qui font des rm -R dans /sys ; un petit pansement sur une grosse blessure.

                  Pour moi le problème est clairement à régler à plus bas niveau (carte mère en premier, et noyau pour protéger les cartes mères pourries).

              • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

                Posté par  . Évalué à 8.

                Censé… Selon quelle norme, quelle règle, selon qui ?

                L'habitude, au moins.

                Il y a des trucs dangereux qui traînent dans /proc et /sys, des variables en écriture seule un peu inquiétantes, des fichiers pas vraiment fichiers, de quoi aller taper très fort dans les périphériques USB et PCI il me semble…

                Oui. Et clairement, si tu fais une moulinette qui va écrire du random() dans tous les fichiers de /proc, /dev ou /sys, tu vas avoir des surprises. Maintenant, et c'est le point depuis le début : la suppression de ces systèmes de fichiers "virtuels" ne devrait pas avoir d'impact autre que de te forcer à les recréer.

                Ce qu'on reproche ici, c'est d'avoir mis à disposition, tout au fond d'un FS "virtuel" qui n'a jamais vraiment été sensible à la suppression récursive, une sous-arborescence qui est non seulement sensible, mais pour laquelle les conséquences sont très lourdes. Le souci, c'est pas "juste" que les variables UEFI sont effaçables par ce biais, c'est que leur récupération est - dans certains cas - compliquée.

                Et je rejoins là-dessus plusieurs commentaires précédentes : la faute est clairement partagée. Chaque élément de la chaîne (jusqu'au type qui a fait son rm -rf /) aurait pu éviter ou limiter le problème. Mais collectivement, oui, c'est une belle boulette.

    • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

      Posté par  . Évalué à -4.

      C'est pas la premiere fois, il me semble même que Linus lui a gentiment dit un jour que il était bien gentil mais casser l'espace utilisateur sur la seule raison "c'est bugue" ce que font les autres ils ont qu'à corriger leur merde, c'était inacceptable.

      Puis LP ne peut pas avoir tord… Non non zeni il n'est presque plus possible de se passer de systemd sous linux ton argument "ne l'utilise pas" est totalement fallacieux.

      • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

        Posté par  (site web personnel) . Évalué à -1.

        Non non zeni il n'est presque plus possible de se passer de systemd sous linux ton argument "ne l'utilise pas" est totalement fallacieux.

        La liberté des uns commence où commence celle des autres : ce qui est fallacieux est de considérer l'esclavagisme comme une liberté.
        Il est tout à fait possible de se passer de systemd, soit en changeant d'OS (tu es libre) soit en changeant l'OS (tu es libre aussi, merci l'open source), saloperie de liberté qui ne veut pas dire pouvoir obliger les autres à faire comme on veut… Elle est chiante cette liberté quand les autres l'utilisent.

        Mais bon, rien de nouveau dans les gens n'aimant pas systemd (ou la liberté), toute excuse est bonne pour se plaindre.
        Au fait, ça en est à quoi Devuan?

        • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

          Posté par  . Évalué à -5.

          J'en ai rien a foutre de devuan et ton argument sous linux tu peux te passer de systemd est fallacieux car cela est, encore, possible mais bientot cela ne sera plus possible en tout cas pas en mode desktop. Tu le sais et tu joues au con en pretendant le contraire.

          Maintenant je n'ai pas le choix, je fais avec, je n'ai pas choisi plein de choses present sur mon OS mais bon cela n'enleve pas le fait que meme Linus Torvalds lui a dis (plusieurs fois) qu'il faisait chier a casser l'experience utilisateur sur des principes que "cela doit marcher comme ca". Le truc, et c'est pour cela que Linux a pris autant de place dans le monde, c'est que Linus est pragmatique est accepte quand c'est au kernel de mettre en place un truc immonde pour compenser les bugs du hardware ou de la couche en dessous (ce qui est le cas ici).

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 6.

            Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

            Posté par  . Évalué à 5.

            Des centaines de devs et de mainteneurs très compétents, probablement parmi les plus compétents du monde d'ailleurs, ont fait le choix de baser de nombreuses distributions sur systemd. Maintenant, tu prétends que c'est une mauvaise idée, sans donner beaucoup d'arguments d'ailleurs (ce qui se comprend vu le contexte, je ne vois pas comment la plupart des lecteurs pourraient peser le pour et le contre dans ces arguments techniques).

            La question, c'est 1) est-ce que ces centaines de mainteneurs ont pété un cable, se sont jeté dans un effet de mode, et ont suicidé toutes ces distributions en faisant un tel choix ostensiblement déraisonnable, ou 2) ils sont plus compétents que toi et tu as tort?

            Quelqu'un comme moi qui n'ai pas les bases techniques pour me faire une opinon par moi-même va essayer de déterminer des probabilités/vraisemblances (je ne veux froisser aucun statisticien) pour les deux options, et à vue de pifomètre mouillé, je mets moins de 1% sur la première et plus de 99% sur la deuxième. Du coup, ça veut dire que je fais plus confiance aux mainteneurs Debian qu'à toi sur la question.

            Ça n'excuse en rien le comportement de L.P.

            • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

              Posté par  . Évalué à 0.

              Du coup, ça veut dire que je fais plus confiance aux mainteneurs Debian qu'à toi sur la question.

              Oui et pourquoi m'attque tu gratuitement sur systemd? Dans ce journal j'ai uniquement repondu a l'affirmation de zenitram que l'on pouvait s'en passer sous linux que cela devenait a peu pres impossible. Si tu lis bien je n'ai meme pas accuse systemd dans cette histoire mais UEFI.

              Apres je n'aime pas le comportement de LP mais certaines personnes peuvent aimer cela ce n'est pas mon probleme.

              • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

                Posté par  . Évalué à 3.

                Dans ce journal j'ai uniquement repondu a l'affirmation de zenitram que l'on pouvait s'en passer sous linux que cela devenait a peu pres impossible.

                Non, tu peux toujours t’en passer… gentoo maintient un fork de udev pour éliminer les adhérences à systemd. Pour l’instant, je n’ai aucun soucis sans systemd. On verra pour l’avenir, mais je suis à peu près certain qu’on pourra toujours, car beaucoup de personne trouve que systemd contrôle trop de chose en un seul point.

                Il va rester les interfaces dbus proposées par systemd pour les desktop, mais je suis sûr qu’il y aura des alternative quand on pourra plus s’en passer… BSD aussi à gnome ou KDE.

                • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

                  Posté par  . Évalué à -1.

                  Et il faut apprendre la langue francaise car j'ai bien dit:

                  "que cela devenait"

                  Traduction: cela est possible "aujourd'hui"

                  • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

                    Posté par  . Évalué à 4.

                    Traduction: cela est possible "aujourd'hui"

                    Traduction de ma réponse : Je pense que ce sera toujours possible dans l’avenir.

                    Et il faut apprendre la langue francaise car j'ai bien dit:

                    Je ne vois pas où j’ai mal compris ton post… quand à apprendre la langue française, je trouve l’attaque un peu vive alors que c’est mon premier post sur ce fil. Ne te sens pas attaqué comme ça, on pourrait croire que tu es sur la défensive.

                • [^] # Re: Incompétence sociale (ce n’est pas une insulte)

                  Posté par  (site web personnel) . Évalué à -5.

                  gentoo maintient un fork de udev pour éliminer les adhérences à systemd.

                  Ce n'est pas le sujet.
                  Il est libre de bosser, de payer pour que d'autres bosse etc…

                  Son problème est qu'il veut des esclaves qui bossent gratos pour lui, et si il n'a pas d'esclave il conclu "ça devient impossible" plutôt que "je n'aime pas quand je n'ai pas d'esclave et comme j'ai la flemme ben c'est possible mais je ne le ferai pas".

                  Bref, le problème est que le monsieur vit en démocratie et que ça l'emmerde.

  • # ro c'est bien gentil, mais

    Posté par  . Évalué à 6. Dernière modification le 02 février 2016 à 21:55.

    Proposer de remonter en ro les efivars peut être un quick & dirty fix pour ce problème, mais ne le résout pas !

    À un moment ou un autre, un programme de mise à jour du bootloader aura besoin d'écrire dedans (ben oui, on ne montes pas ces efivars en rw pour le plaisir) et il faudra les remonter en rw à ce moment là et même si le code de se programme se charge lui-même de passer les efivars en rw pour limiter le temps d’exposition on n’est pas à l’abri d'un bug de ce programme lui-même qui fout le boxon lors de l'écriture.

    Je parle là de bootloaders genre systemd-bootd(ex. gummyboot), grub, syslinux, rEFIt… Mais un logiciel de restauration système (ou d'installation en masse automatisé etc. etc.) sous Windows ou même DOS peut être amené à manipuler ces variables, et y causer des dégâts.

    Bref idéalement c'est aux CM de s'assurer que l'UEFI reste dans une configuration utilisable, mais comme suggéré plus haut, rien ne s'oppose à un mettre un gestionnaire de "quirk" dans le kernel pour protéger un UEFI pourri, ça existe déjà pour d'autres composants.

  • # Je ne connaissais pas L.P.

    Posté par  (site web personnel) . Évalué à -7.

    Mais je constate que c'est un grand démocrate…

    @poettering poettering locked and limited conversation to collaborators 3 days ago

    #JaiToujoursRaison

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Je ne connaissais pas L.P.

      Posté par  (site web personnel) . Évalué à 8.

      Voit pas rapport : la démocratie, c'est la liberté de ne pas prendre son logiciel, et personne (surtout pas lui) ne te l'impose.
      J'ai l'impression que tu es du genre à penser que la liberté d'expression c'est l'obligation pour les autres d'accepter ta prose sur les commentaires de leur espace de liberté, je te rappelle que ce n'est pas la cas… (au contraire)

      Bref : rien à voir avec le refus de la démocratie.

  • # systemd

    Posté par  . Évalué à -9.

    HA systemd, c'est le truc qui a empêché de rebooter proprement mon pc. Apres un ctrl+alt+supr il a insisté pour arrêter chaque service proprement. Sauf qu'ils tombaient dans des timeout de plus d'une minute. Un nouveau ctrl+alt+supr recommence la séquence. Au final j'ai eteins violament mon pc…

    • [^] # Re: systemd

      Posté par  . Évalué à 10.

      Apres un ctrl+alt+supr il a insisté pour arrêter chaque service proprement.

      Rien d'anormal.

      Sauf qu'ils tombaient dans des timeout de plus d'une minute.

      Le timeout par défaut est d'une minute et trente secondes, en effet. Rien d'anormal. Les fautifs sont les services qui ne veulent pas s'arrêter.

      Ça se change en modifiant /etc/systemd/system.conf . J'ai pas trop regardé, mais c'est sûrement la clé DefaultTimeoutStopSec (valeur en secondes).

      c'est le truc qui a empêché de rebooter proprement mon pc.

      De ce que je lis, c'est plutôt toi qui ne voulait pas attendre que systemd fasse son boulot (cet idiot de systemd qui insiste pour "arrêter chaque service proprement" !) et qui a rebooté le PC à la sauvage.

      Au final j'ai eteins violament mon pc…

      Ah ben tu vois, c'est pas systemd qui t'as empêché de rebooter proprement. Tu le dis toi-même.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: systemd

      Posté par  (site web personnel) . Évalué à 1.

      Sauf qu'ils tombaient dans des timeout de plus d'une minute.

      Et le fautif est systemd qui fait un timeout volontairement (=ce n'est pas un bug, c'est voulu par celui à qui tu as délégué par flemme la gestion, et tu as eu encore plus la flemme de configurer pour faire comme toi veut), et pas les services qui font une boucle infinie.

      Tu aurais configuré systemd pour un time out de 60 minutes que ça serait toujours lui le fautif? (ben oui, le service merde, alors 1 ou 60 minutes…)
      tu aurais viré systemd que ça serait toujours lui le fautif? (ben oui, SysV ferait la même chose la… Il attendrait le service qui ne se termine pas)

      Ha le bonheur de pouvoir penser si facilement "j'ai un problème, c'est la faute à X"… Je t'envie.

      • [^] # Re: systemd

        Posté par  . Évalué à 10.

        ben oui, SysV ferait la même chose la…

        Nope, SysV fonctionne pas pareil pour l’arrêt/redémarrage : il envoie un TERM à tout le monde, un KILL 5s plus tard à tout le monde, puis arrête tout 5s plus tard, et tant pis pour les retardataires.

        • [^] # Re: systemd

          Posté par  (site web personnel) . Évalué à -3.

          puis arrête tout 5s plus tard

          argh, j'ai été eu.
          L'auteur de l'attaque sur systemd n'en reste pas moins ridicule (il reproche à systemd de devoir faire un arrêt violent, alors que c'est ce qu'il se passait "avant"… Rigolo comme reproche)

          • [^] # Re: systemd

            Posté par  . Évalué à 9.

            Heu, non. L’arrêt 5s plus tard sous SysV, c’est un remount en read-only des systèmes de fichiers + un sync avant l’extinction. Un arrêt brutal comme décrit plus haut ne fait pas ça.

            • [^] # Re: systemd

              Posté par  . Évalué à 9.

              Heureusement, pour ça, il y a les magic sysrq.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: systemd

          Posté par  (site web personnel) . Évalué à 3.

          puis arrête tout 5s plus tard, et tant pis pour les retardataires.

          Si je comprends bien, avec SysV (vraiment toutes les implémentations ?) le serveur est arrêté, au plus, 5s après un shutdown ?

          Parce que bon … il faut déjà 30 secds minimum pour qu'il arrête Squid. Ce n'est pas beaucoup mieux pour apache, mysql, postgresql, ….

          En tout cas, moi, je ne constate pas un arrêt en 5 secds.

          • [^] # Re: systemd

            Posté par  (Mastodon) . Évalué à 7.

            Non, ya plusieurs timeout.
            D'abord il arrête plein de trucs.
            Ensuite il lance un TERM à tout les programmes, avec un timeout de quelques secondes (5 ? Je ne sais pas).
            Puis il lance un KILL pour ceux qui n'auraient pas compris la première fois, il leur laisse aussi un peu de temps pour se déboucher les pipes auditifs…
            Puis il démonte les systèmes de fichier distants (ou il fait ça avant, je ne sais plus, mais pas en parallèle des TERM/KILL en tout cas).
            Puis à la fin il remonte tout les disques locaux en lecture seule.
            Et là il redémarre, même si il reste encore des programmes qui ont fait la sourde oreille au KILL.

            Donc ça prend plus de 5 secondes au total.
            D'autant plus qu'il attend toujours après TERM et KILL même si tout le monde a été très sage et s'est fermé dans la seconde qui a suivi le TERM.

            C'est discutable, mais ça fonctionne.
            La méthode systemd est a priori plus efficace quand tout le monde est très gentil, mais les timeout sont plus long par défaut, et donc ça peut être très long - voire très inefficace - quand un programme est réfractaire au suicide.

            Yth.

    • [^] # Re: systemd

      Posté par  . Évalué à 8.

      Je ne comprends pas très bien. S'il n'y avait pas eu systemd, il se serait passé quoi ? Tu aurais :

      1. attendu que le ou les services en question s'arrêtent proprement, quitte à ce que ça prenne plus d'une minute ?
      2. Ton autre mécanisme d'arrêt aurait tué ces services de façon non propre ?
      3. Tu aurais éteint violemment ton pc car c'était trop long ?

      Si c'est 1), c'est donc que tu ne réagis pas de la même façon face à systemd ou un autre système. Si c'est 2) ou 3), l'arrêt n'aurait pas été plus propre qu'avec systemd comme tu l'as décrit.

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.