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 Sébastien Maccagnoni (site web personnel) . É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…
# Moui
Posté par Sébastien Le Ray . É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 neologix . É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 Sébastien Le Ray . É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 Antoine . Évalué à 4.
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 Sébastien Le Ray . Évalué à 7.
Le fait de ne pas laisser de ressources traîner sur un système multi-utilisateurs ?
[^] # Re: Moui
Posté par Antoine . É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 Dr BG . Évalué à 5.
Arrêter les processus utilisateur seulement quand l'utilisateur n'a plus de processus ?
[^] # Re: Moui
Posté par Antoine . É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 Dabowl_75 . Évalué à 1.
ou juste laisser l'OS faire son boulot…
[^] # Re: Moui
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 30 septembre 2016 à 10:40.
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 Moonz . Évalué à 10.
Pourquoi diable exclure d’office l’idée que l’utilisateur puisse avoir un démon ?
[^] # Re: Moui
Posté par totof2000 . É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 gnumdk (site web personnel) . Évalué à -2.
Si tu as des serveurs Linux avec GUI, c'est toi qui est triste…
[^] # Re: Moui
Posté par benja . É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 totof2000 . Évalué à 2.
tu laisses une session ouverte sous Postgres pour que Postgres ne plante pas …
[^] # Re: Moui
Posté par gUI (Mastodon) . Évalué à 8.
du coup, la bonne façon de faire c'est quoi ?
ça marche ça ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Moui
Posté par Dabowl_75 . Évalué à 10.
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 ckyl . Évalué à -5. Dernière modification le 30 septembre 2016 à 14:50.
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 Dabowl_75 . Évalué à 5.
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
+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 sheldoncooper . É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 Moonz . Évalué à 5. Dernière modification le 30 septembre 2016 à 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é.
[^] # Re: Moui
Posté par barmic . Évalué à 6.
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 Dring . É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 barmic . É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 Moonz . Évalué à 10. Dernière modification le 30 septembre 2016 à 16:59.
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.
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.
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 barmic . É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 Xavier Teyssier (site web personnel) . É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 lem__mel . Évalué à 8.
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 Misc (site web personnel) . Évalué à 4.
La page d'aide de journalctl a une option
Et j'ai testé sur une fedora 24
, ç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 lem__mel . É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 Dabowl_75 . É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 MTux . É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 Albert_ . Évalué à 10.
Oui en effet comme empecher l'utilisation de screen c'est pour ta securite.
[^] # Re: cet homme n'a jamais fait de production
Posté par zurvan . Évalué à 2.
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.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# FUD/troll
Posté par Le Gab . É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 Ramón Perez (site web personnel) . É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.
[^] # Re: Systemd is defective by design
Posté par Maclag . Évalué à 5.
C'est super pour un vendredi, mais avec des motards et de l'anti-avortement, ça aurait été le combo ultime!
[^] # Re: Systemd is defective by design
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Et systemd est vulnérable aux boules de pétanque aussi.
# Et 4 mois plus tôt, chez Debian ...
Posté par Olivier (site web personnel) . É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 Albert_ . É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 farib . É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 xcomcmdr . Évalué à -4.
Ne pas nettoyer, c'est tellement sain.
Windows98
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par barmic . É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 Joël Thieffry (site web personnel) . É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 :
Donc ta phrase devient plus compréhensible écrite comme ça :
Sur ce, bon dimanche !
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par Tonton Th (Mastodon) . Évalué à 7.
Non, ça fait planter weboob.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par barmic . É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 kantien . É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 barmic . Évalué à 1.
Effectivement….
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 Dabowl_75 . É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 barmic . É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 groumly . É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 Albert_ . É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 groumly . É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 Albert_ . É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:
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
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 groumly . É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 Moonz . Évalué à 6. Dernière modification le 04 octobre 2016 à 16:38.
Quel rapport avec les zombies ?
Les zombies orphelins sont nettoyés par
initdepuis 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).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 groumly . Évalué à 2.
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 Moonz . Évalué à 3. Dernière modification le 04 octobre 2016 à 17:44.
Parce qu’un utilisateur peut très bien avoir de bonnes raisons pour vouloir avoir des processus sans avoir de session (liste non exhaustive) :
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.
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) ?
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)
systemd ne fournit aucune alternative interopérable
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par Lucas . Évalué à 6. Dernière modification le 04 octobre 2016 à 18:04.
Euh, ou pas en fait… l’option
--userest là pour ça, non ?[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par Albert_ . É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 Sufflope (site web personnel) . Évalué à -3.
https://forum.kde.org/viewtopic.php?f=15&t=90508
https://ubuntuforums.org/showthread.php?t=1883631
Ta gueule merci.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par Albert_ . É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 Albert_ . Évalué à 3.
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 groumly . É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 Albert_ . Évalué à 2. Dernière modification le 04 octobre 2016 à 18:12.
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 groumly . É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 Marotte ⛧ . Évalué à 5. Dernière modification le 05 octobre 2016 à 02:33.
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 groumly . É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 plustôt,chez Debian ...
Posté par Juke (site web personnel) . Évalué à 2.
et c'est comment sur Macintosh ?
[^] # Re: Et 4 mois plustôt,chez Debian ...
Posté par groumly . Évalué à 2.
J'en sais trop rien, on a launchd pour faire ce genre de truc.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Et 4 mois plustôt,chez Debian ...
Posté par Albert_ . Évalué à 2.
Se servir d'un mac pour un serveur c'est comme se servir d'un linux pour jouer voir pire!
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par Tonton Th (Mastodon) . Évalué à 6.
Pour moi, c'est quand même assez clair.
http://www.gnu.org/software/coreutils/manual/html_node/nohup-invocation.html
so that the command can continue running in the background after you log out.
http://man.openbsd.org/OpenBSD-5.9/man1/nohup.1
The nohup command allows the specified utility to be protected from termination if the user should become logged out […] The nohup utility is compliant with the IEEE Std 1003.1-2008 (“POSIX.1”) specification.
Maintenant, je ne sais pas comment ça se passe chez AIX, Irix, SunOS, SCO, et autres Sinix, mais mon petit doigt me dit que c'est en gros la même chose.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par Albert_ . Évalué à 3.
Mais arrete bientot on va croire que Groumly est un, comment il dit deja, ah oui un guignol et un clown…
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par barmic . É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 Anthony Jaguenaud . Évalué à 4.
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 barmic . Évalué à 2.
Quand
ip(8)est arrivé en dépréciantifconfig(8), on en a pas fait tout un fromage. Pourtant ce dernier (ounetstat -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 Albert_ . Évalué à 2.
Les distribs en ont pas fait un fromage, elles ont juste enlever ce comportement idiot.
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par claudex . É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 Albert_ . Évalué à 6.
Impressionant il y a 7 personnes qui trouve normal de casser nohup sur un syteme linux!!!!!
[^] # Re: Et 4 mois plus tôt, chez Debian ...
Posté par xcomcmdr . Évalué à 8.
Vous ne croirez pas la 7ème !!!
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.