Journal systemd: attention à RemoveIPC

Posté par . Licence CC by-sa
Tags :
25
30
sept.
2016

Un journal bookmark pour éviter des potentiels problèmes à d'autres…

Suite à une mise à jour vers RHEL7, certaines de nos databases postgres ont commencé à crasher de façon aléatoire sur semop(), avec EINVAL.
La raison: les semaphores utilisées par psql disparaissaient par magie.

On a vite identifié le coupable : systemd, plus précisément cette option :

https://lists.freedesktop.org/archives/systemd-devel/2014-April/018373.html

RemoveIPC=
Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the last of the user's sessions terminated. This covers System V semaphores, shared memory and message queues, as well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users are excluded from the effect of this setting. Defaults to "yes".

Oui, vous avez bien lu, systemd supprime les semaphores/shared memory/message queue appartenant à un utilisateur quand il logout : donc si vous avez un process qui tourne sous un utilisateur, et par example un job cron qui tourne sous ce même utilisateur, systemd va joyeusement faire le menage (et c'est encore pire parce aue le comportement dépend selon que c'est un system user ou non).

Je vous laisse lire le bug report - qui date :
https://github.com/systemd/systemd/issues/2039

J'aime particulièrement cette réponse :

poettering commented on Nov 26, 2015
Well, it's configurable, because it can break stuff.

But I am pretty sure the usecase you describe is borked… The cleanup stuff already excludes system users, i.e. all daemon users. As it appears the customer created a non-system account for this stuff, and that's what should be fixed.

Sorry, but this is nothing to fix upstream… Please ask the customer to disable RemoveIPC= locally, or fix his users to become proper system users.

Sorry.

RHEL et Oracle ont désactivé cette option par défaut, mais je suis abasourdi par la réponse de Poettering…

  • # Poettering

    Posté par (page perso) . Évalué à 10.

    Tu es abasourdi par sa réponse, vraiment ?

    Moi, ça ne m'étonne pas de sa part : il nous a habitués à ce genre de réponses.

    D'un côté je comprends son point de vue et je suis d'accord avec lui, dans l'absolu.

    D'un autre côté, s'appuyer sur un truc qui peut être contrôlé par un admin (donc potentiellement par des noobs) pour un "nettoyage" aussi sensible, sachant que beaucoup d'admins n'ont pas des compétences poussées, c'est vraiment limite…

    https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

  • # Moui

    Posté par . Évalué à 10.

    Si tu regardes bien, même la personne rapportant le bug est d'accord sur le fait qu'il n'y a rien à corriger dans systemd.
    Ça n'arrive que si l'utilisateur postgres (dans ton cas) n'est pas taggé comme system_user et qu'il est utilisé comme un utilisateur classique en plus de son utilisation daemon et l'option est configurable… Du coup j'ai du mal à voir le reproche (mis à part que le threshold pour les system users est défini à la compilation et non dynamiquement en fonction de login.defs).

    • [^] # Re: Moui

      Posté par . Évalué à 10.

      La notion d'utilisateur système est purement administrative : du point de vue du kernel - qui gère les IPC - c'est purement un uid comme un autre (je sais qu'il y a une difference par example pour adduser, mais c'est orthogonal).
      Alors prendre une decision de supprimer des IPCs - qui est potentiellement très dangereux - basée dessus n'a aucun sens.
      Sans parler du risque intrinsèque de régression, qui est inacceptable.
      Linus l'explique mieux que moi : https://lkml.org/lkml/2012/12/23/75

      Sinon, je vois que ce journal a été tagué FUD/troll : c'est dommage, parce que je suis globalement satisfait de systemd, mais ce genre de bug - et le refus de le corriger - est implement inacceptable.

      • [^] # Re: Moui

        Posté par . Évalué à 2.

        À la base la fonctionnalité n'excluait que root, pour avoir un entre-deux ils ont rajouté les users « système » et enfin on peut la désactiver.
        Oui c'est chiant que ça introduise une régression (et encore, dans un cas bien particulier d'utilisation duale d'un user daemon qui a un UID d'utilisateur normal), mais le problème des fonctionnalités désactivées par défaut c'est que personne ne les utilise :-)

        • [^] # Re: Moui

          Posté par . Évalué à 4.

          le problème des fonctionnalités désactivées par défaut c'est que personne ne les utilise :-)

          Quel est l'intérêt de cette fonctionnalité qui fait qu'il faille absolument l'activer par défaut ? J'avoue que j'ai du mal à comprendre.

          • [^] # Re: Moui

            Posté par . Évalué à 7.

            Quel est l'intérêt de cette fonctionnalité qui fait qu'il faille absolument l'activer par défaut ? J'avoue que j'ai du mal à comprendre.

            Le fait de ne pas laisser de ressources traîner sur un système multi-utilisateurs ?

            • [^] # Re: Moui

              Posté par . Évalué à 5.

              Dans ce cas l'implémentation est mauvaise : il faudrait attendre que tous les processus d'un utilisateur soient morts, pas simplement que l'utilisateur se soit déloggé.

              • [^] # Re: Moui

                Posté par (page perso) . Évalué à 5.

                Arrêter les processus utilisateur seulement quand l'utilisateur n'a plus de processus ?

                • [^] # Re: Moui

                  Posté par . Évalué à 9.

                  Qu'on me corrige si je me trompe, mais ici on ne parle pas d'arrêter les processus, on parle de désallouer les ressources d'IPC (par exemple des sémaphores nommés).

                  Par ailleurs, il semble que "l'utilisateur n'a plus de processus" n'est pas la même chose que "l'utilisateur s'est déloggé" : l'utilisateur peut s'être déloggé tout en ayant laissé des processus tourner en tâche de fond.

              • [^] # Re: Moui

                Posté par . Évalué à 1.

                ou juste laisser l'OS faire son boulot…

      • [^] # Re: Moui

        Posté par (page perso) . Évalué à 2. Dernière modification le 30/09/16 à 10:40.

        est (s)implement inacceptable.

        Euh… Désolé, mais autant je pense que ce bug est inacceptable, autant je pense que la correction est à faire côté administrateur qui a fait un peu n'importe quoi en assignant une tâche à un utilisateur pas sensé faire cette tâche.

        Ca me parait logique de "tuer" tout ce qui est lié à un utilisateur quand il se déloggue (car il… se déloggue).
        Perso je comprend que ce journal est tagué FUD/troll car à aucun moment son auteur ne remet en question sa façon de faire (que vient faire un utilisateur qui se connecte et déconnecte dans les droits d'une base de données? il ne le dit pas, alors que les "best practices" sont d'avoir un utilisateur dédié pour la base de données, pour gérer les droits plus finement), il critique la réponse de Lennart, sans chercher à la comprendre.

        En fait, j'ai l'impression que Lennart ne fait que montrer les petits problèmes de "design" d'admin sys chez des utilisateurs ;-).

        bon troll, de toutes façon il en sortira ici rien de constructif quoiqu'on explique pour dire que c'est pas forcément idiot (toujours à taper sur l'autre, et remettre en question tout changement avec n'importe quelle excuse).

        • [^] # Re: Moui

          Posté par . Évalué à 10.

          Ca me parait logique de "tuer" tout ce qui est lié à un utilisateur quand il se déloggue (car il… se déloggue).

          Pourquoi diable exclure d’office l’idée que l’utilisateur puisse avoir un démon ?

          • [^] # Re: Moui

            Posté par . Évalué à 10.

            Quand je disais que systemd adopte les mêmes manières de fonctionner que Windows, tout ce que j'avais comme réponse, c'est que je suis résistant au changement.

            Ce genre de problématique, je l'ai senti venir : dans peu de temps on va se retrouver avec des serveurs Linux avec session GUI ouverte, qu'il ne faudra surtout pas fermer pour ne pas faire planter l'appli. Comme sur les Windows d'il y a 15 ans.

            C'est triste ….

            • [^] # Re: Moui

              Posté par (page perso) . Évalué à -2.

              Si tu as des serveurs Linux avec GUI, c'est toi qui est triste…

        • [^] # Re: Moui

          Posté par . Évalué à 6.

          Donc tu fais tourner postgres sous un autre user, bien. Mais tu ne peux pas te logger sous cet user pour effectuer des tâches administratives; comment fais-tu alors ?

          • [^] # Re: Moui

            Posté par . Évalué à 2.

            tu laisses une session ouverte sous Postgres pour que Postgres ne plante pas …

          • [^] # Re: Moui

            Posté par . Évalué à 8.

            du coup, la bonne façon de faire c'est quoi ?

            • postgres en user system
            • se logguer sous un autre compte
            • "su postgres" pour les taches admini

            ça marche ça ?

        • [^] # Re: Moui

          Posté par . Évalué à 10.

          Ca me parait logique de "tuer" tout ce qui est lié à un utilisateur quand il se déloggue (car il… se déloggue).

          Faut développer un peu parce que ton propos est laconique.

          Quand un DBA se connecte à un serveur pour effectuer des opérations de maintenance sur la database, il n'a pas beaucoup le choix que de prendre l'identité du compte technique qui exécute le produit. Donc bien souvent le user oracle et dans certaines implémentations/normes, le user d'instance (qui peut être séparé).

          Les bonnes pratiques veulent que le DBA se connecte avec un compte nominatif sur le serveur puis passe "dba" via un "su" ou un "sudo".
          Lorsqu'il a terminé ses opérations, ben il se déloggue.

          Avec "sudo", on peut aussi simuler un login. C'est très pratique pour bénéficier des variables d'environnement puisqu'on source le profile.

          En somme, le ménage proposé par systemd me parait très cavalier…

          • [^] # Re: Moui

            Posté par . Évalué à -5. Dernière modification le 30/09/16 à 14:50.

            Les bonnes pratiques veulent que le DBA se connecte avec un compte nominatif sur le serveur puis passe "dba" via un "su" ou un "sudo".

            Whaou y'a encore des gens qui ont pour bonne pratique de se connecter à une machine pour faire des trucs à la mano, non reproductibles, non testés et idéalement sans rien dire à personne pour être sur de prendre un KO à la prochaine mise à jour ?

            Si les DBA existaient pas, faudrait les inventer.

            Les bonnes pratiques ca serait pas plutôt de travailler ton infra pour viser à désactiver tous les logins sur toutes les machines ?

            • [^] # Re: Moui

              Posté par . Évalué à 5.

              non reproductibles, non testés et idéalement sans rien dire à personne pour être sur de prendre un KO à la prochaine mise à jour ?

              faux archi faux.

              Une opération de maintenance est quelque chose de maitrisé, donc reproductible et testé.
              Une opération de maintenance sur la prod ne se fait pas sans incident et sans change request.

              Le fond du sujet est la disponibilité des services.

              Quand tu as 3000 noeuds, tu t'en fiche d'en casser quelques uns.

              Par contre, quand c'est la grosse base de données de l'appli bancaire ultra sensible, mieux vaut ne pas faire de connerie.
              Donc c'est là qu'on prévient et qu'on prend les mesures nécessaires.

              Quitte à couper la réplication au secours pendant quelques minutes pour pas progaper des anomalies, backup préventif, etc etc…

              C'est du professionnalisme.

              Tu notera que ça s'applique à n'importe quoi : pas uniquement au bases de données

              Les bonnes pratiques ca serait pas plutôt de travailler ton infra pour viser à désactiver tous les logins sur toutes les machines ?

              +1

              Sauf que dans le monde réel ce n'est pas encore assez le cas. Tu sais, il n'y a pas que des hébergeurs cloud dans le monde…

              Mais on n'y travaille, je mets en place rh satellite, on verra si mes collègues y adhère…

              • [^] # Re: Moui

                Posté par . Évalué à 3.

                ''Dans un monde "software defined", la maintenance - dans le sens intervention humaine pour corriger un problème - est un échec. Il n'y a que des deploiements. Certes, dans la vraie vie, c'est rarement le cas, mais c'est un objectif d'ingénierie : dans le design et les technologies, ainsi que la gestion des coûts (c'est généralement là où le bât blesse).
                La maintenance doit être un cas particulier du deploiement, dans le sens où, cette dernière opération est la plus fréquente et la plus maitrisée.
                Le plus gros blocage n'est pas technique, mais humain : modéliser sa propre expertise est moins "valorisé" que de l'appliquer. C'est le verrou mental le plus important à cause de la gratification immédiate.
                De plus, il existe encore un bias sur la maîtrise du changement : le lisser dans le temps est toujours la meilleure stratégie, mais comme cela nécessite une excellente coordination, c'est compliqué de le faire hors du pipeline de deploiement.
                Je précise que ma définition de deploiement englobe aussi la notion de décommissionnement.

            • [^] # Re: Moui

              Posté par . Évalué à 5. Dernière modification le 30/09/16 à 15:38.

              Des développeurs peuvent aussi avoir une base de données locale sur le poste de développement. En Oracle je sais pas, mais avec postgres/mysql c’est une solution toute aussi viable qu’un serveur de dev centralisé.

              Whaou y'a encore des gens qui ont pour bonne pratique de se connecter à une machine pour faire des trucs à la mano, non reproductibles, non testés et idéalement sans rien dire à personne pour être sur de prendre un KO à la prochaine mise à jour ?

              1. Pour faire des tests en dev, oui, ça me paraît une pratique acceptable
              2. Malheureusement, dans la vie réelle, même si on connaît et applique généralement les bonnes pratiques, il y a toujours x% de situations merdiques où il faut se connecter en root@prod à l’arrache pour mettre quelques bouts de sparadraps en urgence (x variant de 0 à 100 selon la qualité de l’équipe d’admin, 0 et 100 étant irréalistes). Ce serait bien que dans cette situation d’urgence on ait pas à gérer la surprise « bon, quel comportement qui fonctionnait depuis 15 ans systemd va nous faire exploser à la figure aujourd’hui ? »
              • [^] # Re: Moui

                Posté par . Évalué à 6.

                 Ce serait bien que dans cette situation d’urgence on ait pas à gérer la surprise « bon, quel comportement qui fonctionnait depuis 15 ans systemd va nous faire exploser à la figure aujourd’hui ? »

                Hein ? Tu as en prod un init différent de celui qui est en préprod ? Avec des admin qui le connaissent pas ? Et tu fais du bricolage dans ta prod, du genre tel utilisateur va faire un cron à l'arrache ? Ça commence à faire une jolie combinaison de trucs foireux, non ? Si c'est pas systemd qui « te plante » ça aurait était autre chose ^^

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Moui

                  Posté par . Évalué à 3.

                  Le monsieur du dessus parle d'environnement de développement, local ou non, et tu lui réponds sur production et pré-production. Vous risquez pas de vous comprendre…

                  • [^] # Re: Moui

                    Posté par . Évalué à 4.

                    Non il parle de la situation d'urgence qui te pousse à aller mettre les mains directement dans la prod.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Moui

                  Posté par . Évalué à 10. Dernière modification le 30/09/16 à 16:59.

                  Ça commence à faire une jolie combinaison de trucs foireux, non ?

                  1. Le fond de mon commentaire est que dans la vie réelle les trucs foireux arrivent. « On s’en fout de X, ça ne pose problème que dans les situations foireuses » n’est pas une défense acceptable. Un truc robuste c’est un truc robuste y compris dans les situations foireuses, pas un truc « robuste si tout se passe comme sur des roulettes ». Il n’y a pas grand mérite à être « robuste » quand il n’y a aucun souci par ailleurs.

                  2. Comme remarqué plus haut, en prod/preprod et en temps normal on ouvre pas de session utilisateur. Ergo, tu ne verras jamais en preprod que systemd a tout chamboulé les règles concernant les sessions utilisateurs sur une mise à jour (sauf si tu y penses, mais honnêtement, avant ce journal ou d’y être confronté, qui peut penser au cas « haha la mise à jour systemd va rien casser dans ma prod sauf dans le cas complètement anormal où j’y ouvre une session utilisateur » ?) puisque la question ne se pose pas en temps normal. 3 mois plus tard, urgence en prod, et paf les ressources IPC postgres.

                  3. Il n’y a pas que des serveurs dans la vie, et on a toujours pas répondu à ma question : pourquoi présupposer qu’un utilisateur ne puisse pas avoir de démon ?

                  • [^] # Re: Moui

                    Posté par . Évalué à 3.

                    Pour les points 1 et 2, quand tu commence à faire des choses foireuses accuser systemd (ou n'importe quoi d'autre), n'est pas une bonne idée. Tu peux avoir toutes les bonnes raisons du monde, tu le dis toi même : tu fais des choses foireuses. La seule chose qui peut t'aider dans ce cas là c'est d'être un expert de ton système. Si tu pitte rien à Arch et que tu tente des magouilles, oui tu va te faire mal.

                    Pour le dernier point, c'est parce que c'est le cas. Le fait qu'il y ai des erreurs d'intégration par les distributions et tout à fait orthogonal. Le principe de nettoyer par défaut et de débrayer au cas par cas est très sein.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Moui

              Posté par (page perso) . Évalué à 8.

              Sur certaines archi, quand la prod est tombé, la première chose à faire, le plus important, le plus urgent, c'est de restaurer le service, coûte que coûte, même si ce doit être réalisé avec une solution crade.
              Une fois le service à nouveau rendu, là, on met en place des méthodes propres pour que cette panne ne puisse se reproduire, et pour que si ça se reproduise, on puisse corriger de manière propre…

        • [^] # Re: Moui

          Posté par . Évalué à 8.

          En fait, j'ai l'impression que Lennart ne fait que montrer les petits problèmes de "design" d'admin sys chez des utilisateurs ;-).

          Le problème n'est pas tant les problèmes de « design »[1] qu'un changement dans les pratiques qu'imposent ce genre de choix techniques qui changent l'existant.

          Il m'est arrivé de me travestir en www-data pour trouver la raison pour laquelle tel script/cgi/programme refuse de fonctionner ; si demain il est décidé que l'on ne doit pas se connecter/déconnecter avec un utilisateur système parce que ce n'est pas « le bien »[2], alors à quoi devrais-je m'attendre ? Suis-je vraiment un abruti si jusqu'à maintenant c'est permis, que c'est bien pratique et que je fais cela ?

          Après reste la question de comment faire évoluer Linux, i.e. comment faire « bien », tout en gardant toujours une compatibilité ascendante ?
          Je ne sais pas, et je sais que travailler avec les inerties c'est très difficile. Peut-être plutôt en mettant/activant tel programme/fonctionnalité/option dans une distribution uniquement (e.g. Red Hat, Fedora, et CentOS) ? Après tout si le package est vraiment convaincant tout le monde l'utilisera, et c'est bien ce qu'il s'est produit avec systemd.

          De plus si une feuille de route avec tous les éléments qui vont être changés, avec la nouvelle architecture proposée est accessible cela pourrait aider et cela permettrait également de discuter, faire participer tout le monde[4].

          En bref je sais pas, par contre toujours dire que les autres sont des cons car ils ne font pas ceci cela, parce qu'ils n'acceptent pas le changement, ça me fatigue.[3]

          P.S.:véritable question : en cas d'incident, après récupération des logs binaires sur une autre machine, comment fait-on pour les lire ? Sur le coup et à l'époque à part coder moi-même quelque chose, j'avais pas trouvé.

          [1] sauf à considérer que les autres sont toujours des cons, et qu'ils savent pas (ce qu'ils font | travailler), il y a probablement eu des raisons qui ont poussées ces gens à faire telle ou telle chose. Souvent ces raisons étaient valables à un moment (le prosaïque « pas le temps », ou le classique « pas possible autrement techniquement » mais qui est possible quelques mois/années plus tard), et ne le sont plus plus tard
          [2] parce que c'est de cela dont il s'agit : ils sont en train de concevoir un nouvel OS
          [3] en revanche je comprends bien les réponses de Lennart qui ne pourrait pas faire avancer son projet en transigeant sur tout et n'importe quoi.
          [4] en bref si il y a un processus de discussion autour du nouvel OS désiré ; c'est bien ce qu'arrive à faire le C++, HTML, etc.

          • [^] # Re: Moui

            Posté par (page perso) . Évalué à 4.

            P.S.:véritable question : en cas d'incident, après récupération > des logs binaires sur une autre machine, comment fait-on pour
            les lire ? Sur le coup et à l'époque à part coder moi-même
            quelque chose, j'avais pas trouvé.

            La page d'aide de journalctl a une option

            --file=PATH           Show journal file
            

            Et j'ai testé sur une fedora 24

            journalctl --file /tmp/toto.journal
            

            , ça marche
            (ensuite, journalctl --file /tmp/toto.journla ne marche pas même avec un fichier toto.journla, donc j'ai aussi trouvé un bug curieux )

            • [^] # Re: Moui

              Posté par . Évalué à 2.

              Thanks !

              J'ai testé et n'ai pas eu de problème.

              Par contre c'est pas très résistant à l'altération du fichier (j'ai testé tantôt en modifiant l'entête, tantôt en modifiant ailleurs) ; mais bon c'est innérant au format, et puis peut-être qu'il y aura des outils de récupération plus tard.

  • # cet homme n'a jamais fait de production

    Posté par . Évalué à 10.

    Quand je lis la réponse, je me dis que ce mec ne sait pas ce que c'est que faire de la prod.

    Chez certains clients, il y a des environnements mutualisés.
    C'est à dire un OS avec plusieurs instances applicatives/databases hébergées dessus, et donc autant de users techniques différents.

    Pour peu qu'on normalise un peu les choses, parce que le client est un peu plus gros que d'autres, on choisit des plages d'uid, des règles de nommages, bref on arrive facilement à créer des non-system account (et cette notion est à mon sens toute relative…). Ou alors je n'ai pas compris ce qu'il veut dire ?

    Bref, il y a un risque de tomber dans le bug.

    Heureusement que redhat et oracle l'ont désactivé…c'est bien le moins que l'on attende d'un linux prêt pour l'entreprise.

    En tout cas, ça fait déjà deux journaux traitant de bug sur systemd en moins de 24 heures.

    Il n'en fallait pas plus pour amorcer le week-end.

    • [^] # Re: cet homme n'a jamais fait de production

      Posté par . Évalué à -1.

      Sauf qu'il n'avait pas volontairement conçu systemd pour emmerder les admin db, à la base c'était une mesure de sécurité.

    • [^] # Re: cet homme n'a jamais fait de production

      Posté par . Évalué à 2.

      Quand je lis la réponse, je me dis que ce mec ne sait pas ce que c'est que faire de la prod.

      Effectivement, c'est comme les développeurs de Gnome. Ils ne travaillent que sur leur produit, entre développeurs geeks dans leur petit monde, et ne savent pas comment ça fonctionne dans les entreprises, du coup on se retrouve avec des aberrations et des réponses à l'emporte-pièce. On casse des trucs qui fonctionnaient bien avant, parce que dans leur monde parfait de pisseurs de code, ça fonctionne très bien comme ça.

  • # FUD/troll

    Posté par . Évalué à -3.

    D'un autre côté, l'aura de FUD/troll autour de systemd permet de mettre en lumière les bugs qui apparaissent de manière rapide et espèrer qu'une correction/alternative emerge tout aussi rapidement. :)

    Quant au reste, systemd semble finalement être l'ami des vrais sysadmins.

  • # Systemd is defective by design

    Posté par (page perso) . Évalué à -10.

    Vous utilisez systemd, vous savez que vous aller forcément tomber sur des bugs très grave. C'est la définition même de systemd.

    Mais bon, on va attendre que les millennials se lassent de faire de l'admin système (ce qui ne devrait pas tarder, vu leur durée d'attention qui est proche de celle d'un poisson rouge, ils changeraient de job plus vite que de chemise, si ils ne changeaient pas déjà de chemise 2 fois par jour), et on pourra enfin reprendre de vrais outils.

  • # Et 4 mois plus tôt, chez Debian ...

    Posté par (page perso) . Évalué à 2.

    Ce problème ressemble à celui-ci, https://linuxfr.org/users/err404/journaux/attention-avec-systemd-tmux-ne-survit-plus-apres-la-fermeture-de-la-session

    Pour faire simple, dans une utilisation combinée de ssh + ("screen" ou "tmux"), ces derniers se coupaient lorsque que la connexion SSH tombait. Le "coupable" était une option de systemd activée par défaut dans Debian (en testing et +).

    Debian a rapidement corrigé le tir, en revenant au comportement par défaut de /etc/systemd/logind.conf .

    • [^] # Re: Et 4 mois plus tôt, chez Debian ...

      Posté par . Évalué à 5.

      Et toutes les lignes de commande finissant par "&"…

      Du coup toutes les distributions ont remis le comportement normal par defaut ce qui veux dire que systemd a fait une grosse connerie mais comme LP est un peu comme Trump il n'avouera jamais qu'il a eu tort "vu que il y a toujours la possibilite de changer le comportement dans un fichier de conf"…

      • [^] # Re: Et 4 mois plus tôt, chez Debian ...

        Posté par . Évalué à 1.

        LP est juste encore dans le monde universitaire ou il vaut mieux que les étudiants qui se déloguent de postes Linux ne laissent pas de process tourner en arrière plan.

        Le monde de la prod professionnelle en étant un autre.

      • [^] # Re: Et 4 mois plus tôt, chez Debian ...

        Posté par . Évalué à -1.

        L'idiot du village qui se crée un deamon à l'arrache, sincèrement je me tamponne de savoir que son hack ne fonctionne plus.

        Le fait de nettoyer par défaut est sein. C'est un fait et le fait que ça fasse chialer certains montre que c'est nécessaire.

        Il faut et il suffit d'avoir une procédure claire et simple pour le faire. Comme ça on a une vraie maîtrise de ce qui tourne ou pas sur une machine, on la garde vraiment propre et la portabilité avec d'autres systèmes on s'en fout. C'est quelque chose qui est de l'ordre de la procédure d'installation ça n'était pas plus portable avant que maintenant (sinon il faut aussi se plaindre des systèmes qui activent selinux et qui retirent du coup tel ou tel droit, dont tout le monde a absolument besoin etc etc…)

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Et 4 mois plus tôt, chez Debian ...

          Posté par (page perso) . Évalué à 7.

          Deux fois que tu te trompes d'homonymes dans cette dépêche, alors je me dois de faire mon grammar nazi pour t'éviter la troisième :

          • sein = organe pair très développé situé à la partie antérieure du thorax chez la femme, et qui contient la glande mammaire
          • sain = qui ne présente aucune atteinte pathologique ou anomalie (par opposition à malade)

          Donc ta phrase devient plus compréhensible écrite comme ça :

          « Le fait de nettoyer par défaut est sain. »

          Sur ce, bon dimanche !

        • [^] # Re: Et 4 mois plus tôt, chez Debian ...

          Posté par (page perso) . Évalué à 7.

          Le fait de nettoyer par défaut est sein.

          Non, ça fait planter weboob.

          * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

          • [^] # Re: Et 4 mois plus tôt, chez Debian ...

            Posté par . Évalué à -2.

            C'est que son intégration et/ou son installation est mal faite. Que ça fasse planter weboob, tmux ou le dernier logiciel que tu adore ne change pas grand chose. C'est simple à corriger on corrige.

            C'est quoi cette manière de ne pas vouloir trouver à son code et son packaging ? Il faut absolument que ni les api ni l'intégration change… Créez des logiciels pour des plate-forme précises et ce sera le cas (il y en a qui le font).

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Et 4 mois plus tôt, chez Debian ...

              Posté par . Évalué à 7.

              Un peu hors-sujet ta réponse à un commentaire qui faisait un jeu de mots entre ta faute d'orthographe sur « sein » (au lieu de « sain », comme expliqué dans un autre commentaire) et son équivalent anglais « boob ». ;-)

              Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: Et 4 mois plus tôt, chez Debian ...

          Posté par . Évalué à 3.

          je ne comprends pas cette manie ou ce zèle, de demander ou de laisser systemd faire ce que l'OS fait très bien depuis plus de trente ans…

          • [^] # Re: Et 4 mois plus tôt, chez Debian ...

            Posté par . Évalué à 4.

            Par OS tu entends noyau ? Parce que pour la plupart des gens systemd fait parti de l'OS.

            Le noyau choisi de dézinguer tes processus ? Si tu parle de l'OOM killer, il fait ce qu'il peut, mais prends souvent de mauvaises décisions.

            Pour les IPC, je suis intéressé de savoir quand et comment il choisi.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Et 4 mois plus tôt, chez Debian ...

        Posté par . Évalué à 2.

        Et toi, c'était quand le dernière fois que t'as admit que t'avais raconte des conneries?
        Non, parce que tu débites un sacré paquet de troll à la minute quand même.

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

        • [^] # Re: Et 4 mois plus tôt, chez Debian ...

          Posté par . Évalué à 0.

          Mais mon petit spermy tu sais tres bien que je suis un debile profond qui ne raconte que des conneries. Alors que toi tu ne dis que des verite, ne fais jamais d'attaque ad hominem et justifie toutes ses affirmations.

          Dommage que tu es oublie dans ce message le lien montrant que je disais des conneries et que nohup n'avait pas ete casse dans la configuration par defaut par systemd mais je suis sur que tu vas repare cet oublie.

          • [^] # Re: Et 4 mois plus tôt, chez Debian ...

            Posté par . Évalué à -1.

            nohup n'a pas été cassé, non.
            Le process ignore toujours sighup. Systemd envoie un sigterm/sigkill.

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

            • [^] # Re: Et 4 mois plus tôt, chez Debian ...

              Posté par . Évalué à 7.

              https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=825394;msg=30

              Amusant moi je suis un debile, tout le monde le sait! Du coup je me rabat sur un message d'un devs debian qui dit clairement:

              You are missing the point. The way people using Linux (or any UNIX for
              that matter) have been starting background processes for the last 30
              years is to just run it with nohup & or in a screen session.
              Now suddenly systemd wants to change this, by having you jump through
              extra hoops.

              Apres tu vas dire que ce n'est pas casse car tu peux contourner le truc et le lancer. Le truc c'est que TOUTES les distributions ont pris la solution logique: On degage cette option (debile) de systemd.

              Juste pour rire meme un devs systemd te contredit:

              Systemd breaks Screen, tmux, nohup

              Systemd contributor Christian Rebischke suggests to use systemd-run instead of POSIX standard utilities like nohup

              Utiliser systemd-run c'est tellement plus simple que mettre un simple "&" comme cela se fait depuis 30 ans…

              • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                Posté par . Évalué à -1.

                Ben écoutes, lit la man page de nohup, et revient me dire que ca devrait survivre à un sigkill,
                Tout ce que man dit, c'est que le process survit nohup quand le controlling terminal est fermé. Pas que lorsque la session est fermée, tous les zombie doivent rester vivant, highlander style, contre vents et marée, même quand pinpin au pays des trululu a décider de ssh dans une machine de prod et nohup un process à la rache et l'oublier la.

                Si t'as un workflow digne de Windows 98, ca ne regarde que toi.

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

                • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                  Posté par . Évalué à 6. Dernière modification le 04/10/16 à 16:38.

                  Quel rapport avec les zombies ?

                  Les zombies orphelins sont nettoyés par init depuis la nuit des temps, c’est pas une nouveauté de systemd. Les zombies non orphelins n’ont pas à être nettoyés puisque leur père peut très bien vouloir récupérer leur code retour plus tard (et systemd ne les nettoie pas).

                  Si t'as un workflow digne de Windows 98, ca ne regarde que toi.

                  Quitte à troller, je dirai que le workflow digne de Windows 98, ce serait bien de se dire « je laisse ma session ouverte parce que si je la ferme apache.exe de mon WAMP va se faire tuer ».

                  • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                    Posté par . Évalué à 2.

                    Quitte à troller, je dirai que le workflow digne de Windows 98, ce serait bien de se dire « je laisse ma session ouverte parce que si je la ferme apache.exe de mon WAMP va se faire tuer ».

                    Ce workflow est pas tellement mieux que:
                    ssh user@host
                    nohup httpd &
                    Ctrl d

                    Je vois pas ce qu'il y'a de délirant a tuer les process lancés manuellement par un utilisateur quand il se délogge.
                    Si tu veux que ca tourne en tache de fond, fais en un vrai service, ou dit a systemd que c'est un service ad hoc (e.g. une tâche qui tourne longtemps en background et va se terminer toute seule).

                    Les zombies, c'était une façon de parler.

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

                    • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                      Posté par . Évalué à 3. Dernière modification le 04/10/16 à 17:44.

                      Je vois pas ce qu'il y'a de délirant a tuer les process lancés manuellement par un utilisateur quand il se délogge.

                      Parce qu’un utilisateur peut très bien avoir de bonnes raisons pour vouloir avoir des processus sans avoir de session (liste non exhaustive) :

                      • screen/tmux
                      • un job long terme (encodage d’une video par exemple)
                      • download/seed d’un client bittorrent
                      • programme type seti@home

                      Sinon non, ça n’a rien de délirant tant qu’une alternative crédible est proposée pour permettre les mêmes fonctionnalités. Je n’en vois pas. Sur le principe, ce serait certainement une bonne idée de faire ça si on créait un système de novo, sans historique à gérer. Scoop : ce n’est pas le cas de Linux.

                      Si tu veux que ca tourne en tache de fond, fais en un vrai service

                      1. La méthode idiomatique pour se faire depuis des décennies c’est de faire une tâche de fond de ce type un orphelin. Pourquoi vouloir à ce point casser une convention qui marche somme toute pas trop mal (pas parfait on est d’accord, mais c’est pas comme si la solution systemd était parfaite elle) ?

                      2. systemd ne fournit aucune alternative accessible à l’utilisateur (systemd-run nécessite les droits root, créer un service systemd nécessite les droits root)

                      3. systemd ne fournit aucune alternative interopérable

                      • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                        Posté par (page perso) . Évalué à 6. Dernière modification le 04/10/16 à 18:04.

                        systemd ne fournit aucune alternative accessible à l’utilisateur (systemd-run nécessite les droits root, créer un service systemd nécessite les droits root

                        Euh, ou pas en fait… l’option --user est là pour ça, non ?

                  • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                    Posté par . Évalué à 2.

                    Enfin n'oublions pas la vrai raison de cette option dans systemd c'est que Gnome et Pulseaudio laisse plein de merde qui tourne derriere apres un logout…

                    • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                      Posté par (page perso) . Évalué à -3.

                      https://forum.kde.org/viewtopic.php?f=15&t=90508

                      I've noticed that even after closing KDE and the X server several KDE processes are still shown in htop, notably virtuoso-t, nepomukserver, knotify and various kdeinit4 kio_somethings. I'm no developer, but shouldn't all of these processes been closed properly?

                      https://ubuntuforums.org/showthread.php?t=1883631

                      been using k3b since 8o4 and never looked until now. I see three kde processes left over after closing k3b.

                      Ta gueule merci.

                      • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                        Posté par . Évalué à 4.

                        Ouhais kde4 (qui est mort) et tu as tout de meme un trouve un message de … 2010 et l'autre de 2011 et "chez moi" (quand j'avais encore kde4 ie il y a 1 mois) je n'avais pas/plus ce comportement. Par contre je te defie de fermer une session gnome sans avoir des gvfsd, zeitgeist, gconf dans tout les sens et ce avec la toute derniere version de gnome (sans avoir systemd qui fait le menage naturellement).

                        PS: tu peux aussi rester polis cela ne tueras pas ton chat.

                • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                  Posté par . Évalué à 3.

                  Si t'as un workflow digne de Windows 98

                  Comment dire… Tu as compris que nous parlons de Linux (Unix)? J'ai comme l'impression que tu as rate un episode…

                  • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                    Posté par . Évalué à -2.

                    Ah oui, tu m'en diras tant. on dirait une réponse de Trump quand on lui a cloué le bec. T'es la pour rendre Linux grand à nouveau?

                    Et donc, sinon, la man page de nohup, elle dit quoi au sujet de sigterm, sigkill et la fermeture de la session utilisateur?

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

                    • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                      Posté par . Évalué à 2. Dernière modification le 04/10/16 à 18:12.

                      > man nohup
                      
                      
                      NOHUP(1)                                                                                                        User Commands                                                                                                        NOHUP(1)
                      
                      NAME
                             nohup - run a command immune to hangups, with output to a non-tty
                      

                      https://linux.die.net/man/1/nohup

                      Ce que casse bien systemd mais bon tu es plus fort que tout le monde y compris les personnes qui font les distributions. Chapeau l'artiste.

                      • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                        Posté par . Évalué à 1.

                        systemd n'envoie pas un hangup.
                        L'appli survit au hangup. Par contre, ya rien qui dit que lorsque l'utilisateur se déloge, l'init est pas cense nettoyer les process qui n'ont rien a foutre la a coup de sigterm/sigkill.
                        C'est juste pas documente, tu peux pas casser quelque chose qui n'est pas documente.

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

                        • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                          Posté par . Évalué à 5. Dernière modification le 05/10/16 à 02:33.

                          23.4 ‘nohup’: Run a command immune to hangups
                          =============================================
                          
                          ‘nohup’ runs the given COMMAND with hangup signals ignored, so that the
                          command can continue running in the background after you log out.
                          

                          so that the command can continue running in the background after you log out

                          Bah quand même, quand je lis ça je peux espérer que ma commande ne se terminera pas si je me délogue. Que ce soit par un signal ou pour n’importe quelle autre cause liée à l’OS… (sauf OOM ou truc du genre…)

                          • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                            Posté par . Évalué à 0.

                            lit toutes les pages man, aucune ne mentionne de logout, uniquement "immunité au sighup". Ce qui parait logique, sinon la commande serait appelée nologout.
                            Que la doc GNU fasse un raccourci sighup == log out illustre bien l'ampleur du problème et a quel point des guignols comme Albert passent pour des clowns (et encore je met le L pour rester poli).

                            nohup est documente comme "le process resistera a sighup".
                            La doc de sighup dit "le signal est envoye quand le controlling terminal est ferme".

                            rien ne documente ce qu'il se passe quand la derniere session de l'utilisateur est fermée (i.e. quand l'utilisateur se délogue).
                            ET C'EST TRES PRECISEMENT LE PROBLEME QUE SYSTEMD ADDRESSE.

                            C'est une sémantique qui est complètement absente de posix, et cette absence de sémantique a mene au bordel actuel.

                            Pour revenir a l'enculage de mouche initial: systemd a change un comportement non documente. Donc systemd n'a rien casse, vu qu'il n'y a rien de documenter.
                            Albert_ Trump le windowsien reposait depuis des années sur un details d'implementation non documente qui pouvait changer a tout moment pour faire son admin comme un clampin, et vient par derriere donner des leçons, comme a son habitude.

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

                          • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                            Posté par . Évalué à 3.

                            C'est marrant personnellement, je découvre avec cette histoire que nohup est sensé rendre le processus immortel à mon logout. Moi je m'en servais juste pour qu'il survivre au pseudo terminal qui me lance.

                            C'est d'autant plus piégeux que l'option nohup dont je me sert maintenant à la place de l'outil nohup, fait exactement ce que j'attends (et heureusement en fait…).

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                          Posté par . Évalué à 4.

                          Par contre, ya rien qui dit que lorsque l'utilisateur se déloge

                          Bah, c’est pour ça qu’il y a une hiérarchie de process, quand tu tues le processus qui gère ta session, tu tues aussi tous ces enfants. Nohup sert justement à sortir de cette hiérarchie pour pouvoir résister à la fermeture. Je faisait ça sous MS-DOS avec l’appel système TSR (Terminate and Stay Resident).

                          Que tu penses que c’est la bonne façon de faire, pourquoi pas. Mais il faut avouer que systemd change les comportements par défaut connu et attendu provoquant des bugs sur un système ayant un historique conséquent.

                          La prochaine étape c’est quoi ? l’inclusion de zsh et l’interdiction de bash ? Bah oui, c’est vraiment stupide d’avoir plusieurs shell incompatible entre eux.

                          • [^] # Re: Et 4 mois plus tôt, chez Debian ...

                            Posté par . Évalué à 2.

                            Quand ip(8) est arrivé en dépréciant ifconfig(8), on en a pas fait tout un fromage. Pourtant ce dernier (ou netstat -ie) est plus agréable pour avoir des infos un peu complètes en une commande simple.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Et 4 mois plus tôt, chez Debian ...

        Posté par (page perso) . Évalué à 3.

        Jusqu'à récemment, toutes les distribution avait comme config SSH par défaut, l'autorisation pour root de se connecter. Les développeurs de SSH avaient-ils fait une erreur de développer ce comportement ?

        « 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: Et 4 mois plus tôt, chez Debian ...

        Posté par . Évalué à 6.

        Impressionant il y a 7 personnes qui trouve normal de casser nohup sur un syteme linux!!!!!

Suivre le flux des commentaires

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