Je me sers tous les jours de Tmux (Terminal multiplexer). https://fr.wikipedia.org/wiki/Tmux
C'est un outil très pratique pour garder du travail en cours en tache de fond.
Sauf que depuis une récente mise à jour de ma Debian sur mon poste utilisateur, j'ai mon tmux qui est tué lorsque je me déconnecte (tmux est censé continuer à travailler en arrière plan).
Or ces derniers temps j'avais lu vite fait une information comme quoi les devs de systemd avaient (encore) changé un comportement par defaut, et en l'occurrence sur la façon de gérer les processus orphelins ou zombies.
Ce qui me dérange le plus c'est que si le problème est connu (au moins par les devs ou par les packageurs), pourquoi il n'y a pas dpkg qui m'avertis lors de la mise à jour de systemd que le comportement par defaut a changé.
Je parle de dpkg, mais ça concerne aussi les autres gestionnaires de paquets.
C'est si compliqué de prévenir d'un changement du comportement par defaut lors de la mise à jour???
pour ceux qui voudraient éviter ce genre de tracas, il y a au moins deux solutions:
- ne pas utiliser tmux ou systemd (je me passerais bien de systemd qui ne m'apporte rien par rapport à l'ancien système d'init)
- appliquer la solution décrite ici: https://github.com/systemd/systemd/blob/master/NEWS#L3 (il parait qu'il faut recompiler systemd, il n'y a vraiment pas une option à changer quelque part lorsque on ne souhaite pas recompiler systemd?)
Si vous avez une solution élégante, je suis preneur.
# Bug ferme chez tmux
Posté par Manozco . Évalué à 4.
Si ça peut t'aider, ca semble lie a ce bug sur le GitHub de tmux:
https://github.com/tmux/tmux/issues/428
[^] # Re: Bug fermé chez tmux
Posté par err404 (site web personnel) . Évalué à 5. Dernière modification le 03 juin 2016 à 01:04.
Merci beaucoup.
Donc, si je comprend bien, je devrais lancer tmux avec la commande suivante:
systemd-run --scope --user tmux
sauf que ça me renvoit:
Failed to create bus connection: Operation not permitted
(c'est un tmux que je lance en tant que Root, c'est un comble :p )
[^] # Re: Bug ferme chez tmux
Posté par karchnu . Évalué à 10.
Bug de tmux ? En quoi ? Parce qu'il n'intègre pas du code spécifique à un système d'init en upstream ?
[^] # Re: Bug ferme chez tmux
Posté par err404 (site web personnel) . Évalué à 4. Dernière modification le 03 juin 2016 à 02:40.
Ce n'est pas un bug de Tmux, mais ça n'empêche pas que ça apparaissent dans leur rapport de bug.
Le rapport de bug est fermé justement parce que ça ne concerne pas tmux, mais bien systemd et leur choix arbitraire à la va-vite.
Vu sur le Web, mais je ne sais plus où:
En gros, il existe une petite fonction, Daemon(), qui fonctionne de façon inchangée depuis 30 ans, simplement et sur des multiples plateformes. alors que pour obtenir la même chose aujourd'hui, il faudrai ajouter 150 lignes de code spécifique à Linux ET ajouter une dépendance à une bibliothèque.
Je crois que je vais laisser tomber Debian (que j'utilise depuis 1997 mais avec de moins en moins de satisfaction) et je vais aller voir du coté de Gentoo qui laisse plus de choix à l'utilisateur final. (je vais passer un peu de temps à compiler…)
c'est dommage, j'aimais bien le contrat social de Debian. je reviendrais peut-être à Debian un jour, il y a assez de distributions GNU/Linux pour avoir encore un peu de liberté.
[^] # Re: Bug ferme chez tmux
Posté par Ph Husson (site web personnel) . Évalué à 10.
Pour un OS multi-utilisateurw c'est le comportement "standard" qui est aberrant.
Sur une machine d'université (pour prendre un pire cas), si chaque personne qui se connecte sur l'ordinateur a un processus persistant à vie, il faut redémarrer la machine tous les trois jours.
La manière de faire peut-être discutable, mais à moins de prendre Windows, il n'existe pas D'API pour exprimer ce genre de besoins.
Et non daemonize n'exprime pas la persistance sur une session. Il exprime juste l'indépendance avec le shell appelant.
Par exemple, en situation difficile je fais des nohup firefox&, qui a la même sémantique que daemonize.
Fort heureusement dans ce cas, la notion de session est définie par X, et je fais confiance à firefox pour se suicider quand il perd le serveur X.
Aussi, systemd garantit de connaître la liste des processus persistants, alors que la sémantique de daemonize ne le permet pas.
Bref, comme d'hab avec systemd, on peut éventuellement reprocher le manque de documentation, et encore, cf le commentaire "NEWS", mais systemd apporte une vraie avancée technique.
[^] # Re: Bug ferme chez tmux
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
Juste un petit commentaire en passant concernant ceci :
Bien d'accord avec vous. C'était d'ailleurs le comportement par défaut de la plupart des systèmes. Jusqu'à récemment sur mes machines de calculs pour éviter de perdre le calcul à la rupture de la connexion ssh, je conseillais à mes utilisateurs d'employer des logiciels comme screen. Si je comprends bien tmux est un peu du même genre ?
Ores, sur ubuntu serveur 16.04 — et malgré systemd, ou à cause de réglages adaptés de celui-ci — les processus lancés dans un bash normal ne sont plus tués lors de la déconnexion. Très pratique d'un point de vue utilisateurs. Mais effectivement je m'attend à quelques surprises sur le long terme.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Bug ferme chez tmux
Posté par zul (site web personnel) . Évalué à 10.
Oui screen et tmux font globalement la même chose. Donc screen est aussi cassé par cette modif. Et puis nohup aussi. Mais systemd c'est bien, mangez en.
[^] # Re: Bug ferme chez tmux
Posté par Tonton Th (Mastodon) . Évalué à 7.
Et on le remplace par quoi ?
[^] # Re: Bug ferme chez tmux
Posté par karchnu . Évalué à 9.
Visiblement systemd. Tout ce dont nous parlons jusqu'à présent c'est bel et bien du fonctionnement qui est normal pour un processus. Par défaut il se fait tuer lorsqu'on se déconnecte (du terminal, pas de la session). Donc « ce qui est amélioré » c'est juste que même lorsqu'on a décidé de laisser un processus fils continuer après la mort du père (le terminal), il se fera tuer si on quitte la session.
Ça n'apporte strictement rien. Les quelques (rares) programmes qui continuent de fonctionner sans qu'on n'ait à utiliser nohup, et où ça n'a pas trop de sens (ex: firefox) doivent être patchés au cas par cas, ce n'est en aucun cas un patch à appliquer à tous les programmes dont leur fonction est de continuer après la mort du terminal. nohup est là pour justement permettre à des applications de survivre, et ça fonctionne comme ça sur tous les unix-like du monde. Rien ne justifie de faire une exception sous linux.
[^] # Re: Bug ferme chez tmux
Posté par Ph Husson (site web personnel) . Évalué à 0.
Le problème est dans le "on"
Dans un cas la logique du "on" est clair, c'est géré par systemd
Dans l'autre cas, c'est… dépendant de chaque programme!
J'ai plus confiance en systemd qu'en hot-babe (exemple de programme alacon probablement codé à l'arrache) pour nettoyer les ressources du second en cas de problème.
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 3.
Encore heureux que le fonctionnement du programme soit géré par chaque programme …
Et commencer à considérer que le systemd est là pour faire le ménage dans le fonctionnement des programmes utilisateurs est… comment dire…
[^] # Re: Bug ferme chez tmux
Posté par WhiteCat . Évalué à 1.
Le kernel aussi peut se mêler du fonctionnement des programmes en les killant s'il le faut. Vraiment honteux de la part du kernel : qu'il se mèle de ses affaires à la fin !!
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 5.
?
C'est le taff du kernel de gérer les processus et de les contrôler.
J'avoue que j'ai un peu du mal à comprendre l'humour de la réponse.
Systemd est un système d'initialisation/de démarrage.
Considérer que c'est normal, et même intéressant, qu'il kill les process que l'utilisateur a lancé de son propre chef, car il considère que la session est finie et donc il sait mieux que l'utilisateur ce qui doit être fait est une pente savonneuse.
Je peux le comprendre dans le cadre d'un "workaround" (moi même je me suis déjà amusé à killer les multiples démons de kde une fois un programme utilisant kde étant arrêté)
Mais là on applique un workaround de façon globale, sans aucune réflexion.
Méthode windows quoi "on a un problème, on reboot plutôt qu'essayer de résoudre le problème".
Qu'il le permette, c'est très bien. Qu'il soit mis par défaut, c'est contre productif.
[^] # Re: Bug ferme chez tmux
Posté par WhiteCat . Évalué à 1. Dernière modification le 04 juin 2016 à 13:12.
Comme son nom l'indique, systemd est bien plus qu'un système d'init. Il harmonise, améliore, simplifie et par conséquent fiabilise un gros pan du système Linux.
Étant donné que son rôle est de gérer les services et tout un tas d'autres choses, je ne trouve pas anormal qu'il puisse effectuer des actions sur des processus et service, tout comme le kernel peut le faire.
Après le problème ici c'est qu'un paramètre par défaut est modifié et casse des programmes. En général un paramètre par défaut est un paramètre qui est le plus sécurisé, utile et fiable pour la majorité des utilisateurs. Est-ce que l'usage de tmux/screen est un cas d'usage de la majorité des utilisateurs ? Je ne pense pas.
Personnellement j'ai utilisé plusieurs fois screen qui était indispensable (Mining Ethereum ou serveur Minecraft par exemple). Mais pour le reste des serveurs que je peux être amené à administrer (dans le cadre de mon taf), j'aime autant que le paramètre par défaut soit le meilleur, et que pour mes cas spécifiques d'utilisation je change le paramètre KillUserProcess à no.
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 3.
On a pas besoin de discours marketing sur un site technique…
Non, pas "tout un tas d'autres choses", non définis, et complètement abstraite.
Tu remarqueras que j'ai jamais dit qu'il ne pouvait pas faire des actions sur les processus. J'ai parlé de ce choix précis et qu'il outrepassait ses fonctions, pour des raisons argumentées…
Et comparer systemd au kernel, c'est pour le lol ?
Quelqu'un s'amuse à comparer le moteur au système de transmission , sous prétexte que c'est dans une voiture ?
Surtout que le paramètre par défaut n'a pas lieu d'être, car devrait être activé au cas par cas, en attendant la résolution réelle du problème.
Merci d'arrêter de penser ce qui est bon pour les autres, et de décider tout seul qui constitue la majorité, ou ce que devrais faire ou ne pas faire ladite majoritée.
Le but de linux est que chaque utilisateur puisse faire ce dont il a besoin. Pas de devoir suivre/respecter certaines contraintes parce que WhiteCat ou Lennart ou Tartenpion à décidé que la "majoritée" ne devait pas lancer de commandes en nohup sans d'abord demander à son sysadmin de désactiver des paramètres obscurs dans le système d'init…
La question que pose ce paramètre est : "Est ce que cacher les problèmes et ne pas s'en occuper est une bonne solution ?".
La réponse, pour n'importe qui de technique, et j'espère que linuxfr reste un site où on peut parler technique, serait "non".
Cool pour toi. Surtout sachant que l'utilisation du terme "meilleur" ne veut rien dire dans ce cas. (Pourquoi un cas d'utilisation serait "meilleur" que l'autre ? )
Et sachant que dans la vrai vie, les utilisateurs n'ont pas tous les pouvoirs root, et peuvent avoir besoin de cette fonctionnalités … de base. Et que si tu en as besoin au cas par cas… Ben faut pas oublier la modif…
Ps : c'est sur qu'on sent que le mining c'est trop dans le cadre du taff… Et que si c'est ta seule utilisation de screen, ça en dit long sur ce que tu peux être à "amené à administrer dans le cadre de ton taff". (Non pas que ce soit bien ou pas, juste ne vient pas expliquer aux gens qui font autre chose que toi comment ils doivent travailler, et pourquoi ton "je modifie les trucs un à un quand je sais que j'en aurais besoin" ne rentre pas dans un cadre un poil plus industriel/sous charge etc…)
[^] # Re: Bug ferme chez tmux
Posté par groumly . Évalué à 6.
Ben d'un autre côté, laisser le problème apparent depuis toujours n'a pousse personne à corriger le problème.
KDE a toujours laissé des process survivre la session quand ils auraient pas dû, et personne n'a rien fait contre ca.
Et mon petit doigt me dit que c'est parce qu'ils ne peuvent pas vraiment d'ailleurs.
La on a solution qui résoud le problème correctement dans 99% des cas, avec un cas spécial simple pour les 2 programmes qui posent problème (screen et tmux).
Alors du coup, tu proposes quoi pour corriger ce problème?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Bug ferme chez tmux
Posté par GG (site web personnel) . Évalué à -2.
Tu veux dire que les processus qui survivent à la fermeture d'une session KDE sont si problématique????
Ça consomme tant de ressources que ça ces processus?
Et, cela justifierait de tuer TOUS les processus qui resteraient actif après la fermeture d'une session (accidentellement ou pas)?
Vraiment, il y a exagération, et il est préférable de corriger le fonctionnement de KDE pour ce genre de cas, mais si personne ne l'a fait, c'est probablement parce que ce n'est pas génant. D'ailleurs, il y a peut être des rapports de bug à ce sujet, non?
Et, pour ceux qui n'utilisent pas KDE… faut aussi supprimer les processus qui restent actifs après la fin de la session?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Bug ferme chez tmux
Posté par groumly . Évalué à 2.
Je te retourne la question, démarrer tmux/screen via systemd est si problématique que ca?
Aaaah, la bonne vieille philosophie du "ca fait pas ce que devrait, mais on va pas le corriger".
Que je t'entende pas prôner la supériorité et efficacité de Linux sur le desktop toi, parce que tu vas te prendre cette citation dans les dents.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Bug ferme chez tmux
Posté par GG (site web personnel) . Évalué à 1.
Avant de pouvoir le lancer avec systemd-run (il faut deviner que c'est avec ça qu'on doit s'y prendre maintenant), il faut autoriser l'utilisateur à le faire…
Perso, je trouve ça bien plus compliqué que de lancer simplement tmux, screen ou nohup…
Ah? mais je trouve que Linux est prêt pour le Desktop, depuis bien longtemps, et c'est même le meilleurs.
C'est juste devenu pénible avec la nouvelle version de Systemd, puisque cela oblige à vérifier si la machien sur laquelle on voudra lancer un tmux a la nouvelle version de systemd ou pas.
J'aime pas Redhat depuis des années, c'est pas pour rien.
Avec Debian, on installe pdns-recursor, par exemple, il va être activé par défaut au boot, et sera lancé à la fin de l'installation.
Avec Redhat… il fautr faire un chkconfig sinon le service ne sera pas lancé au prochain boot… j'ai déjà observé dans plusieurs entreprises des problèmes DNS parce qu'ils avaient oublié de faire ce réglage sur leurs machines Redhat… problème qu'on a pas chez Debian.
Redhat, et systemd appportent beaucoup de problèmes. Je suis curieux de savoir lesquels sont résolus. Sincèrement, avec systemd, la plupart de mes machines sont devenues lente à l'extinction.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par needs . Évalué à 8.
Je ne prétends pas répondre à la place de Grégoire G, ce serait malvenu, mais tu exagères son propos et tu lui fais dire ce qu'il n'a pas dit.
Il ne prétend pas que « c'est de la merde », il préfère Debian à RedHat, sans pour autant qualifier RedHat de « merde ».
Il n'a pas dit le contraire. Il mentionne juste un cas précis, et tu en a fait une généralité.
De même, il précise qu'il trouve systemd « pénible », et tu généralises sans fondement.
L'adoption de systemd n'est pas le résultat d'un consensus de la communauté des utilisateurs de Linux. Les paragraphes qui suivent devrait te convaincre.
Premièrement, il faut reconnaître que systemd est plus facile à utiliser que SysVInit pour les mainteneurs d'une distribution. Et c'est pourquoi il a été adopté, car ces sont précisément les mainteneurs qui ont le dernier mot sur les programmes par défaut d'une distribution.
Ce ne sont pas les utilisateurs (autant sysadmin, développeurs ou personne lambda) qui ont choisi systemd. Et il ce trouve que systemd est moins bon que SysVInit du point de vue utilisateur, comme le montre ce journal et de nombreux autres avant, ici ou ailleurs sur Internet.
Il faut aussi reconnaître que systemd à été poussé de force dans RedHat et Fedora, tout simplement car RedHat contrôle ces deux distributions. Cette migration a forcé certain programmes à être fortement dépendant de systemd, notamment car systemd est conçut comme un monolithe. Si tu dépends d'une fonctionnalités quelconque de systemd, alors tu dépends la totalité de systemd.
Rappelons aussi que systemd contient en autres udev, un système de logs, un gestionnaire de session, et gère une partie de dbus. Ainsi les programmes qui ont besoins de telles fonctionnalités doivent inclure du code pour pouvoir fonctionner sur un nombre croissant de distributions. Et comme maintenir plusieurs version d'un même code est difficile, certain programmes sont devenu simplement dépendant de systemd.
Un peu à la manière de pulseaudio qui ce place entre tout autre serveur son et le noyau, systemd ce place entre tout programmes utilisateurs et le noyau. C'est la raison majeure de l'adoption massive de systemd. Et c'est pourquoi le terme « forcé » est tout à fait approprié.
C'est encore une fois un cas typique qui montre qu'une adoption massive n'est en générale pas corrélé à la qualité technique.
Wayland n'est pas aussi mature que systemd. Le contexte n'est pas le même, les programmes ont des finalités bien différentes. Bref, c'est comparer l'incomparable, cet exemple n'est pas convaincant.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par needs . Évalué à 7.
Les utilisateurs n'ont pas tous les compétences, le temps, la motivation de maintenir une distribution (qui plus est basée sur Debian). Encore une fois, systemd est une avancé par rapport à SysVInit du point de vu des mainteneurs. C'est une régression du point de vue des développeurs et utilisateurs lambda. Devuan n'est d'ailleurs pas une alternative à systemd, c'est un fork de Debian sans systemd.
Systemd n'a pas été développé par Redhat en premier lieu, comme l'explique Lennart¹, il s'agit d'un projet personnel. Seulement puisque Lennart est un employé de Redhat (Et Kay Sievert de Novell) il a été plus facile d'intégrer systemd à Fedora, il en parle même dans le lien donné plus haut. Donc ce n'est pas fallacieux.
Il ce trouve que si, car pour le moment systemd est le seul programme qui implémente toute ces interfaces, plutôt complexes. Il faut bien voir qu'avant ces interfaces étaient toutes implémentées par des programmes plus ou moins indépendant. Petit à petit ces programmes ont été intégrés à systemd. Elle vient de là la dépendance à systemd. Il faut aussi voir que c'est bien l'équipe de systemd (ou des personnes des mêmes employeurs) qui définit à la fois le standard² et l'implémentation de référence.
systemd est un deuxième élément critique du système, le premier étant le noyau. Il ce place intentionnellement entre tout programmes utilisateur et le noyau, forçant son adoption ainsi que rendant plus difficile la mise en place d'alternatives. Est-ce plus clair ?
C'est vague et s'applique globalement à tous les programmes informatique. Non, ce n'est définitivement pas convaincant. De plus, plus de « disque, ram, processeur, etc… » n'est pas une raison pour faire des mauvais programmes et augmenter la complexité du système.
L'age n'est pas un argument, et non, une décennie ce n'est pas une éternité, il ne faut pas exagérer.
¹: Quand bien même il précise que systemd dans ses premiers jours à reçut une collaboration de Key Sievert de Novell, il en vient assez vite à parler d'inclure systemd dans Fedora. Il ne cache pas ses objectifs, qui sont très certainement aussi ceux de son employeur.
²: DBus est contrôlé par RedHat, udev a été développé et maintenu en partie par Kay Sievert…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par GnunuX (site web personnel) . Évalué à 7.
En tant qu'intégrateur et sysadmin, je trouve particulièrement pratique systemd (contrairement à upstart par exemple). Il est facile de retrouver pourquoi un service n'a pas démarré, de savoir quelle service démarre anormalement lentement, de modifier les options de démarrage tout en conservant le fichier d'init de la distribution, ….
Tu déformes le journal en disant que "systemd est moins bon que SySVInit", il dit juste qu'une option par défaut ne lui convient pas (la belle affaire).
Tu peux donner des sources ? Quelles "programmes" ne fonctionnent plus en dehors de systemd ? En quoi c'est le problème de systemd ?
En quoi c'est le problème de systemd ? Upstart a un système pour rendre compatible avec ce que propose systemd.
[^] # Re: Bug ferme chez tmux
Posté par needs . Évalué à 7. Dernière modification le 05 juin 2016 à 15:23.
Tu as mal lut mon propos, ou j'ai mal compris le tient. Je concède que systemd est meilleur que SysVInit pour les mainteneurs d'une distribution. De part les retours que tu peux lire ici même et ailleurs sur internet, systemd est à la fois apprécié et décrié par les sysadmin. De même, systemd est source de nombreux problèmes pour les développeurs et utilisateurs lambda. Il existe des alternatives tout à fait valable à SysVInit, comme minit ou runit.
C'est le problème de systemd car avant systemd il n'y avait pas à « être compatible avec systemd », et après systemd il faut « être compatible avec systemd ». Ou dit autrement, systemd casse un système qui était stable en redéfinissant le rapport entre les programmes utilisateurs et un système d'init, de force.
GNOME, KDE, tout les programmes qui utilisent udev, avahi et probablement d'autres. Sans compter les multiples bugs (comme pour tmux) qui forcent les développeurs a intégrer un « switch systemd » dans leur code, histoire de bien marquer au fer rouge la communauté.
[^] # Re: Bug ferme chez tmux
Posté par Zenitram (site web personnel) . Évalué à -5.
euh… non, rien, si tu y crois ça va être difficile de te montrer les faits tellement évidents et une des raisons pour laquelle systemd est demandé.
Mouais, j'attends toujours les forks avec des gens dessus, ça fait un moment que ça aurait dû arriver si les gens qui décrient systemd étaient objectifs.
ce post fait un très bon résumé sur la réalité des anti-systemd.
Je me permet d'en recopier un extrait :
On m'avais dit qu'une fois que Centos 7 arriverait, les gens partiraient en masse (donc en juillet 2014 ). Puis on a dit "tu verras quand Debian sortira" ( avril 2015 ). Et ensuite "quand ça toucheras Ubuntu" (octobre 2015). Puis "nan mais je voulais dire Ubuntu stable" (avril 2016).[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 1.
setsid() fait parti de POSIX mais es tu vraiment sur que ne pas l'utiliser rend un programme non POSIX? C'est pas une interface système POSIX?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par Zenitram (site web personnel) . Évalué à -10.
On en reparle dans allez disons 3 ans pour te laisser le temps… J'ouvre les paris en disant que comme 99% des gens qui hurlent contre le changement "c'était mieux avant même si j'oublie qu'avant c'était pas si bien que ça" et disent "demain je change", tu diras dans 3 ans "si si promis je l'ai pas fait hier mais vraiment mon prochain, promis cette fois, système ne sera pas basé sur linux… ".
Dur la vie. Tu as oublié de penser que personne ne te force à changer de version de ton OS. Garder les mêmes API/comportements est facile, tu ne changes pas de version de l'OS.
(faudrait savoir : si tu changes de version c'est que tu veux du changement mais en même temps tu ne veux pas de changement, tu es bipolaire?)
bref, "ma bonne dame, c'était mieux avant, c'est fou ces jeunes qui font pas comme nous, nous on savait mieux qu'eux".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10. Dernière modification le 05 juin 2016 à 00:23.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par Zenitram (site web personnel) . Évalué à -10.
tu ne souhaites pas me dire dans 3 ans jute si tu as fais ce que tu as dit que tu allais faire? OK, je note, donc c'est juste pour râler.
Désolé, mais dire de changer d'OS pour un truc de ce type, comme si c'était mieux ailleurs, c'est très lourd.
Pas bien difficile de se mette d'accord avec d'autres dont la machine plante si le problème n'est pas chaise-clavier pour avoir un OS à jour de sécurité sans rien modifier.
Sinon, si un MAJ de sécurité casse l'API, je me demande comment tu réagiras.
Donc :
je déteste la facilité avec laquelle tu dis que tu vas quitter Linux pour des raisons ridicules.
je déteste la facilité avec laquelle tu dis que tu vas quitter Linux mais dont on sent que tu ne le feras pas.
Promis, tu arrêtes ce que je déteste, j'arrête ce que tu détestes (ça n'aura plus de raison d'être).
Bref, je te mets juste en face de tes contradictions et te défies juste de faire ce que tu dis que tu vas faire. Je la fais facile? Désolé mais ce n'est pas moi qui crache sur Linux pour des raisons ridicules.
"Demain, je" est d'un classique… Pour ne pas le faire. Je te fais juste remarquer la chose.
[^] # Re: Bug ferme chez tmux
Posté par benja . Évalué à 8.
HS: tu as l'air de prêter une signification erronée à ce terme. Pour ton info, cela désigne le diagnostique que l'on donne à un malade/patient dont l'état psychologique souffre alternativement d'épisodes de grave dépression et d'hypermanie.
[^] # Re: Bug ferme chez tmux
Posté par Zenitram (site web personnel) . Évalué à -10.
J'ai trop regardé Homeland dernièrement, mauvais mot qui est arrivé.
schizophrène plutôt.
[^] # Re: Bug ferme chez tmux
Posté par totof2000 . Évalué à -3.
Tu peux pas. En fait si tu n'aimes pas systemd, c'est parce que tu n'aimes pas le changement, comme tes cobolistes.
[^] # Re: Bug ferme chez tmux
Posté par needs . Évalué à 5.
Je te seconde sur ce point avec un petit retour d’expérience personnelle. Depuis au moins 6 mois, lorsque j’éteins mon ordi (ArchLinux) il y a environ :
J'en ai globalement rien à faire car mon ordi ayant plus de batterie, j'ai juste à débrancher le câble d'alimentation pour l'éteindre brusquement. Pour des raisons qui me sont obscure, mon ordi n'a jamais été très compatible avec les programmes de Lennart, à savoir pulseaudio, NetworkManager, journalctl et systemd.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6. Dernière modification le 05 juin 2016 à 00:48.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 7.
1m30 ? petit joueur. Sur des tests au boulot, il attendait un certain service plus de 10 min. Et bien entendu plus la main pour killer ledit process car il a coupé ssh avant et t'as pas de terminal pour pouvoir le faire une fois le process d'extinction lancé.
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à -2.
C'est vrai, c'était tellement mieux avant, quand l'init était incapable de tuer le service et restait bloquer comme un con…
[^] # Re: Bug ferme chez tmux
Posté par WhiteCat . Évalué à 6.
C'est marrant moi c'est justement une des raisons pour lesquelles je n'aime pas Debian. Je ne vois pas en quoi le fait d'installer un service signifie l'activation de ce service (qui n'aura même pas été configuré !) derrière… C’est dangereux. Moi j'active un service seulement une fois que je l'ai configuré et que je suis prêt à le mettre en route.
Les Debianeux (-nistes?) anti-systemd sont certainement des ayatollah de la méthode KISS, mais pourtant leur gestionnaire de paquets ne l'ai pas. Pourquoi un gestionnaire de paquets active et lance des services ? C'est un gestionnaire de services alors aussi ?
[^] # Re: Bug ferme chez tmux
Posté par GG (site web personnel) . Évalué à -2.
C'est un problème si powerdns-recursor écoute sur l'interface locale? Houla la… dangereux…
Si c'est ton cas, tu filtres le port 53 avant.
Il arrive bien plus souvent d'oublier d'activer le service au boot que de ne pas oublier.
Enfin, selon la configuration des logiciels, il faut parfois faire un tour dans /etc/default/le_logiciel, c'est le cas par exemple pour Polipo.
Il est probable que chez Redhat, habitués à devoir utiliser chkconfig à chaque fois, ils se soient dit que Systemd allait tout résoudre…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Bug ferme chez tmux
Posté par Moonz . Évalué à 7.
Le problème c’est le couplage de « je démarre et active automatiquement les processus installés » et « j’installe toutes les dépendances recommandées ». Démarrer et activer automatiquement un service explicitement installé par l’utilisateur, pourquoi pas. Démarrer et activer automatiquement un service qui vient en dépendance (même pas forcément obligatoire), là on rentre plus dans le domaine du WTF.
Au final tu te retrouves avec plein de machines sur lesquelles smbd est installé, activé, lancé et non utilisé, sans que l’utilisateur soit nécessairement au courant. Et samba a régulièrement des failles de sécurité. Alors tant que Debian c’est 0.1% des utilisateurs ça va, mais pour moi dans l’idée ça reste une recette pour avoir un track record niveau sécurité digne de XP.
[^] # Re: Bug ferme chez tmux
Posté par barmic . Évalué à 4.
J'adore cette façon de décrire quelque chose qui fonctionne et qui est très utilisé comme quelque chose qui est immonde, ne marche pas, etc. Debian et ses dérivées ont suffisamment d'utilisateurs pour que ce genre de choses soient relativement éprouvée. Tu ne crois pas ?
Au dessus on parle du coté non-KISS d'apt. Ce dernier, comme tous les autres que je connais, utilise des scripts shell pour faire l'installation et c'est le paquet qui lance (ou non le service). Ce qui est fait avec apt, peut très bien être reproduit avec yum ou yaourt, c'est une manière de créer les paquets et pas lié du tout à apt en lui même.
Si la sécurité est un poil importante pour toi, tu as un firewall activé sur ta machine et lancer des services qui écoutent le réseau ne te posera aucun problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bug ferme chez tmux
Posté par Moonz . Évalué à 3.
Tu confonds « ne marche pas » et « pose des problèmes de sécurité ». Bien sûr que ça marchouille (et encore, ya des situations où ça foire. J’aime bien par exemple la mise à jour de la libc sous debian qui tue les nginx de mes containers dockers, juste parce que le restart du service fait un
killall nginx…), sinon ça longtemps que ce serait abandonné.J’ai quelque chose qui me convient encore mieux perso :
exit 101danspolicy-rc.d.Je ne dis pas qu’il n’y a pas de solution ; je dis que le défaut est pourri d’un point de vue sécurité.
[^] # Re: Bug ferme chez tmux
Posté par WhiteCat . Évalué à 3.
J'arrive pas à comprendre le raisonnement, ou bien je n'ai pas compris ce que tu as voulu dire. Tu préconises de bloquer des ports pour des services qui écoutent le réseau ? Quel intérêt de faire fonctionner ces services alors ?
[^] # Re: Bug ferme chez tmux
Posté par barmic . Évalué à 3.
Non je préconise de bloquer tous les ports dont tu n'a pas le besoin. Par la suite quand tu installe un serveur, tu as 3 étapes :
L'avantage c'est que tu fais de la sécurité (pour de vrai pas « tout le monde est gentil sur mon système donc ça doit être sécurisé ») et tu te protège aussi d'un quelconque script qui chercherait à écouter le réseau inopinément.
La sécurité ça consiste à bloquer les droits par défaut et à donner les droits le plus ponctuellement possible.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
C'est un raisonnement tout à fait raisonnable mais il a eu un effet secondaire suite a son application généralisé par les DSI : la bascule de plein (presque tous) de service sur du https… Cette règle simple a malheureusement aussi des effets secondaires négatifs ;-)
[^] # Re: Bug ferme chez tmux
Posté par barmic . Évalué à 4.
Quel est le rapport avec la choucroute ?
Le problème dont tu parle est une question de capacité des DSI à adresser les besoins de leurs utilisateurs, rien avoir avec le fait que Debian lance ou pas les services.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Je reprends ta phrase sur la sécurité et je la place juste sur le concept de socket réseau ;-) Donc attention aux phrases trop générales… Quand aux DSI, on peut être pour ou contre mais cela ne changera rien. Leur comportement est un fait sociétal !
Ceci dis, cela ne me dérange pas que Debian lance ses services par défaut, au contraire. Une machine fraîchement installé n'est pas ouverte sur le net (DMZ) avant configuration… Un service, cela se configure via cfegnine, puppet… et si un service ne sers à rien, il n'est pas installé. Donc sur mes serveurs, un service installé est un service qui tourne. Je n'aime pas avoir du code dormant sur mes serveurs, je trouve cela plutôt dangereux !
Bref, un service mis sur off devrait être (sauf HA…) un service purgé du système de fichier ;-)
[^] # Re: Bug ferme chez tmux
Posté par GG (site web personnel) . Évalué à 1.
Ça c'est l'option par défaut de aptitude, spéciale pour débutant.
J'espère que tu ne laisses pas ça sur tes machines…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Bug ferme chez tmux
Posté par Moonz . Évalué à 6.
apt-get aussi.
Et pourquoi pas ? Je ne suis pas radin sur l’espace disque. Le comportement « ramène les dépendances recommandées » ne me dérange pas. C’est le comportement « lançons donc automatiquement des services que l’utilisateur n’a pas explicitement demandé » qui me dérange.
[^] # Re: Bug ferme chez tmux
Posté par WhiteCat . Évalué à 4.
Pour powerdns-recursor j'en sais rien, je n'ai jamais utilisé, mais si j'installe un serveur httpd ou pire dhcpd, j'ai vraiment pas envie qu'il me le lance tout seul.
Je ne vois pas ce que systemd vient faire là-dedans.
Avec RHEL6 : yum install httpd ; chkconfig httpd on
Avec RHEL7 : yum install httpd ; systemctl enable httpd
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 9.
Oui, tu introduis des workflow différents suivant les machines que tu utilise. En plus ce n'est absolument pas intuitif, et il faut avoir les autorisations de le faire.
Bref, c'est une grosse régression par rapport à lancer simplement ton programme dans un shell, comme on fait depuis plus de 30 ans.
La prochaine solution ça sera quoi "le lancer par une connexion ssh c'est si problématique que ça ?"
C'est quand même génial. Systemd introduit un workaround pour pas avoir à gérer un faux problème.
Conclusion, une tonnes de personnes sur linuxfr propose un workaround pour travailler avec workaround de systemd.
Et ensuite ils viennent demander si c'est "si compliqué de faire comme ça".
Et les mêmes t'expliquent que systemd "fluidifie, harmonise et simplifie" :D
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à -1.
Si l'on m'avais dit que tu taperais sur systemd un jour j'aurai rigole mais non non je ne reve pas.
[^] # Re: Bug ferme chez tmux
Posté par groumly . Évalué à -1.
Et ouais parce que nohup ou screen, c'est super intuitif?
Encore heureux.
Serais tu en train d'insinuer que la sécurité, c'est gênant, et laisser tout le monde faire n'importe quoi, c'est mieux? Clap clap clap.
Avis purement subjectif. Je vois pas ca comme une régression, quoique je puisse comprendre l'argument.
Grosse régression, clairement pas, c'est réglé avec une entrée dans un fichier de config.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Bug ferme chez tmux
Posté par karchnu . Évalué à 4.
Et en quoi c'est un problème de sécurité le fait de laisser un processus utilisateur tourner ? S'il n'a pas le droit de faire quelque-chose, c'est déjà géré. Empêcher de faire tourner un programme qui n'a pas de privilèges ce n'est pas de la sécurité, c'est juste pénible pour l'utilisateur.
[^] # Re: Bug ferme chez tmux
Posté par groumly . Évalué à 4.
Je repondais a son argument qui disait en substance "if faut avoir les permissions pour lancer un background process avec systemd, et les permissions c'est chiant, il faut les avoir".
Une machine partagée dans une fac par exemple n'a pas forcement envie de voir tourner un client bitcoin en tache de fond. C'est a l'admin du réseau de decider qui a le droit de faire quoi. Et si l'admin, c'est toi, ben c'est pas la mer a boire que d'activer ca.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Bug ferme chez tmux
Posté par karchnu . Évalué à 5. Dernière modification le 06 juin 2016 à 16:14.
Donc ce n'est pas un problème de sécurité.
Ton exemple n'est pas bon non plus. Un utilisateur des machines de la fac peut vouloir lancer un processus de manière légitime (quelque-chose qui s'exécutera pendant un petit moment). Tu prends l'exemple du minage bitcoin, je prend l'exemple d'un étudiant qui veut juste faire son travail et lancer une compilation ou un ensemble de scripts. Sur cet exemple (bien plus répandu que du minage de bitcoin) c'est simple actuellement, avec le nouveau comportement c'est pénible. Donc pour la fac non, ça ne fonctionne pas. Je sais que l'exemple a été dit plusieurs fois pour montrer à quel point on en aurait besoin, mais c'est faux et non viable.
[^] # Re: Bug ferme chez tmux
Posté par WhiteCat . Évalué à 4.
Potentiellement si.
Lennart Poettering explique déjà très bien ça : http://lwn.net/Articles/689509/
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 4.
AHAHA mdr.
Non mais sérieusement, tu as lu le cas d'usage de Lennart ?
Pour ceux qui veulent pas lire le lien, je vais résumer :
"imaginez un employée d'une banque (réseau sécurisé pour le sieur) qui lance un spam bot contre son grès (il aurait visité un site "méchant" et paf un exploit dans le browser et paf spambot… [Sur un réseau bureautique "sécurisé" avec controle des ports et proxy…sisi puisque Lennart le dit ].
Ou alors un employé qui a quitté l'entreprise et a laissé un programme tourner. Ben avec systemd le spam bot serait mort dès que l'employé aurait fermé sa session et l'entreprise serait sauvée.".
Je ne sais pas si je dois expliquer en quoi c'est complètement éloigné de la vraie vie, ou juste continuer à rire.
[^] # Re: Bug ferme chez tmux
Posté par WhiteCat . Évalué à 1.
Il est certes tiré par les cheveux, mais la conclusion de LP n'en reste pas moins logique :
"when the user is logged out, he's really logged out. And it's completely OK if certain users get excludeded from that, but if so, then the admin needs to sign off on that, and thus a privilege check needs to be enforced."
Effectivement je trouve normal que par défaut sur un système, quand on se déconnecte, plus aucun de mes programmes tournent. C'est juste propre et plus sécurisant pour moi et l'admin.
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à 2.
Dans la vraie vie linux c'est sur des serveurs et des systemes HPC donc ce comportement est juste … debile point barre et pourquoi a t'il etait mis en place? Parceque le bebe de monsieur systemd (pulseaudio) est une bouse ambulante qui laisse des process alors que tu te delogues et la encore une fois c'est tellement loin des HPC que ce cas de figure (reel lui) on s'en tape mais pas le fait que tu ne puisses plus rien lance sans passer par des operations complexes.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Je ne sais pas ce que tu fais comme HPC mais tous les systèmes que je connais, les scheduleurs dégomment tout lors de la fin du script de soumission (équivalent session) ou lorsqu'on arrive à l'échéance du temps du walltime. Si ton système HPC ne fonctionne pas ainsi, pour moi, ce n'est pas un système HPC car je ne vois pas comment le scheduleur pourrait dans ces conditions allouer correctement les ressources et faire des estimations de temps de passage.
Toutes les machines HPC de PRACE, GENCI ou des centres régionaux marchent sur ce principe.
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à 1.
Nous avons des HPC (petits) qui permettent de tester AVANT de balancer sur les gros bousins et nos utilisateurs sont des … nullos qui viennent du monde windows et leur faire utilser la ligne de commande c'est … rigolo on va dire gentiment. Nous avons donc des machines dedies au dev qui ne passent pas forcement par des systemes de queues, nous avons aussi des systemes HPC avec visualisation deportes utilisant virtualgl et la aussi on chunte le systeme de queues. Et tout plein de petit cas de ce style qui vont etre sacrement amusant a gerer et apres on va nous dire que windows c'est genial avec le rdp (legerement equivalent de screen pour le graphique non?). Enfin je vois plein de merde arriver mais bon je n'ai pas de controle dessus donc on fera avec mais ca va etre bien bien chiant je sens.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 5. Dernière modification le 06 juin 2016 à 21:49.
Il y a une ligne à changer pour avoir l'ancien comportement.
Perso, j'utilise mosh pour la connexion distante qui résiste au changement d'IP et de réseau ! Tu lances ton xpra dans une session mosh et tu as au final un truc beau ;-)
Bref, je ne me fais pas trop d'inquiétude, pleins de gens ont ce besoin sur ce genre de serveur (que je ne qualifie pas de HPC) et il y a donc une configuration qui marchera. Peu de gens actuellement font tourner VirtualGL sur leur poste perso (sans l'aide d'un sysadmin) donc adapter le système pour lui ne me semble pas inaccessible.
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à 2.
Ligne que j'ai naturellement change :D
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à 7.
Que ce soit 1 ou 30 je suis assez d'accord avec Linus Torvalds: "On ne casse pas le putain d'espace utilisateur" et ce qui est fait par systemd c'est ca. Et on peut dire ce que l'on veut mais je suis a peu pres certain que l'enorme majorite des utilisateurs de linux vont detester ce comportement… car ils vont devoir changer des ANNEES d'habitude (ou tripatouiller dans les fichiers de conf).
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 1.
"l'enorme majorite des utilisateurs de linux" n'utilise ni trap ni nohup…
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à 6.
Ah oui? Puti mon echantillon de quelques centaines d'utilsateurs linux doit etre totalement biaise car 100% de l'echantillon utilise nohup. MERDE MERDE MERDE uilm va vraiment falloir que je rencontre des utilisateurs "normaux" de linux comme gnumdk qui n'utilise jamais nohup.
[^] # Re: Bug ferme chez tmux
Posté par xcomcmdr . Évalué à 2. Dernière modification le 07 juin 2016 à 08:28.
Ca ne casse pas l'espace utilisateur, vu que quand Linus dit ça il parle de changement cassant d'ABI, pas l'application d'un comportement tout à fait logique.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à 6.
Mais oui c'est vrai screen et tmux on donc le comportement attendu de la part de ces programmes! Merci d'avoir pointer que me trompais (et les devs de ces logiciels) sur leur but.
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 7.
En plus, Dans la vraie vie, les postes bureautique d'entreprises (qui sont la plupart du temps sous windows) sont des postes nominatifs et les gens ne se déloguent que très rarement. (ce qui est d'ailleurs une gageure pour la proximité ;)).
Poste que tu rends lorsque tu quittes la boite.
La plupart des cas où tu as le cas de "vrai" multi-utilisateur, c'est quand tu es sur des pcs partagé (client X léger, poste internet, poste métier spécifiques etc…).
Ensuite oui il doit certainement avoir quelques entreprises qui ont tous leurs postes qui sont en libre service, et aucune place attitré (de façon hiérarchique ou simplement par convention).
Mais même là, tu vas utiliser la capacité multi utilisateur de linux pour avoir plusieurs sessions utilisateur en même temps, et tu ne vas sans doute pas te délogguer pour autant.
Bref, encore une fois, La capacité de pouvoir killer les process d'un utilisateur qui se déloggue est intéressante, mais en inversant la règle du défaut tout simplement.
Et si une banque estime que c'est plus mieux pour la sécurité, ben ils l'activeront tout simplement.
Vu les politiques de mots de passes que ces **** activent, ils sont tout à fait capables d'activer cela si ils estiment que c'est intéressant pour eux.
Dans les autres cas d'utilisation de linux, c'est plutôt contre productif amha.
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 2.
Jamais vu ce comportement… T'es sur que tu ne confonds pas avec le pulseaudio lancé par GDM? (ça c'est débile par contre et je n'ai toujours pas compris pourquoi GNOME laisse comme ça)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
A partir du moment ou on a commencé à écrire les bureaux en variables globales, à ne pas vouloir relancer le bureau lors de reconfiguration mais où on voulait que tout se propage instantanément (dbus, gconfd…), on a commencé à faire des services au niveau session plutôt que d'utiliser des variables d'environnements pour transmettre des paramètres pères fils…
Cette évolution ayant été suivis pas presque tous les bureaux, il faut bien à la fin nettoyer la "merde" qui traîne un peu partout ;-)
[^] # Re: Bug ferme chez tmux
Posté par totof2000 . Évalué à 3.
Et c'est là qu'on se retrouve à devoir faire comme sous windows : laisser une session ouverte sous l e nom de l'utilisateur en question pour faire tourner un programme.
Certains me diront qu'on peut faire autrement, mais en pratique, ça se voit encore beaucoup.
[^] # Re: Bug ferme chez tmux
Posté par xcomcmdr . Évalué à 1.
En général, on créé un service (= un daemon sous Linux).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Bug ferme chez tmux
Posté par totof2000 . Évalué à 0.
mouais, aparamment c pas toujours possible. je vois encore des cas ou il faut laisser la session ouverte.
[^] # Re: Bug ferme chez tmux
Posté par Sufflope (site web personnel) . Évalué à 0.
On doit pas connaître les mêmes banques puisque pour au moins une, le "réseau sécurisé" c'est le réseau où c'est marqué que t'as pas le droit d'y brancher un câble ethernet si t'as pas le droit d'accès au réseau sécurisé. La sécurité c'est que comme les gens ont pas le droit ils le feront pas.
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 6.
Je confirme, j'avais lancé une simulation pour un TP de ma fac, et sur mon pc perso c'était pas assez puissant.
Ca a duré une semaine sur les 7 machines dispo de la fac -chacune 4 fois plus puissantes que mon pc- :)
Ben le sysadmin de la fac l'a remarqué et me l'a gentiment laissé, parce que j'avais bien mis la bonne priorité qui permettait à tout le monde de travaillait sans gêner :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 3.
Là ou je bossais avant, tu l'aurais eu dans le *** parce que ISO 14001 oblige, on coupait les PC le soir ;)
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 2.
ça tombe bien, c'était pas des pc:P
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 8.
Confère mon interrogation sur la définition dudit problème, plus bas
Prendre ses petites mains et allez ouvrir un bug-report, voir même de coder pour réparer ce problème qui te gênes dans les logiciel que tu utilises?
Ah j'aime les stats sur linuxfr. On a une solution qui résoud un "problème*" (mais non quantifié par personne. Pourquoi 99% ? Pour moi c'est <0.01%. J'ai plus de sous process utilisé par systemd que par mon environnement graphique lorsque je le quitte…)
On a des cas avérés que cette solution ne convient pour certaines utilisations (et ça casse bien plus que "2 programmes", ça casse tout programme lancé par l'utilisateur dans une session systemd, et qui est amené à vivre après cette session.)
Et on vient nous expliquer, à grand renfort de chiffres complètement farfelus que c'est "la solution qu'il nous faut".
Pour revenir sur le "problèmes". Qui dit que c'est un problème ?
C'était peut être voulu de ne pas lancer à chaque début de session tel ou tel programme ? (je ne connais pas l'archi de kde)
Lorsqu'on utilise nohup, c'est pour des programmes n'ayant pas prévu de se détacher et de fonctionner un peu comme des daemons, et qui ne capturent pas le signal HUP.
Si kded et consors ne meurent pas, peut être qu'ils ont été prévu de fonctionner comme ça et que c'était voulu "by design" ?
Tu parles d'ailleurs des workstations, c'est rare qu'elles soient utilisés par 10 000 personnes différentes. Donc le plus souvent c'est pas vraiment un problème si les logiciels ont été prévus pour et sont bien codés.
Pour les stations libres services (style école, facs, …) là je peux croire qu'ils veulent limiter l'impact, mais pourquoi prendre kde ou gnome dans ce cas ? :P
Et ça reste un mode de fonctionnement moins standard quand même. Donc utiliser ce mode de fonctionnement pour expliquer que "la solution qu'il nous faut" …
[^] # Re: Bug ferme chez tmux
Posté par GnunuX (site web personnel) . Évalué à 1.
Le problème c'est qu'aujourd'hui il n'y a pas vraiment de solution au problème. Il n'y a pas de notion de "logout". Comment une application est censé savoir qu'une personne fait un "logout" ? En tout cas, moi je ne sais pas fait.
Résultat des applications restent démarrées (principalement des agents, comme SSH, …).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à 7.
Toi tu ne te sers pas de KDE et ca se voit car ca fait bien longtemps que KDE n'a plus ce genre de probleme contrairement a Gnome mais surtout a Pulseaudio.
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 0.
Non, ce n'est pas un discours marketing, si tu n'es pas capable d'aller lire la doc pour comprendre que systemd est aussi un gestionnaire de session qui remplacera les daubes genre ksmserver et gnome-session, c'est que tu n'as rien compris…
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 3.
Mais bien sur: c'est sur que
Sont des arguments techniques d'une profondeur rare.
Et je vois pas pourquoi tu parles de ksmserver ou gnome-session, sachant qu'on en a jamais parlé, et que ce que tu cites ne s'appliquait pas dessus.
Une chose est sur, c'est que systemd ne permet pas à ses défenseurs de lire correctement les posts auxquels ils répondent (et pourtant j'avais fait une belle citation itou itou).
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 2.
Je t'en parle parce que les devs KDE et GNOME veulent remplacer ksmserver et gnome-session par systemd.
[^] # Re: Bug ferme chez tmux
Posté par barmic . Évalué à 1.
C'est pas possible systemd n'intéresse que la packageurs aux dépends des utilisateurs et des développeurs. (https://linuxfr.org/users/err404/journaux/attention-avec-systemd-tmux-ne-survit-plus-apres-la-fermeture-de-la-session#comment-1660159)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bug ferme chez tmux
Posté par Albert_ . Évalué à -3.
Un superbe discours marketing a un gars deja convaincu par systemd… c'est beau a lire. :D
[^] # Re: Bug ferme chez tmux
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 10.
Hello,
C'est le genre de changement qui ne m'étonne pas sur une branche non-stable de Debian. Vu un commentaire plus bas, le changement est bien annoncé.
Sinon, Debian n'impose pas systemd, le paquet d'init propose encore l'ancien système sur Jessie. Il ne me semble pas avoir entendu parler de l'abandon de SysV pour Stretch, donc ça devrait aussi être disponible.
C'est quand même un bon troll: proposer comme solution de passer d'une distribution avec binaires à une distribution à compilation locale juste parce qu'une branche instable est instable dans sa configuration par défaut…
Alors qu'il suffit de changer 1 ligne dans /etc/systemd/logind.conf ou même de bien choisir de choisir son logiciel d'init ou encore de rester sur une version stable…
[^] # Re: Bug fermé chez tmux
Posté par err404 (site web personnel) . Évalué à 1.
changer d'init?
alors tu va m'expliquer comment je peux me passer de dbus sur mon ordinateur de bureau.
parce que j'utilise Mate Desktop, et Mate dépend de dbus qui dépend de systemd…
sur mes serveur je n'utilise pas systemd parce que j'ai d'autres system d'init, mais sur mes serveurs je n'utilise pas d'environnement de bureau non plus…
[^] # Re: Bug fermé chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
J'ai des machines sous Jessie qui sont restés sous sysvinit… Cela ne pose aucun soucis !
apt-get install sysvinit-core sysvinit-utils systemd-shim systemd-sysv-
[^] # Re: Bug fermé chez tmux
Posté par benoar . Évalué à 5.
Des serveurs, je suppose. Sur un desktop, c'est inutilisable : pas de mise en veille, pas d'auto-montage, etc. Non, Debian avec SysV pour un desktop n'est plus utilisable.
[^] # Re: Bug fermé chez tmux
Posté par eingousef . Évalué à 5.
C'est difficilement utilisable, mais c'est pas totalement inutilisable.
Je vais parler juste de mon cas : j'utilise Debian testing avec openrc (qui semble s'appeler maintenant file-rc dans Debian), mais je ne pense pas que ça change grand chose par rapport à sysvinit.
Utiliser un système d'init classique sous Debian, désormais, ça demande surtout de s'orienter vers des programmes minimalistes, simples et stupides. Si on est habitué à un simple petit openbox + tint2 ça ne dépayse pas beaucoup, mais si on utilise des gros environnement tout en un (xfce, kde, gnome), ça demande de changer beaucoup d'habitudes. Pour la suspension / hibernation je fais ça à la main (j'ai des scripts à base de pm-machin mappés sur les touches appropriées de mon clavier), pour le montage de disques, je fais ça aussi à la main, avec pmount. Je ne ferai pas de publicité particulière pour pmount, il est bof bof, mais bon il fait le job. Évidemment on ne peut pas monter les volumes en cliquant directement dessus depuis pcmanfm (on a une belle fenêtre d'erreur) mais il y a un fork, spacefm, qui apparemment utilise udevil pour monter/démonter les volumes, et ça marche !
*splash!*
[^] # Re: Bug fermé chez tmux
Posté par benoar . Évalué à 2.
Oui, OK, je concède, mais du coup ça marchera uniquement pour trois barbus. J'ai du mal à appeler ça « utilisable » au sens général.
[^] # Re: Bug fermé chez tmux
Posté par gnumdk (site web personnel) . Évalué à 9.
Les non barbus utilisent systemd et ne savent pas ce que c'est…
[^] # Re: Bug fermé chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Pas tout vérifier mais sur un poste que je vois à distance, udev tourne, dbus aussi et je ne vois pas pourquoi ce qui marchait avant Jessie ne marcherait plus… Il me semblait que gnome ne dépendait de systemd que par un truc con facile a refaire.
[^] # Re: Bug fermé chez tmux
Posté par benoar . Évalué à 7.
Ahaha, elle est bonne : c'est justement l'état d'esprit des dev de systemd, de ne rien avoir à foutre de la rétro-compatibilité. Et c'est « assumé » ! Et donc oui, tu ne vois pas pourquoi, mais en pratique c'est le cas : plein de choses sont cassées si tu n'as pas systemd. J'ai vécu quelques temps horribles sans, et puis j'ai laissé tomber, accepté systemd et je me tape tous les comportements « étranges » dès qu'un nouveau truc est cassé. La résignation, c'est la vie.
Ah bah non, informe toi : c'est aussi bien pour les services liés à la gestion de session que de l'énergie, les permissions des périphériques, la configuration réseau, etc. Ça n'est pas « facile à refaire ». J'avoue ne plus suivre depuis quelques temps, mais j'ai toujours cette épée de Damoclès que tout parte en cacahuète sans que je ne comprennes rien. Par exemple, Debian pour Jessie a stoppé la version de consolekit avant que son moteur de permissions en Javascript n'arrive, mais je crois que pour avoir le dernier systemd il va falloir y passer. Quelle avancée extraordinaire et facilement maîtrisable ! Rien de terrible ne pourrait arriver, non ?
[^] # Re: Bug fermé chez tmux
Posté par totof2000 . Évalué à 6.
Amusant, c'est ce genre de choses qui font que j'ai quitté Windows pour Linux, et que j'ai quitté Linux pendant une période assez longue pour NetBSD puis FreeBSD.
[^] # Re: Bug fermé chez tmux
Posté par modr123 . Évalué à -1. Dernière modification le 04 juin 2016 à 17:56.
et alors ?
[^] # Re: Bug fermé chez tmux
Posté par Parleur . Évalué à 2.
Ça dépend de ta distribution.
[^] # Re: Bug fermé chez tmux
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Non, parce que j'utilise systemd (pour les timers, unit, services, …) et je ne vais donc pas chercher à me passer de celui-ci.
L'idée est que ne pas utiliser systemd est possible (avec les paquets sysvinit-core, systemd-shim et init-system-helpers).
Si MATE ne fonctionne vraiment pas, c'est alors MATE qui te pose problème (D-Bus ne dépend que de libsystemd0, pas de systemd directement).
[^] # Re: Bug ferme chez tmux
Posté par Zenitram (site web personnel) . Évalué à -2.
man daemon
Je vos nul part que cette fonction permet le background même si l'utilisateur se déconnecte.
donc je ne vois pas en quoi systemd "casse" quelque chose, je dirai plutôt qu'un développeur a vu un comportement, s'est pas embêté à regarder la doc et a imaginé que ça serait toujours pareil.
Et en fait, comme c'est mis dans les autres commentaires, ça semble être juste une option de systemd à changer, rien d'horrible juste une politique par défaut (et comme d'autres, je trouve que tuer tous les process qui n'ont pas dit explicitement qu'ils veulent rester quand on se déconnecte et qui n'ont pas été autorisés à le faire, ce n'est pas forcément une mauvaise idée, ce n'est pas "mais les salauds pensent pas comme moi", les deux options ont des avantages et inconvénients).
Sinon pour le journal :
Si c'est pas une tache système (mis en user), pourquoi un utilisateur déconnecté devrait continuer à avoir des process qui bouffent du CPU? il peut rester connecté aussi, ça permet d'ailleurs d'associer un processus à une session utilisateur (et de "tuer" cette session et ces process si ça consomme trop).
Finalement, quelle utilité de se déconnecter?
Ca me semble un faux problème.
[^] # Re: Bug ferme chez tmux
Posté par Tonton Th (Mastodon) . Évalué à 6.
Pour emmener ton laptop avec toi quand tu pars à Terre Blanque ?
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 3.
Parce que genre tu éteins ton laptop?
[^] # Re: Bug ferme chez tmux
Posté par Tonton Th (Mastodon) . Évalué à 7.
Ethernet est limité à 100 mètres, donc oui, forcément, il y a déconnexion.
[^] # Re: Bug ferme chez tmux
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 03 juin 2016 à 10:27.
Laptop et Ethernet dans la même discussion en 2016, ça fait bizarre quand même.
Et j'avoue que je ne vois pas du tout le rapport avec le sujet (ai-je mal lu et le journal parle d'un terminal distant uniquement?)
[^] # Re: Bug ferme chez tmux
Posté par Tonton Th (Mastodon) . Évalué à 10.
Sauf si tu es un peu loin de l'antenne et que celle-ci est partagée, et que tu veux tes 96 Mb/s, tu te branches sur la prise murale. Et le cable n'est pas extensible.
On a un peu dérivé de
tmuxversnohup, mais le souci est en gros le même. Je fais pas mal de synthèse d'images, et j'ai des batchs qui tournent plusieurs heures/jours sur des machines distantes. Donc, je les fais tourner soit dans unscreen, soit en fire-and-forget avecnohup. Et là, l'autre estraïlle de LP me casse un workflow instinctif depuis 20 ans ;{J'attend avec angoisse le moment où je vais avoir à re-déployer des applis du siècle dernier basées sur des technologies aussi canoniques que
xinetd;}[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 4. Dernière modification le 03 juin 2016 à 10:47.
Où tu as lu que cela concerne ta session SSH? C'est pas systemd (pour l'instant en tout cas) qui gère cela.
Testé sous ArchLinux, ça tue screen uniquement sur une session locale, pas via SSH…
[^] # Re: Bug ferme chez tmux
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Il faut utiliser mosh!
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Yep, mosh + tmux (byobu) marche d'enfer et la charge réseau est TRES TRES faible (on attend juste la redirection de port).
[^] # Re: Bug ferme chez tmux
Posté par benja . Évalué à 1. Dernière modification le 03 juin 2016 à 15:12.
+1, Mosh est super pratique… Du coup, au sujet de la question qui nous occupe, il inclue un support spécifique pour systemd ?
(Par contre au niveau de la charge cpu, je trouves mosh un peu décevant… Peut-être parce qu'il est écrit en python ?)
ps: qu'entends tu par redirection de port ?
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Yep, mosh charge un peu trop (tmux surtout il me semble).
Redirection -> pouvoir glisser via mosh un retour graphique xpra par exemple ;-)
[^] # Re: Bug ferme chez tmux
Posté par fearan . Évalué à 10.
man daemon:
The daemon() function is for programs wishing to detach themselves from the controlling terminal and run in the background as system daemons.
effectivement, il n'est pas précisé que ça survit à la déconnexion, mais ça survit à la fermeture du shell ouvrant, et il me sembles que les daemon systèmes survivent bien sans utilisateur connecté.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Bug ferme chez tmux
Posté par Kaane . Évalué à 6.
Ben oui, mais dans systemd, la slice système (ie le/les cgroup(s) attribué au lancement de processus en mode service) n'a pas le même fonctionnement que les slices utilisateurs. Donc si tu lances un processus en tant qu'utilisateur et que pour une raison X ou Y tu veux le conserver bien que tu fermes ta session - tu l'as un peu dans l'os.
En ce qui concerne daemon() c'est un utilitaire "à la sauce" sysV init. En d'autres termes c'est un toolkit qui facilite le double fork et la migration des input/output depuis un pty/tty vers un autre.
a) C'est très compliqué à utiliser en cours de route (ie c'est pas facile de démoniser à la volée un processus qui n'a pas été prévu pour - notamment qui ne va pas migrer sa mémoire, environnement, threads etc. quand il va se prendre un fork dans les dent). daemon() est plutôt destiné à être utilisé au lancement du processus
b) systemd en a rien à faire de daemon(), le process aura été lancé depuis une slice utilisateur, donc il va rester dans son cgroup utilisateur. En d'autres termes, daemon() ou pas, ou moment ou la slice sera nettoyée (par exemple à la fermeture de session) le processus va gicler (c'est d'ailleurs bien là le soucis qui nous préoccupe aujourd'hui)
c) Si on fait avaler à systemd une slice dégénérée (ie une slice utilisateur qui est considérée par systemd comme une slice système - voire une slice mère de la slice système) ca passe. Par contre créer ce type de slice est complexe, non supportée et casse beaucoup de choses (logind par exemple - pour citer le truc le plus impactant). A part en expérimentation pour faire joujou, je déconseille vivement.
[^] # Re: Bug ferme chez tmux
Posté par David Marec . Évalué à 4.
Non, mais le problème est dans la notion même de « déconnexion », il me semble.
J'ai ouvert une session utilisateur sur une machine distance via SSH; j'ai, de fait, ouvert un terminal .
De ce terminal, je lance un tmux/screen/whatever pour effectuer des tâches assez lourdes (compilation, mises à jour).
Je détache ce nouveau terminal du terminal qui l'a lancé.
Je ferme ce terminal. L'utilisateur n'est pas déconnecté.
Sur la machine distante, un FreeBSD, je constate que la session de l'utilisateur est toujours ouverte.
Cela signifie que, sous Linux, fermer le premier terminal termine la session, alors que l'utilisateur a ouvert d'autres terminaux toujours actifs ?
Et que dans ce cas, il faut que je garde ouvert ma connexion SSH et le terminal/shell lancé derrière ?
[^] # Re: Bug ferme chez tmux
Posté par totof2000 . Évalué à 2.
les sessions tmuix/screen ouvertes via ssh ne sont pas concernées, si j'ai bien compris.
Par contre si tu as des traitements batch lancés en local via un terminal, turisque de les perdre lorsque tu fermes ta session X.
Linux ressemble de plus en plus à Windows : c'est moche.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Idée au pif (pas testé)
echo screen | at now +1s
[^] # Re: Bug ferme chez tmux
Posté par groumly . Évalué à 2.
Autre idée au pif: lire les 15 lignes du changelog, et ensuite changer la clé qui va bien dans la config systemd, puis retourner vaquer à ses occupations.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je le sais bien puisque je l'ai aussi proposé ailleurs ;-) L'idée ici est de garder une session en container qui est nettoyé en fin de session et d'envoyer simplement un processus hors de ce container de session, via at par exemple.
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . Évalué à 3.
la simplification du process et de l'administration dans toute sa splendeur :'( (pour reprendre les avantages de systemd pronés par whitecat ;) )
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par err404 (site web personnel) . Évalué à 3.
pour avoir testé un ssh en localhost, ça ne fonctionne pas, le tmux est quand même killé à la fermeture de la session.
C'est pour ça que cette option dans /etc/systemd/logind.conf est importante.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 05 juin 2016 à 13:26.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug ferme chez tmux
Posté par GG (site web personnel) . Évalué à 3.
Quand ta session est fermée (volontairement ou non), ton terminal avec la connexion ssh est aussi fermée… et donc tmux se retrouve tout seul. Avec le nouveau systemd il se fait euthanasier illico-presto.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 05 juin 2016 à 15:01.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bug fermé chez tmux
Posté par err404 (site web personnel) . Évalué à 3.
Je ne parlais pas de remote, mais bien de ssh en localhost.
Le comportement de systemd est le même si j'ouvre un terminal dans ma session graphique et que je lance tmux dans ce terminal.
[^] # Re: Bug ferme chez tmux
Posté par gnumdk (site web personnel) . Évalué à 1.
Pas chez moi…
[^] # Re: Bug ferme chez tmux
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 03 juin 2016 à 14:13.
Je pense qu'indépendemment du fait qu'il était documenté ou non, c'est toujours une mauvaise idée de changer brusquement un comportement connu et attendu des utilisateurs depuis 30 ans si ça n'apporte pas une amélioration drastique. L'équipe de systemD ne peut pas prétendre ne pas savoir que des tonnes d'utilisateurs gardent volontairement des sessions tmux/screen ou des process tourner via nohup, notemment quand ils sont dans un environnement hostile en terme de connection.
Donc je trouve raisonnable que l'option "par défaut" reste le même et que les administrateurs changent cette option dans les finalement très rares cas où ils ont une exprérience régulière de process qui bouffent des ressources indéfiniment.
Après ça fait partie des prérogatives des mainteneurs dans les distros de faire attention à ce genre de chose.
[^] # Re: Bug ferme chez tmux
Posté par totof2000 . Évalué à -4.
Bah, j'ai l'impression que certaines personens de cette équipe aiment faire parler d'eux, et que ce genre de buzzz flatte leur égo (je sais, on pourrait penser que c'est une attaque ad hominem, mais en y réfléchissant un peu, ce ne seraient pas les seuls à agir ainsi).
[^] # Re: Bug ferme chez tmux
Posté par GnunuX (site web personnel) . Évalué à 4.
Tu parles de ton cas personnel je suppose là. Pour avoir administrer des systèmes multi utilisateurs (LTSP, no-machine, VNC, …) je peux te dire que cette fonctionnalité est vraiment très intéressante.
Parce que le nombre de processus qui reste quand un utilisateur se déloggue peut devenir très important et très contraignant.
A titre privé je l'ai observé encore il n'y a pas si longtemps. Sur une petite machine qu'on utilisait à 2 avec ma fille (chacun sa session), on se retrouvait rapidement avec des processus qui tournait pour rien.
Par contre … je ne vois pas souvent des gens qui ferment leur session alors que des processus tourne. Il me semble que l'option par défaut est la bonne.
[^] # Re: Bug ferme chez tmux
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 03 juin 2016 à 15:11.
Non justement.
Ce que je dis c'est que les systèmes style LTSP/no machine représentent finalement une infime fraction des millions de machines unix qui tournent et que je trouve raisonnable qu'on ne change ce paramètre que pour celles-ci.
Là c'est toi qui parle d'expérience personnelle. Et j'imagine que si ta fille a des process qui continuent à tourner à son nom, c'est parce que vous lockez vos sessions au lieu de les fermer, et c'est donc un comportement attendu et hors sujet avec cette option systemd. Je doute que ta fille s'amuse à lancer des trucs avec nohup où joue à des jeux en ascii dans des sessions screen/tmux.
Reste qui si on parle de "PC" depuis 30ans, c'est justement parce que l'ordinateur (et même le téléphone !) est devenu personnel. Avec des laptops qui coûtent maintenant moins cher que des desktop, le pc familial est aussi un truc en voie de disparition, chacun a son laptop, sa tablette ou son smartphone sur les genous ou dans les mains et se balade aux 4 coins de la maison. Les sessions multiples et partagées, tu n'en vois plus que dans les entreprises et universitées.
[^] # Re: Bug ferme chez tmux
Posté par GnunuX (site web personnel) . Évalué à 6.
Non, je parle bien de "fermer" sa session.
C'est d'ailleurs pour cela que tous ceux qui administrent des serveurs de ce type font des scripts moche comme celui-là : http://www.skolelinux.no/~klaus/newnotater/x4181.html
[^] # Re: Bug ferme chez tmux
Posté par Michaël (site web personnel) . Évalué à -1. Dernière modification le 03 juin 2016 à 18:20.
Une machine c'est fait pour être utilisé avant d'être administré! Ici, j'ai lu une vingtaine de messages du fil et aucun ne mentionne une solution simple de remplacement: du point de vue de l'utilisateur c'est une régression pure et simple!
P.S.: En lisant plus loin j'ai lu la solution simple… beacuoup de bruit pour pas grand chose! ;)
[^] # Re: Bug ferme chez tmux
Posté par ookaze . Évalué à -2.
Le problème, c'est que pour qu'il y ait un changement, il faut que la nouvelle solution soit visible. Cette possibilité était présente depuis les débuts de logind, or personne ne l'utilisait, parce que c'était déjà configurable, mais on laissait l'option par défaut à No en upstream. Et je pense tout simplement que personne n'en avait rien à faire et a repoussé à plus tard.
Comment se fait-il que tant d'utilisateurs utilisent tmux/screen ou laissent tourner des process via nohup ? Peut-être dans les écoles, mais sinon je ne vois pas.
Screen c'est très utile pour développer à distance chez soi, donc sur des postes utilisateur. nohup c'est quasiment toujours du hack.
Tout le monde ne compile pas tout son OS comme moi, et j'utilise principalement screen pour cela.
En tout cas, l'équipe de systemd est parfaitement au courant de l'existence de screen/tmux, à tel point que toutes les informations pour continuer à les utiliser avec le nouveau comportement par défaut, se retrouvent dans les man de logind et de systemd-run, et clairement indiqués dans la NEWS systemd.
Comme d'habitude, la personne qui a remonté le "bug" dans Debian instable, soit possède un niveau de compréhension trop faible pour une utilisation de screen, soit utilise la mauvaise foi pour forcer la main aux mainteneurs. Et ça a marché puisque les mainteneurs ont ramené l'option comme avant. C'est triste, mais pas si grave, les sysadmins qui ont maintenant eu vent de l'option, pourront l'activer sur leurs serveurs.
Non, ce n'est pas raisonnable selon moi. Un utilisateur moyen (la majorité) aurait une expérience améliorée avec cette nouvelle option par défaut, et est incapable de la modifier, tout simplement parce qu'en général tout cela le dépasse et il laisse aux autres le soin de lui choisir la meilleur solution (et il n'utilise pas screen de toutes façons). En revanche, ceux qui maîtrisent un peu plus sont parfaitement capables d'utiliser les moyens palliatifs ou de modifier l'option de manière générale.
[^] # Re: Bug ferme chez tmux
Posté par totof2000 . Évalué à 6.
Quand tu es admin et que tu n'as pas une connection des plus fiables pour intervenir, c'est pratique d'avoir un truc qui continue à tourner en cas de coupure.
[^] # Re: Bug ferme chez tmux
Posté par totof2000 . Évalué à 6.
Hum. En lisant un peu plus bas, je me suis rendu compte que le réseau n'est pas forcément un problème (ça peut l'être pour une session via xdmcp par exemple), mais que ça peut poser problème si tu es admin et que' tu as un oom killer qui te tue ta session X (ça m'est déjà arrivé avec un firefox et un java qui prenait trop de RAM sur ma machiine).
# Depuis NEWS
Posté par ff9097 . Évalué à 10.
[^] # Re: Depuis NEWS
Posté par GnunuX (site web personnel) . Évalué à 6.
Tu as pourri une grosse partie de son argumentaire … Si maintenant on se met à vérifier les sources d'un troll un vendredi …
[^] # Re: Depuis NEWS
Posté par err404 (site web personnel) . Évalué à 1. Dernière modification le 03 juin 2016 à 14:21.
Tout à la fin de mon texte, j'indiquais:
ff9097 a indiqué une solution, toi tu n'a pas lu mon texte jusqu au bout.
[^] # Re: Depuis NEWS
Posté par GnunuX (site web personnel) . Évalué à 4.
Ouais enfin la solution était dans le texte que tu as indiqué AU DESSUS de la partie qui te propose de compiler l'option par défaut.
Tu as 21 lignes qui explique comment faire et a quoi ca sert. Puis 2 lignes qui explique comment changer la valeur par défaut à la compilation. J'ai mal a croire que tu n'ai retenu que les 2 dernières lignes "de bonne foi".
[^] # Moi aussi je lis trop vite et de façon superficielle.
Posté par err404 (site web personnel) . Évalué à 2.
Ce sont des choses qui arrivent quand on cherche une solution le soir avant d'aller se coucher, si j'avais vu cette autre solution dès le début, j'aurais plutôt fais un journal qui donne directement cette solution plutôt que d'en arriver à quémander une solution.
Je n'avais pas lu le texte assez en détail, de la même façon que je ne lis pas systématiquement les changelog de tous les paquets que je mets à jour sur mon ordi perso parce que la plupart des autres paquets indiquent quand il y a un gros changement dans le comportement habituel.
j'avais d'autres réglages dans le fichier /etc/systemd/logind.conf (ceux qui concernent le comportement quand je rabat l'écran du portable) ils ont étés écrasés sans prévenir,
D'habitude il y a dpkg qui me dit que le fichier de conf qui sera installée est différent de celui qui est présent, et à ce moment, j'ai le choix entre installer la version du paquet, garder ma version, ou voir la différence etc.
Mais avec systemd, je n'ai pas avertissement, tout est écrasé silencieusement.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par Sufflope (site web personnel) . Évalué à 10.
Ah oui voilà c'est la faute de systemd qui a piraté dpkg pour court-circuiter l'avertissement qu'un fichier a été modifié.
Enfin on s'en fout des détails, l'important, c'est que c'est la faute de systemd.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 1.
Moi je l'ai eu et on m'a demandé comment je voulais gérer la fusion. Mais tu étais peut-être trop fatigué pour appuyer sur "D" et "Enter".
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par err404 (site web personnel) . Évalué à -5.
Ah ah, surement pas.
Quand je tombe sur ce genre de question, je fais particulièrement attention.
Mais je te remercie d'avoir soulevé ce point.
Après vérification de mon Debconf, le niveau de priorité est réglé à 'high' ('high' is for rather important questions), donc pour les questions importantes, et, vu comment les devs de Systemd considèrent les utilisateurs, je n'étais pas près de voir s'afficher de question…
Je passe à 'medium', et j'espère bien avoir plus de retour sur les réglages par defaut de systemd la prochaine fois.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par Sufflope (site web personnel) . Évalué à 3.
Et allez c'est encore la faute de systemd. C'est Lennart qui choisit le niveau de priorité des fichiers dans le packaging dans Debian ? Quel salaud il a vraiment tout infiltré. Tu te ridiculises.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par err404 (site web personnel) . Évalué à -5. Dernière modification le 03 juin 2016 à 22:37.
ton raccourci est encore pire que le mien :p
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par Vincent Bernat (site web personnel) . Évalué à 7.
/etc/systemd/logind.confest un fichier de configuration (car il est listé dans/var/lib/dpkg/info/systemd.conffiles). Aussi, s'il a été modifié des deux côtés, son remplacement sera toujours demandé à l'utilisateur, sauf si celui-ci lance dpkg avec--force-confnew(ce qui se fait difficilement par accident). Ce n'est pas quelque chose qui est géré par debconf donc le niveau de priorité n'a aucune importance.[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par Kaane . Évalué à 6.
Oui, si il a été modifié des deux cotés.
En d'autres termes, si la conf de l'utilisateur est l'ancienne conf par défaut, elle sera mise à jour avec la nouvelle conf par défaut de façon silencieuse, à moins que le packageur ne lève spécifiquement une exception pour ça.
C'est une erreur du packageur et non de systemd (nous sommes d'accord) - mais on peut parfaitement avoir ce paramètre qui passe de "no" à "yes" lors d'une mise à jour et ce sans aucun avertissement.
Donc le tout tout est écrasé silencieusement. de err404 est très probablement vrai.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par Frank-N-Furter . Évalué à 1.
https://wiki.archlinux.org/index.php/systemd#Drop-in_snippets
Depending on the time of day, the French go either way.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par Dolmen (site web personnel) . Évalué à -1.
Ce sont des choses qui arrivent quand on lance un troll le soir avant d'aller se coucher : la journée du lendemain est difficile parce qu'on s'en prend plein la gueule, et qu'on l'a bien mérité.
Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par err404 (site web personnel) . Évalué à 3.
Je ne m'en suis pas pris plein la gueule, du moins pas plus que systemd, et j'ai trouvé une solution au problème. (et je me suis bien marré toute la journée du vendredi, rassures-toi :D )
Reste à savoir pourquoi je n'ai pas eu d'avertissement sur la modification arbitraire de /etc/systemd/logind.conf (les avis sont mitigés la dessus)
j'ai passé la priorité de debconf à un niveau inférieur, on verra bien.
D'après ce que j'ai pu lire dans un autre commentaire, le fait que les packageurs de systemd pour debian soient revenus au comportement habituel qui consiste à ne pas tuer les processus daemonisés des utilisateurs à la fin de la session, prouve que j'avais raison de me fâcher. ou du moins que nous partageons le même point de vue.
L'important c'est de pouvoir intervenir librement dans les réglages, sans avoir à subir des généralités au prétexte que tout le monde fait dans un sens ou dans l'autre.
Je comprend tout à fait que les besoins (ou les envies) des uns diffères des autres.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par gnumdk (site web personnel) . Évalué à 4.
Parce que dpkg ne met un warning que si le fichier a été modifié PAR L'ADMINISTRATEUR?
[^] # Re: Depuis NEWS
Posté par err404 (site web personnel) . Évalué à 4.
Merci ff9097 \o/
Effectivement il semble possible de modifier le comportement par defaut de systemd sans être obligé de recompiler ce dernier.
le fichier à modifier se trouve dans /etc/systemd/logind.conf
et il faut remplacer la ligne #KillUserProcesses=yes par KillUserProcesses=no
sans oublier de la decommenter bien entendu.
Vous croyez que c'est possible de demander à systemd de prende en compte le changement sans rebooter l'ordinateur?
tiens, si ça se trouve la modification apportée ne suffira pas…
[^] # Re: Depuis NEWS
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Elle est documentée partout. Arrêtons la mauvaise foi et essayons d'être optimiste ;-)
[^] # Re: Depuis NEWS
Posté par Kaane . Évalué à 10.
C'est pas pour être méchant, mais dans le strict cadre du projet systemd, cet extrait de log n'apporte rien. Ca serait la glibc ou le kernel il n'y aurait aucun soucis - mais avec systemd si l'option par défaut sur un composant de systemd a une valeur, il ne vaut mieux pas y toucher.
Et ce pour trois raisons
1 - L'équipe de dev systemd a la fâcheuse habitude de n'en n'avoir strictement rien à faire des gens qui modifient les options par défaut. Le nombre de bugs remontés sur la mailling list qui se terminent par un "won't fix" avec un laconique "we do not see the interest in testing this configuration" est loin d'être nul. Que les choses soient claires, il est tout à fait possible qu'à partir de maintenant la team systemd considère que l'option est à yes dans tout le code qu'ils écrivent - on a déjà vu ce type de comportement pour les cgroups, udev, les sockets unix etc.
2 - Même si on met l'option à false, le scope est "abandonné" en cas de fermeture de session. CF freedesktop - Ca veut dire quoi un scope abandonné ? Ben systemd ne le gère plus. Autant dire que ca va être chaud de récupérer un process de ce scope, ou de le terminer proprement.
3 - C'est super savonné quand même. Logind gère un certains nombre de fonctions assez utile (et parfois nécessaires) - et lui quoi qu'il arrive il va clore les informations, accès, canaux dbus etc lié au login de l'utilisateur. Donc si votre programme "détaché" a besoin d'accéder à ces fonctions, il va de toute façon se vautrer comme une loutre bourrée à la bière à la fermeture de session.
La seule option pour avoir un comportement "presque" normal est de laisser la valeur à yes mais de lancer tout les processus qui sont susceptible de devoir être détachée dans des scope services utilisateurs tout en ayant l'option lingering activé.
CF freedesktop
Il y a un défaut tout de même :
En d'autres termes vous allez créer un sous scope de votre user.service à chaque fois que vous allez lancer un tmux/screen. Ce sous-scope va avoir un nom très pratique genre run-r14b0047ab6df45bfb45e7786cc839e76.scope.
Ce sous-scope va être relancé systématiquement au boot de la machine. Donc il ne faut pas oublier de faire le ménage de temps en temps. Bien sur si vous avez de vrais services utilisateurs qui doivent être lancé à chaque boot, il ne faut pas se planter pendant le ménage.
# Ne pas utiliser, recompiler… ou changer une option.
Posté par Anonyme . Évalué à 8.
Dans le changelog on peut lire qu’il y a l’option KillUserProcesses qu’on peut mettre à no… comportement par défaut changé, oui, comportement inchangeable ou difficilement, non.
Si c’est pour troller gratuitement c’est pas la peine.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par scullder . Évalué à 1.
Surtout que c'est un comportement qui me parait sain pour tout système partagé par plusieurs utilisateurs.
Si je suis le seul utilisateur logué sur une machine, je veux un accès exclusif aux ressources ou je veux savoir que les ressources sont partagées et que mes processus seront en concurrence avec un autre utilisateur.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Anonyme . Évalué à 3. Dernière modification le 03 juin 2016 à 10:35.
Pour moi, si un programme veut effectivement rester actif même quand l’utilisateur détenant le processus se déconnecte, il faut que se programme en informe l’init (à voir après pour la portabilité de la chose :D), plutôt que de traîner ad vitam æternam sur la machine en question.
Ça nettoie les processus qui n’ont juste plus rien à faire là, on est bien d’accord.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par gnumdk (site web personnel) . Évalué à 8.
Ca va faire du bien à KDE vu le nombre de fois que j'ai vu des enfants de kdeinit vivre après une fin de session…
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . Évalué à -6.
Systemd, ou comment ne pas encourager l'écriture d'applications au comportement propre. C'est sûr, ce gars a une vision à long terme pour linux…
Scoop d'une source confidentielle: systemd 666 intégrera un anti-virus.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Anonyme . Évalué à -1.
Résistance au changement ?
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par err404 (site web personnel) . Évalué à 1.
Je ne fais pas de la résistance au changement, mais j'aimerais que ce genre de changement soit mieux documenté lors de la mise à jour.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Sacha Trémoureux (site web personnel) . Évalué à 2.
Euh, c'est dans le changelog. C'est dans la dernière version de systemd, donc le temps que ça soit embarqué dans les distributions stables, ces dernières ont le temps de savoir sur quel pied danser.
Je comprendrais que ça râle si c'était pas désactivable, mais là faut pas pousser. Mais bon, faut bien râler…
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . Évalué à 5. Dernière modification le 03 juin 2016 à 12:38.
Haha, je te cites "Ne pas utiliser, recompiler… ou changer une option.". Résistance au changement ?
Sérieusement je vais te donner la bonne interprétation de mon commentaire. Je pose simplement la question de savoir si cette décision apportera une plusvalue en ce qui concerne une amélioration de la qualité des applications. J'en doute très fortement car je prends comme hypothèse que masquer des problème engendre une non-correction des bugs de la part des programmeurs, et je justifie cela non pas par leur fainéantise innée, mais parce que ces bugs ne seront tout simplement pas rapportés par les utilisateurs. Bref, dans le long terme, c'est une mauvaise décision selon moi :-)
À comparer à OpenBSD qui utilise des techniques pour révéler les bugs (p.e. un malloc particulier), et dont au final tous les OS en profitent…
(Sinon, ne t'inquiètes pas pour moi je vais m'adapter comme toujours, c'est juste qu'un jour je vais oublier que sur telle machine je dois faire les choses différemment et me faire avoir… Et puis me redemander à quoi ça sert d'avoir mis ce comportement par défaut… enfin bon la vie est pleine de contradictions :P).
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Anonyme . Évalué à 1.
Ah ok je comprends mieux.
Bon alors du coup, dans notre cas du KillUserProcess, est-ce que cela a mené à une correction des problèmes ?
Plus haut, en réponse à un commentaire, il est fait part d’un processus kdeinit (de KDE donc) qui traîne après fermeture de la session KDE.
Ayant utilisé KDE par le passé, je ne peux que valider ce comportement.
KDE existe depuis longtemps et ce comportement existe toujours… et il n’y a pas que lui. On peut prendre l’exemple de redshift aussi.
Alors ok ce sont des problèmes liés à des softs "desktop", et on peut se poser la question de ce que ça va donner sur des softs "serveur".
Pour l’instant ma réflexion s’arrête ici : si l’init fait du nettoyage, et bien je préfère qu’il le fasse, plutôt que de laisser des applications tourner alors qu’elles n’ont plus rien à faire. Laisser une instance d’un soft tourner peut également engendrer des bogues lors du développement. Pour moi, l’un dans l’autre, c’est un peu bonnet blanc et blanc bonnet.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . Évalué à 3.
Bien vu, tu mets le doigt sur la question essentielle. Si le problème est "il y a des process qui restent", je suppose que la réponse est oui. Si le problème est "le process X a un bug qui fait qu'il ne se ferme pas comme il devrait", alors la réponse est inverse. C'est comme choisir entre traiter la cause ou les symptômes; en fonction de l'objectif à atteindre la solution peut-être différente. Si l'objectif est à long terme, s'attaquer aux causes fonctionne généralement mieux.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Sufflope (site web personnel) . Évalué à 6.
Ce qui n'empêche pas, point de vue système, de se prémunir des comportements malsains de programmes, sans attendre qu'ils soient parfaits et exempts de bugs.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par xcomcmdr . Évalué à -2.
Le bon sens même. Et Microsoft l'a compris le premier.
Et après on se demande pourquoi Linux n'est pas prêt pour le desktop…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par ookaze . Évalué à 2.
En fait ce commentaire indique que la décision est excellente à court comme à long terme. En effet, aucun utilisateur n'est capable de remonter des problèmes survenus après la fermeture de sa session. Car l'immense majorité des utilisateurs, après s'être déconnecté, ne va pas se reconnecter ensuite pour voir s'il n'y aurait pas des mauvais comportements dans les logs ou des process fantômes, le seul endroit où ce comportement sera visible.
Les mauvais comportements seront au contraire désormais un peu plus visibles, car on pourra désormais voir ces process mourir dans les logs de l'utilisateur.
Cette décision apporte une énorme plus-value : elle permet d'indiquer clairement à l'init que les process qui restent actifs sont voulus ainsi, alors qu'auparavant, il n'était pas possible de faire la distinction avec des mauvais comportements de process, puisque c'était un hack pour tromper les autres init.
La plus grosse contradiction dans toute cette affaire, c'est que les soi-disant sysadmins qui se plaignent que systemd n'est pas fait pour leurs serveurs, sont les mêmes qui se plaignent de ce changement de comportement par défaut, alors qu'il est parfaitement adapté aux serveurs justement.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . Évalué à 6.
N'est-ce pas contradictoire ?
Comme quoi, chacun voit midi à sa porte :-)
BTW: As-tu déja utilisé nohup, dans le cadre de sysadmin ? J'imagine que non… Généralement, c'est pour faire nohup mon_script_exceptionnel_que_je_n_veux_pas_interrompre, donc bref une manipulation exceptionnelle (genre un dump de DB, reconstruction raid, etc), pas pour lancer un daemon (ça c'est parfaitement la responsabilité job d'init). Bref "indiquer clairement à init que les process qui restent sont voulus" c'est faire "nohup"… Avec ce comportement par défaut ça sera "systemd-spawn-machinchose --flag-super-important nohup mon_script", ça c'est le progrès… Aussi un "soit-disant sysadmin" utilise généralement différentes versions d'OS et différents OS, tu peux imaginer un peu le casse tête (?).
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Sufflope (site web personnel) . Évalué à 0.
On pourrait s'interroger sur la pertinence de balancer des traitements critiques sans prendre la peine de les rendre résilients, relançable… mais bon il fera un alias nohup = systemd-run --trucmuche et voilà.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . Évalué à 1.
La vraie vie, toussa…
Explicit is better than implicit !
(ok: vraie vie, toussa…;-) )
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par ookaze . Évalué à 3.
Non, puisque cela concerne uniquement la minorité de personnes qui va aller regarder ses logs (par quelque moyen que ce soit, par exemple via un outil de monitoring).
Les utilisateurs que j'ai décrit, évidemment, n'iront pas voir.
Je n'ai jamais utilisé nohup dans le cadre de sysadmin. Et cela simplement parce que nohup, lorsque je l'utilisais, se révélait toujours être une catastrophe, car bien souvent, on oublie de mettre quelquechose dans le journal, et c'est difficile à gérer. J'ai très vite découvert screen, et donc nohup n'avait plus aucune utilité pour moi depuis ce jour. Surtout pour faire des choses comme des dumps de DB ou des reconstructions de RAID, je préfère avoir clairement en visuel le retour de ces fonctions. Si je suis en local ou quasi local sur le serveur, pas besoin de nohup ou screen, mais si je suis à distance sur une connexion peu fiable (comme internet), dans ce cas, effectivement, j'utilise screen. Même pour des reconstructions de RAID logiciel sur Linux, ça s'effectue en tâche de fond et je n'ai jamais eu besoin de nohup.
systemd-run --scope --user , cela n'a rien de compliqué, et un sysadmin digne de ce nom ne s'amuse pas à balancer des process en nohup sur différentes versions d'OS et donc sur plusieurs serveurs en même temps. Il faudrait que ces serveurs soient extrêmement mal gérés pour avoir besoin de faire autant de tâches manuelles non prévues. C'est quand même censé être rare d'avoir à lancer ce genre de trucs. Sur l'unique machine où j'ai un screen en permanence, il est lancé une fois au boot dans une session. Je n'ai besoin que d'un seul screen pour gérer plusieurs serveurs, et je n'ai donc plus besoin de nohup.
De plus, nohup n'indique rien du tout à l'init, l'init reste incapable de faire la différence avec un process qui se comporte mal. Au contraire de systemd-run.
Et des process vandales, j'en ai vu aussi bien à l'école que dans des grandes entreprises, avec par exemple des tonnes de process java zombies qui tuaient à petit feu les performances des serveurs à chaque redémarrage de l'application (obligatoire puisque grosse appli enterprise-ready Java pourrie comme bien souvent). Des problèmes qui parfois datent de plusieurs années et qu'aucun sysadmin ne remarque (j'espère par manque d'expérience).
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par karchnu . Évalué à 1.
nohup n'indique rien du tout à l'init, vrai. L'outil qui te sert à démarrer ta machine (init) n'a pas vraiment besoin de gérer les processus par après. systemd le fait, mais ce n'est pas le rôle de l'init.
nohup n'indique rien au gestionnaire de services / démons, vrai. Là on rajoute une meta donnée supplémentaire juste pour savoir si le processus doit rester en vie après la fin d'une session utilisateur. On ne peut pas dire qu'on soit sur la voie de la simplicité, surtout avec des commandes toujours spécifiques à systemd.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Sufflope (site web personnel) . Évalué à 3. Dernière modification le 03 juin 2016 à 16:01.
Du coup avec sysV /etc/init.d/apache restart une semaine après le boot de la machine, c'est bien ou mal ?
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par karchnu . Évalué à 3.
Un bootscript tu le réutilises, c'est fait pour démarrer ou arrêter ton programme. Mais ton programme init va pas décider de ce qui doit ou non rester en vie après le démarrage, de ce que j'ai pu en voir jusqu'à présent c'est spécifique à systemd ça. Je n'ai vu aucun système d'init qui tue une application parce que tu ne lui as pas dit qu'il fallait la garder en vie. Je ne suis pas fondamentalement contre ce genre de système, juste ça n'a rien à voir avec l'init.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par ookaze . Évalué à 1.
C'est faux évidemment, sysvinit s'occupe de lancer ou de tuer tes applications en fonction du runlevel choisi.
Et évidemment, une majorité de sysadmin très vocaux contre systemd ne le savent pas, parce que tout simplement, mon expérience a montré qu'une majorité de sysadmin ne comprend rien au système d'init et tous ses écueils, et le groupe contre systemd semble entièrement inclus dans ce groupe.
Ce qui n'est pas étonnant au final, vu qu'il faut vraiment ne pas avoir eu à gérer sysvinit correctement (indice : c'est impossible de le gérer correctement) pour ne pas voir l'immense avancée avec systemd.
Les bootscripts qui outrepassent complètement le comportement normal de sysvinit sont déjà un exemple flagrant. Normalement, tout devrait se faire dans inittab avec sysvinit. Et si l'init ne tuait jamais rien, cela signifierait qu'en cas de passage au runlevel 0 ou 6, il se contente d'éteindre sans avertir les applications, bonjour le massacre.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par karchnu . Évalué à 4.
Là encore, tu assimiles l'init à ce qui lance et tue tes applications, ok, c'était fait comme ça dans sysvinit. Soit.
Le runlevel est quelque-chose de particulier, et changer de runlevel ne peut être simplement comparé à démarrer et arrêter un processus qui est une tâche bien plus courante que de changer volontairement de runlevel (autre qu'au démarrage / arrêt de la machine).
Sous OpenBSD par exemple la gestion du runlevel est simple, et qui peut se résumer à : tu as un level où tu as tous les droits, un level de fonctionnement normal, il n'est pas possible de revenir au niveau « tous les droits » si tu es en mode « normal ». C'est simple, ça répond exactement aux besoins.
En aucun cas on ne va utiliser le runlevel pour simplement redémarrer une application ! C'est pas fait pour. Changer de niveau c'est un changement d'état de fonctionnement de ta machine, ce n'est pas annodin. Le système d'init, s'il gère aussi le runlevel, peut être amené à tuer des processus dans le but de ne pas induire des erreurs dans le fonctionnement. C'est pas tout à fait la même chose que de dire « c'est lui qui gère le démarrage et l'arrêt des processus ». D'ailleurs, tu n'indiques pas de commande à ton processus d'init pour qu'il démarre tes services, tu réutilises simplement ses scripts.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par briaeros007 . Évalué à 9.
GG. Moi je dis respect.
Réussir, dans la même phase, comparer les runlevel à une ouverture/fermeture de session utilisateur, et expliquer, par cet exemple, que les sysadmins "vocaux contre systemd" sont des idiots finis qui ne comprennent rien au fonctionnemnt du runlevel sysinit.
Et juste après expliquer que sysvinit c'est "tout dans inittab"…
Merci, tu m'a bien fait marrer :).
Si toi tu m'explique que je suis un con, je le prends comme un compliment là :)
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Moonz . Évalué à 4.
Ben justement dans le modèle sysv les scripts
/etc/init.d/*, malgré le nom du dossier, ne sont pas gérés par le binaireinit.[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par totof2000 . Évalué à 5.
Ben quand ton boulot c'est de passer ton temps à faire de la maintenance corrective, ça arrive plus souvent que tu peux le croire.
quand tu as un parc de plus de 1000 machines, ça commence à arriver souvent.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par gnumdk (site web personnel) . Évalué à 0.
Hmm, tu gères un parc de 1000 machines avec nohup??? Tu me fais peur… Tu sais que y'a des outils adaptés pour la gestion de parc?
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par briaeros007 . Évalué à 7.
marrant comment tu as du mal à lire et change les propos des gens…
Il a dit qu'il l'utilisait plus fréquemment avec un parc de 1K qu'avec un parc de 1 machines.
Il n'a pas dit qu'il l'utilisait comme outil de gestion de parc.
Mais bon comme faire des hommes de pailles semblent être le jeu favoris de certains …
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par briaeros007 . Évalué à 7.
GG pour le coup de "attend que je t'explique comment te passer de tes outils, tu n'en as pas besoin"…
en tant que sysadmin et perso, j'utilise régulièrement nohup, screen, etc…
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par needs . Évalué à 5.
Il y a une part de vérité. Si il y a un bug dans
kdeinit, c'est pas danssystemdqu'il faut le corriger/le cacher.[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par xcomcmdr . Évalué à 2.
Et tu fais comment pour les programmes qui ne sont plus maintenus ? Ou les programmes dont t'as pas le code source ?
Et empêcher que des mauvais process mettent à mal le système, ça empêche pas de publier des bonnes pratiques, hein…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par Moonz . Évalué à 4.
Et tu fais comment pour les programmes qui ne sont plus maintenus ou dont t’as pas le code source, et qui se basent sur l’ancien comportement ?
# Article et rapport de bug
Posté par Frédéric Massot (site web personnel) . Évalué à 10. Dernière modification le 03 juin 2016 à 12:45.
Ce problème est commenté/traité un peu partout depuis quelques jours :
Sur Phoronix et les commentaires
Le rapport de bug Debian
Au niveau du paquet Debian, l'option KillUserProcesses est repassée à no.
# systemd, le nouveau Multics
Posté par Ontologia (site web personnel) . Évalué à 3.
Étant sensible à l'histoire de l'informatique, et ayant écrit un article sur l'invention d'Unix (publié dans un Linux mag il y a un an), j'ai été particulièrement intéressé par ce post de blog qui illustre mon point de vue dépassionné sur la question.
Dépassionné, car j'utilise Linux au boulot, à un niveau qui fait que systemd, je sais à peine qu'il existe, et donc je m'en fou un peu.
Ce post de blog compare Multics et systemd; c'est écrit par un sysadmin, et c'est à mon avis très intéressant.
Teaser :
Multics tried to be everything to everyone by providing the most general interface possible. As a result, it was inefficient to develop and cumbersome to use. It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd.
Traduction libre : Multics essayait de tout faire pour tout le monde en proposant une interface la plus générale possible. résultat, celle-ci était difficile à écrire et peu pratique à utiliser. 99% des cas d'utilisations étaient très complexes afin de faire en sorte que les 1% soient plus simple.
C'est ce design-pattern que je pense être répété dans systemd
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: systemd, le nouveau Multics
Posté par Sufflope (site web personnel) . Évalué à 10.
Quand je vois la simplicité d'un fichier de config systemd pour l'immense majorité des cas (limite un unit file d'un daemon simple c'est 3 lignes, le nom du service, le binaire à lancer, et l'utilisateur) et les critiques style "mais ça casse mon script d'init de 1500 lignes pour mon usine à gaz ignoble", je dirais que c'est tout le contraire.
Le mec a confondu systemd et JEE.
[^] # Re: systemd, le nouveau Multics
Posté par totof2000 . Évalué à 0.
Mauvaise foi : Va voir un peu comment est fait le lancement des services sous xBSD.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 2. Dernière modification le 04 juin 2016 à 22:06.
C'est moins moche mais c'est toujours moche…
[^] # Re: systemd, le nouveau Multics
Posté par needs . Évalué à 10. Dernière modification le 03 juin 2016 à 18:11.
Il existe des systèmes d'initialisation on ne peut plus simple, comme runit, ou minit par exemple. La aussi c'est une histoire de moins de 10 lignes. Ce qui est important de comprendre, c'est que 10 lignes pour systemd et 10 lignes pour runit n'ont pas la même complexité lorsque l'on regarde le système dans son ensemble.
Systemd, c'est pas moins dans 270 000 ligne de C¹, dont 44 000 pour la gestion des services². Le code de minit ne dépasse pas les 1700 lignes, et celui de runit, 6500 (ou 3400 lorsque l'on ne compte pas la réimplantation partielle de la lib C³). C'est sans compter le fait que systemd définit plus de 60 services et bibliothèques⁴ qui sortent complètement du champs d'un système d'init.
Enfin systemd fait tout pour ce placer entre le noyau et un programme utilisateur. Ce qui ajoute un deuxième point critique au système, le premier étant le noyau (monolithique, lui aussi). Tout ceci montre que systemd est d'une complexité beaucoup plus grande que ce qui est nécéssaire, comme le montre les alternatives fonctionnelles. De plus cette complexité ce retrouve au cœur du système et envahit l'espace utilisateur. C'est pourquoi il est fallacieux de qualifier systemd de « simple », et présumer qu'une alternative est nécessairement complexe (« 1500 lignes »). La situation actuelle tend à montrer l'inverse, systemd étant complexe, et les alternatives en moyenne sont assez simples.
¹: En ne considérant que les fichiers du répertoire
src.²: Systemd étant un énorme monolithe, on ne peut pas séparer uniquement la partie du code qui gère les services. Ainsi, on obtient le chiffre de 44 000 lignes de code en ne comptant que le code dans
src/coreetsrc/systemctl.³:
runit/src $ cloc chpst.c runit-init.c runit.c runsv.c runsvchdir.c runsvctrl.c runsvdir.c runsvstat.c sv.c svlogd.c svwaitdown.c svwaitup.c utmpset.c⁴:
ls systemd/src | wc -l, qui donne 76. Résultat duquel il faut soustraire au moins trois fichiers, leMakefile,src/coreetsrc/systemctl, plus une bonne demi-douzaine pour des dossiers qui ne définissent ni services, ni bibliothèques.[^] # Re: systemd, le nouveau Multics
Posté par ookaze . Évalué à 1.
Cela ne veut rien dire, il y a toujours un init (PID 1) entre le noyau et les process utilisateur dans un OS multi-utilisateur, surtout si l'on veut que les process soient gérés correctement.
On peut le faire avec du shell mais les fonctionnalités seront loin d'être les mêmes.
Donc il n'y a absolument rien de montré ici. Et les alternatives fonctionnelles ont des manques énormes.
Tous ces init sont très bien dès lors qu'on a des environnements figés, comme de l'embarqué dédié à une tâche spécifique avec un noyau configuré pour.
[^] # Re: systemd, le nouveau Multics
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
En fait, le nouveau comportement en question ici, c'est pas tout à fait systemd mais logind. Sur une machine de calcul, lorsque tu lances un job via un scheduleur, il t'ouvre un cgroup ayant un cpuset, un memset… A la fin de ta session (walltime), le cgroup est supprimé avec tout ce qu'il y a avec. Job qui ne finit pas dans les temps ==> nettoyer !
En fait, logind fait exactement la même chose, désormais, il nettoie tout en fin de session via les mêmes mécanismes.
En fait, il faut JUSTE ré-écrire nohup pour qu'il ouvre une nouvelle session indépendante, dans un autre cgroup. Cela me parait tout à fait convenable et peut se faire via une IHM simple ;-) Il a été pris l'exemple de mosh plus haut et couplé à tmux, c'est hyper pratique (et simple)…
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 9.
Donc une parfaite illustration de "tried to be everything to everyone by providing the most general interface possible" si je comprends bien ?
Oui, comme tous les autres programmes qui utilisent le design pattern daemon() ou double fork. Tiens, il est où le patch de Lennart P. pour nohup et la glibc ?
Je suis d'accords avec le mainteneur de tmux: si on est cohérent, alors on modifie l'implémentation de daemon() dans la glibc pour parler avec systemd et éviter que chaque application doivent dupliquer le même code. Comme ça tout le monde est content, on garde l'interface posix et la vision de Lennart P.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par GG (site web personnel) . Évalué à 4. Dernière modification le 03 juin 2016 à 15:45.
Cela t'a l'air simple… mais je n'ai absolument rien compris.
Tout à l'heure ma session graphique à planté. Heureusement que mes tmux n'ont pas été coupés par systemd.
Heureusement que je n'utilise pas cette version de systemd…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: systemd, le nouveau Multics
Posté par ookaze . Évalué à -10.
Ce n'est pas grave, c'est parce que tu n'as pas le niveau, c'est visible par ce que tu dis ci-dessous.
La version de systemd que tu utilises possède déjà le mécanisme décrié, c'est juste que l'option n'est pas activée par défaut dans le fichier de configuration.
Eh oui, la seule chose qui a changé dans cette version de systemd en ce qui concerne cette fonctionnalité, c'est une option d'un fichier de configuration qui est passé de Yes à No. Lorsque l'on utilise tmux, je pense que l'on est capable d'aller modifier une option dans un fichier de configuration.
[^] # Re: systemd, le nouveau Multics
Posté par GG (site web personnel) . Évalué à 4.
Donc si j'utilise tmux, je dois prévoir que je vais devoir changer la config d'un autre logiciel…
Ce qui me dérange avec systemd, c'est qu'il se mêle de ce qui ne le regarde pas.
Un peu comme NetworkManager qui va toucher aux réseaux, sans te demander, et sur des éléments qu'il n'a pas mis lui-même en place.
La première chose que je fais sur une machine ddont le réseau déconne, c'est de virer NetworkManager. Avec systemd, j'ai rarement le choix.
Si des admin-sys craignent des pprocessus sans contrôles, il peuvent installer des vm pour leurs utilisateurs.
Bref, la solution que tu proposes pour faire fonctionner tmux proprement est compliquée. La solution simple est de virer cette fonctionnalité de systemd. Ceux qui la veulent sauront la mettre en place.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: systemd, le nouveau Multics
Posté par GnunuX (site web personnel) . Évalué à 0.
Tu peux très bien utilisé tmux et ne avoir besoin de modifier la configuration de logind.
Tu as besoin de modifier logind si (et seulement si) tu veux lancer des tâches dans tmux ET fermer ta session.
[^] # Re: systemd, le nouveau Multics
Posté par GG (site web personnel) . Évalué à 10.
C'est quoi l'intérêt de tmux et scr(een si ce n'est pas de survivre à une déconnexion?
Des coupures réseaux ou des fermetures intempestives de sessions, ça existe, et j'utilise tmux pour que mes taches continuent malgré TOUT. S'il y a un problème, je suis assez grand pour faire un kill du processus.
L'admin sys, si ce n'est pas moi, est assez grand pour demander à l'utilisateur des info sur les processus.
Systemd à rendu compliqué un truc simple. Heureusement que les équipes de Debian sont revenus en arrière.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: systemd, le nouveau Multics
Posté par totof2000 . Évalué à 6.
Hum … Quel est l'intéret alors de tmux si ce n'est pas pour survivre à une fermeture de session (involontaire ou volontaire) ?
Dans ce cas un tmux sur ton desktop ne sert à rien
[^] # Re: systemd, le nouveau Multics
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 03 juin 2016 à 18:02.
euh vous exagérez il y'a plein de trucs intéressants dans tmux autre que la persistence de session comme par exemple des onglets/panneaux multiples, une manipulation de l'historique assez puissante avec des bindings vi, du partage de session à plusieurs, etc.
À vrai dire j'utilise tmux tous les jours et je détache rarement ma session.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 1.
Ca tombe bien, on ne parle pas d'SSH ici…
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 1.
Vu ton manque flagrant de compréhension à la lecture, j'ai du mal à croire que tu, en te paraphrasant, aies été capable d'aller lire la doc pour comprendre que systemd est aussi un gestionnaire de session qui remplacera les daubes genre ksmserver et gnome-session.
(Ceci était une communication de l'association pour la défense des commentaires inutiles et gratuits.)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par ookaze . Évalué à 2.
Pas du tout, tu peux aussi lancer la commande adéquate pour que cela fonctionne comme avant (systemd-run et passer ta session en linger, si c'est autorisé par l'admin).
Il se mêle exactement de ce qui le regarde, à savoir gérer les process utilisateur.
Je pense que ce qui gêne le plus les utilisateurs qui gueulent, c'est qu'auparavant, ils pouvaient tromper le sysadmin, et maintenant ils ne pourront plus.
C'est le boulot de NetworkManager de toucher aux réseaux, c'est même dans son nom. Si on n'aime pas on vire, c'est tout.
Ils peuvent aussi utiliser cette option de systemd, ce qui est infiniment plus simple et moins consommateur de ressources que d'installer des VM pour les utilisateurs.
La solution proposée par les dévs de systemd est extrêmement simple, et cette fonctionnalité est présente dans systemd depuis de nombreuses versions, a une réelle utilité, et ne gêne personne : il n'y a aucune raison de l'enlever. Et oui, ceux qui l'utilisaient auparavant savaient changer "#KillUserProcesses=no" en "KillUserProcesses=yes" dans /etc/systemd/logind.conf.
[^] # Re: systemd, le nouveau Multics
Posté par GG (site web personnel) . Évalué à 8.
Tu l'as la commande?
Avant, je lançait tmux, et ça marchait.
Maintenant, il faudrait que je passe par systemd-run et passer ma session en linger… je ne suis pas contre du changement, mais cela m'a l'air bien plus compliqué qu'avant.
Je viens de regarder le man… c'est très pauvre, et je ne vois pas comment je dois écrire ma commande, et si je comprends, l'admin-sys doit aussi l'autoriser (comment?). Bref, c'est vraiment très complexe.
J'ai assez à faire sur mes machines pour pas avoir ça aussi à gérer… faut croire que systemd permet aux admin-sys de garder leur poste…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: systemd, le nouveau Multics
Posté par totof2000 . Évalué à 1. Dernière modification le 03 juin 2016 à 17:33.
ben non, avant systemd les admins passaient leur temps à écrire/modifier/comprendre des scripts d'init compliqués. Faut bien qu'ils s'occupent maintenant.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à -4.
s/leur temps à écrire\/modifier\/comprendre des scripts d'init compliqués/faire de la merde/g
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par Frank-N-Furter . Évalué à 8.
Jayce?
Depending on the time of day, the French go either way.
[^] # Re: systemd, le nouveau Multics
Posté par Sufflope (site web personnel) . Évalué à 4.
Tu sais faire tout ça mais rien avec systemd, même pas une unit file simple qui ressemble à : (c'est de tête c'est ptêtre pas exactement ça mais l'idée est là) :
? Y a un truc qui colle pas.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par totof2000 . Évalué à 2.
C'est parce qe t'as pas écrit les 3 bonne lignes, espèce d'idiot. Tout se résout en 3 lignes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par ookaze . Évalué à -2.
Mon petit doigt me dit que bash, pour gérer le langage des shell scripts, a besoin de plus de LOC que systemd pour gérer ses fichiers d'init. Bref, probablement un argument fallacieux en plus d'inverser complètement la réalité.
Clairement inmaintenable, surtout qu'il fait appel à plusieurs autres binaires et contient une inclusion (source) d'un autre fichier qui peut contenir tout et n'importe quoi (dont d'autres inclusion), et sans lequel ce script ne fonctionne plus. Mais évidemment, si on ne parcourt pas le fichier, on ne peut pas s'en rendre compte.
[^] # Re: systemd, le nouveau Multics
Posté par Moonz . Évalué à 8. Dernière modification le 06 juin 2016 à 15:53.
C’est ridicule. Tu prends en compte le nombre de lignes de C de CPython quand tu évalues la taille d’un programme en Python ? Et pourquoi pas aussi inclure la glibc, gcc et le kernel ?
Et systemd il fait appel à d’autres binaires comme
/lib/systemd/systemd-*. C’est nul, c’est inmaintenable.[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 3.
De toutes façons, le kernel vous nique tous en nombre de lignes, hein…
Et pourtant il est maintenable… Comme quoi le LOC seul n'est pas une information suffisante, et ce concours de la-plus-petite entre systemd et SysV n'a pas lieu d'être.
Merci et au revoir !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 1.
« Linux is bloated » : http://www.linux-mag.com/id/7536/
Si Linux est maintenu, c'est avant tout parce qu'il y a un nombre hallucinant de développeurs dessus, pas parce qu'il a été conçu pour être facilement maintenable.
[^] # Re: systemd, le nouveau Multics
Posté par Michaël (site web personnel) . Évalué à 6.
Tu ne devrais pas te fier à ton petit doigt. La première erreur est que FreeBSD n'utilise pas bash et ensuite, l'implémentation du shell fait 14kloc toute mouillée:
Quand on fonde son argumentation sur un rapport pifométrique 1 il vaut mieux éviter ce genre de conclusions tonitruantes.
Quelle idée d'aller fouiller là avec le petit doigt! ↩
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à -9.
Ben si tu sais écrire un OS, tu le fais, bien à la mode Unix années 70 et tu arrêtes de faire chier ton monde non?
[^] # Re: systemd, le nouveau Multics
Posté par Frank-N-Furter . Évalué à 3.
Dude, stay cool.
Depending on the time of day, the French go either way.
[^] # Re: systemd, le nouveau Multics
Posté par totof2000 . Évalué à 10.
Lorsqu'on utilise tmux, ça ne veut pas dire qu'on a les droits pour modifier le comportement par défaut de systemd : on va encore passer 1 mois à pleurer auprès des admins pour qu'ils puissent changer la configuration de ce comportement.
[^] # Re: systemd, le nouveau Multics
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
En fait, je pense qu'on prends ici le problème à l'envers. Il faut voir que pour cloisonner les choses, on est entré dans le monde des containers (ou cgroup pour simplifié). Du coup, à l'ouverture de session, du ouvre un nouveau container et à la fermeture, tu le fermes. C'est aussi simple que cela et n'a rien à voir avec systemd ou logind ;-) Comme je l'ai dis, les sessions sur les clusters de calculs sont ainsi depuis des années. On pourrait très bien (on a déjà) avoir la même chose avec sysvinit !
Si tu veux lancer un processus qui survive au container, un screen ou un tmux, tu ne dois pas modifier screen ou tmux mais simplement les lancer hors du container. nohup lance hors du shell courant mais pas hors du container. Il faut juste changer cela ;-)
Mais que nohup s'appelle demain outainer ou un autre nom, personnellement, c'est bien pareil. Sur ce coup-ci, cela fait pas mal de temps (plusieurs années) qu'il est dis qu'un jour, la session utilisateur sera certainement par défaut dans un container et qu'il faudra changer quelques habitudes comme nohup… C'est pas un truc que les développeurs de screen ou tmux découvrent aujourd'hui ;-)
Sinon, il faut bien un paramètre admin à changer sur une machine car encore une fois, sur une machine de calcul, on ne peut pas laisser un utilisateur avoir des processus en nohup au delà de sa session (walltime). Bien que je n'aime pas la syntaxe CamelCase des projets gravitant autour de systemd, modifier une ligne, c'est pas la mort. Avec des outils comme cfengine, puppet ou équivalent, c'est déployer sur un parc de plus de 1000 machines en 1h…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10. Dernière modification le 05 juin 2016 à 02:23.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par totof2000 . Évalué à 7.
C'est bien ce que je disais lorsqu'on trollait sur systemd : il va falloir réécrire plein de trucs pour que ce soit systed compatible, et maintenir des versions "systemd" et "non systemd" de ses programmes si on veut un minimum de portabilité.
[^] # Re: systemd, le nouveau Multics
Posté par ookaze . Évalué à 2.
Ce post de blog est extrêmement intéressant.
Hélas, il est floué peu après le début.
C’est amusant de lire qu’une « demi-vérité est pire qu’un mensonge » (sophisme, puisqu’une demi-vérité est un mensonge, mais bon), et de lire ensuite « modern BSD systems continue to manage just fine by way of incremental improvements to the pre-existing components », alors que FreeBSD (il me semble, ou est-ce OpenBSD ?) a annoncé la nécessité de développer son propre systemd car les systèmes ne sont plus gérables en l’état.
Ceci dit, l’analyse est intéressante, parce que les points indiqués sont vrais. Mais le premier point est parfaitement connu, et la volonté est bien d’utiliser un script shell pour les cas à la marge, comme les daemons qui se comportent mal. Et AMHA ce sera une réelle avancée pour tout le monde, parce que tous les daemons qui se comportent mal seront immédiatement visibles par tous les sysadmins. La volonté n’est surtout pas d’ajouter des fonctions spécifiques pour ces daemons, mais de faire en sortent que leurs développeurs les corrigent. Et on a déjà commencé à voir de nombreuses améliorations depuis la naissance de systemd, donc c’est un point extrêmement positif. J’ai vu des améliorations dans gdm, mysql/mariadb, apache, les process pour NFS entre autres.
L’assistance des utilisateurs (en général des mainteneurs de distribution ou des sysadmins) est une bonne chose selon moi. Rien n’empêche d’utiliser d’autres moyens plus sioux si on en a l’habitude ou l’envie, mais gueuler sur « systemctl edit » parce que ça assiste le sysadmin n’a aucun sens.
Mais c’est normal puisque l’auteur n’a absolument pas compris les nombreuses bonnes raisons pour l’utilisation de « systemctl edit », des raisons qui sont essentiellement liées au déploiement de distributions. Ce n’est pas non plus la panacée évidemment.
Hélas, l’auteur commence à tomber ensuite dans le déraisonnable et même carrément le mensonge, lorsque l’auteur dit qu’avec sysvinit, il était capable de dire exactement quels services allaient être démarrés. Je n’ai jamais vu le moindre sysadmin capable de prédire cela avec sysvinit, c’est même spécifiquement la raison pour laquelle tout sysadmin sain d’esprit rebootait le serveur au moins une fois lorsqu’il modifiait la séquence de démarrage, pour être sûr que ça allait bien exécuter les scripts jusqu’au bout. Et je n’ai pas dit « lancer les services » mais « exécuter les scripts ». Parce qu’avec sysvinit, ce n’est pas parce que le script d’init était lancé et renvoyait un code retour OK (voire un bel OK vert à l’écran) que le service était vraiment lancé ou n’avait pas planté après coup.
L’auteur parle de sécurité, mais ensuite ose venir se demander pourquoi systemd ne veut plus lancer de shell (/bin/sh) avant de lancer chaque daemon. Cet argument est d’une telle mauvaise foi : un daemon n’a absolument pas besoin d’un shell pour être lancé, c’est complètement contre-productif. L’auteur sera incapable de justifier pourquoi il faudrait lancer un shell, surtout qu’avec sysvinit, les daemon sont censés être lancés dans l’inittab, sans aucun shell. Donc il renverse la question pour dire que systemd est pas bien parce qu’il ne veut pas lancer de process inutiles. Et souvent ce n’est pas que /bin/sh, mais beaucoup d’autres process lancés (augmentant la surface d’attaque de tout script init), juste pour un daemon qui n’en a que faire. Le pire, c’est que sur son BSD, ça ressemble plus à systemd qu’à sysvinit.
Bref, il y a des critiques valides, mais rien qui ne soit pas déjà connu ou pris en compte par les dévs de systemd. Il est triste aussi de constater que ce qui est le plus critiqué et le plus critiquable, c’est que systemd écoute les utilisateurs et rajoute des options qu’ils demandent, lorsqu’ils estiment que c’est un cas pertinent (suffisamment répandu pour ajouter une option).
[^] # Re: systemd, le nouveau Multics
Posté par briaeros007 . Évalué à 5.
Moi j'en ai vu un certains nombres.
Ils sont bizarres les sysadmins que tu as connu.
Avec systemd non plus. C'est le problème de dvp du scrip de démarrage ou du fichier de définition du service.
Et pour avoir fait les deux, les deux se comportent exactement de la même manière. Si tu merde dans ton fichier, ben ton fichier fera de la merde. Systemd n'est pas plus omniscient et ne devine pas que tu as "oneshot" mais en réalité ça voulait dire "fork", tout comme sysinit ne devine pas que quand tu lance /prefix/toto en réalité tu voulais le lancer avec start-stop-daemon ….
Pour le reste des hommes de pailles (vu que tu réponds à des arguments que tu as posé, et que personnes à soulevé, c'est la définition stricto sensus), je te laisse à ton dialogue intérieur.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9. Dernière modification le 05 juin 2016 à 11:19.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par Frank-N-Furter . Évalué à -2. Dernière modification le 05 juin 2016 à 12:11.
Et donc, quand est ce que tu passes à free/net/openBSD?
Depending on the time of day, the French go either way.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8. Dernière modification le 05 juin 2016 à 12:50.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par Frank-N-Furter . Évalué à 1.
Mon problème, ce n’est pas que tu n’aimes pas systemd, ou que tu chouines. C’est tes menaces de partir si les choses n’évoluent pas dans ton sens, parce que la plupart du temps les personnes qui se comportent de la sorte ne font rien pour changer leur situation, et se contentent de pleurnicher.
Tu n’aimes pas systemd, tu as les options constructives suivantes:
Tu remarqueras comment, menacer de passer a un BSD sur un petit forum internet, ne fait pas partie de la liste?
Depending on the time of day, the French go either way.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à 5.
Globalement généralement le gars qui dit « ce logiciel X ne me plaît, si ça continue comme ça je passe à Y », il va se faire basher sévère pour une bonne raison. On s'en fout de ce qu'il fait. Tout le monde se fout de ce que tu fais. Faire des menaces en tant qu'utilisateur qui ne représente rien c'est ridicule. C'est cool si tu passe à une BSD (ou autre). On est tous très content pour toi, ça leur fait des utilisateurs en plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 1.
Non, je ne connaissais pas la notion de "controling terminal" mais par contre maintenant que je sais, j'ai cherché à savoir comment connaître le "controling terminal" d'un process… C'est finalement ce qu'affiche la commande suivante:
$ ps
PID TTY TIME CMD
17587 pts/7 00:00:00 bash
17590 pts/7 00:00:00 ps
Mon controling terminal est "pts/7"
Par contre, quand je fais un ps sur mon user, je vois que plein d'applications n'ont pas de "controling terminal" (?)… Donc en gros, ça veut dire quoi, que chaque application doit gérer ça dans son code?
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à 4.
Si comme a l'air d'indiquer son commentaire, c'est juste le hup. C'est très simple. Un processus envoi un signal hup à ses fils lorsqu'il meurt. Soit.
Si A crée un processus B et que B crée un processus C, si B meurt sans tuer C alors C devient un daemon et ne sortira du contrôle du « controling terminal ». Comme quoi c'est pas parce qu'on y donne un nom anglais que c'est quelque chose de puissant…
Les cgroups sont là pour pallier à ça (les process ne peuvent pas sortir d'eux même d'un cgroups).
nohupc'est pas mal utilisé juste pour pouvoir faire :nohup firefox&Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 2.
Ah ok, moi je fais ça pour faire un nohup:
trap "" 1
firefox &
C'est quoi la différence?
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à 6.
nohupredirige la sortie standard et d'erreur dans un fichierTous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à -4.
Vu que le monsieur ne te reprend pas, je vais partir du principe que tu as raison et que son argumentation se résume à: "POSIX permet un comportement pourri et non défini"…
J'ai lu un peu partout qu'effectivement POSIX nécessite une mise à jour sur cette partie là mais qu'une fois de plus (et ça on peu leur reprocher), l’équipe de systemd met la charrue avant les bœufs… Mais bon, parfois pour faire bouger les choses… Genre POSIX, je vois ça plus comme un cadavre (dernière mise à jour 1995)…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par totof2000 . Évalué à 2.
Ben en fait systemd c'est bien parce que c'est un changement, et résister au changement, c'est pas bien.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 1.
Ben, tu ne pas toujours pas répondu, pourquoi j'ai 75% des mes programmes qui n'ont pas de controling terminal?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à -2.
ah ok, bon ben alors tant pis, je ne connaitrais pas la raison profonde… Par contre, ce que je note, c'est que cette histoire de controling terminal ne sert à rien si plus de la moitié des programmes n'en ont pas…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 5.
Et donc comment fait un process pour sortir d'un cgroup, parce que je trouve rien sur le net…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 2. Dernière modification le 08 juin 2016 à 09:22.
Bon, ben écoute, si tu ne veux pas répondre… Enfin en tout cas, Google ne trouve rien… Ce qui me semble logique en même temps, parce que si un programme peux sortir tout seul d'un cgroups, on se demande bien à quoi cela peu bien servir…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 08 juin 2016 à 18:13.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par Ph Husson (site web personnel) . Évalué à 4.
Un FS a des permissions. Lorsque le cgroup est créé, rien n'empêche de changer ses permissions
D'ailleurs c'est le cas par défaut:
Donc à moins de considérer qu'un processus normal est root, auquel cas on ne parle plus vraiment de session utilisateur, je comprends pas le sens de ce que tu dis.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à 4.
Donc ça fait 3 jours que tu insulte tout le monde parce que j'ai dis « les process ne peuvent pas sortir d'eux même d'un cgroups » au lieu de « les process d'un utilisateur ne peuvent pas sortir d'eux même d'un cgroups » (ça me paraissait évident) ?
Je ne sais pas quoi te dire…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1. Dernière modification le 09 juin 2016 à 17:24.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -1.
T'as rien de mieux à faire ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à 9.
Peut être qu'un dessin pourra te donner un peu le sourire :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par briaeros007 . Évalué à 6.
ben si ils peuvent … si ils ont les droits.
Encore heureux qu'on puisse controler qu'un process si un process peut faire ce qu'il veut ou pas avec ses limites.
[^] # Re: systemd, le nouveau Multics
Posté par briaeros007 . Évalué à 0. Dernière modification le 09 juin 2016 à 19:01.
le monsieur à utilisé
$PIDet pas$$, ça aurais aussi du mettre sur la piste…C'est beau cette génération. Les gens ne font pas le moindre effort, et le type qui se fait pourrir (suffit de voir ses notations) c'est celui qui prend du temps pour lui expliquer…
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -5.
Dis celui qui fait pas l'effort de comprendre ce qu'est systemd (hint : ce n'est pas que un logiciel d'init)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à -2. Dernière modification le 10 juin 2016 à 09:25.
C'est donc hors de propos.
Euh… ? Mes commentaires sont à plus ou moins 1 et ceux d'alenvers sont à +5
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par MCMic (site web personnel) . Évalué à 3.
C’est censé être alenvers le type qui «prend du temps pour lui expliquer…»?
Il explique très mal alors parce que j’ai rien compris à son charabia mêlant condescendance et «Hint: commande sans contexte» à tout va.
Alors que si j’ai bien compris au final ce qu’il voulait dire c’est
C’est poli, on a l’information, on en sort moins con.
Mais non, lui il préfère dire:
Alors bon j’ai pas lu tout le thread et ptet qu’il s’est énervé petit à petit mais pour une personne extérieure à la discussion il parait complètement déraisonnable et n’apporte aucune information. Il répond par énigme parce que ses interlocuteurs doivent «faire l’effort», ou il nous dit que la réponse est quelque part dans les 800 pages d’un bouquin à 30€. Définitivement, merci alenvers de «prendre du temps pour nous expliquer», c’est trop d’honneur.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 01 juillet 2016 à 23:18.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à -1.
Avec des droits particuliers, non ? Les droits root ou un droit pour accéder en écriture à cette arborescence c'est l'exception plus que la règle.
Je me fou de systemd et tout hurle comme un idiot sur une question totalement ridicule. Systemd te propose 2 comportements et Debian est préconfiguré avec celui qui ne te plaît pas. Tu crois vraiment que ça casse des briques ? Tu te sens pas un peu idiot ? Tu prends ta machine tu reconfigure, tu relance et tu oublie ou tu remonte un bug chez Debian ou tu passe à un autre os si ça te fait plaisir. Reste que s'extasier sur ça c'est ridicule.
Je n'aime pas particulièrement systemd, il est sur mon système et je me fou autant de lui que de sysvinit. Seul upstart me semblait sortir du lot.
Pour les hup, ça ne casse pas des briques ne te prends pas pour un gourou unix parce que tu connais 3 trucs. C'est un fonctionnement simpliste qui permet à n'importe qui de créer des daemons si tu en es content c'est cool si ça te gêne, je m'en fiche. Tu fais bien ce que tu veux de ta machine ça ne me regarde pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 8.
Ça n'est pas compliqué mais de la a dire que c'est "simpliste", faut pas exagèrer, hein. D'ailleurs ce sont deux concepts orthogonaux.
Le concept de daemon n'implique pas un traitement particulier de la session et des terminaux et réciproquement. On peut avoir un daemon controleur de session, ou pas contrôleur, avec un terminal, ou sans terminal. Un "daemon" est de ce fait une notion assez floue et qui dans le sens commun s'entend comme "tourne en arrière plan" (tourne == pas en tant que zombie…) mais sans impliquer d'autres comportements plus précis en ce qui concerne, p.e. la gestion de la session[1].
Effectivement, il y a des interactions et des changements d'états implicites avec la création/mort des processus, qu'il peut-être utile de comprendre pour ne pas se tirer une balle dans le pied. Bref dire que le hup sert à créer des daemons c'est comme dire que le klaxon sert écraser les piétons… Par exemple, ce screen/tmux qui nous occupe pour l'instant car il est sensé tourner en arrière-plan sans discontinuer (aux dernières nouvelles c'est un peu le sujet de la discussion, c'est un peu pourquoi on en est venu à dévier sur nohup) ne fonctionne pas du tout de la même façon qu'un programme lancé avec nohup même si, in fine, ils survivent tout deux à une rupture du terminal.
Pour info, HUP ça veut dire "hang up" et c'est le nom du signal que le noyau envoit au fameux "session leader" lorsqu'il détecte une perte sur la ligne du TTY "contrôleur". Ces histoires de tty controleur et de session est une relique de UNIX (enfin je crois que les sessions sont arrivées un peu plus tard avec BSD, la flemme d'aller vérifier), un gros hack qui s'est transformé en standard. Tout cela est bien documenté, il suffit de lire la doc, je ne ferrai pas l'affront de passer pour un "gouroux", on peut bien sûr discuter de la météo :D
Cette histoire de killer tous les users process, c'est un peu comme réinventer ce hack. Mais en encore plus crade car il n'y a plus de notion de session (enfin si, il parait que ça s'appelle logind et que ça sert à changer les ACL d'un fichier dans /dev/drm… pour ce que j'en ai compris) et donc pas de solution pour faire coopérer les programmes (on attend toujours le patch qui merge libdbus dans la glibc … :p et bye bye musl, uclib (ah non ça s'était déja fait))
C'est un peu retourner à l'ère des teletypes avec pour seul moyen pour se déconnecter que de tirer la fiche série…
Pour en revenir au sujet, pas la peine de se sentir idiot pour constater 1) c'est systemd qui a mis en avant un autre comportement assez surprenant 2) les empaqueteur debian ont peut-être mal évalué (ou ne se sont pas rendus compte de) la porté d'un tel changement 3) systemd reste une valeur trollifère sûre, au moins tout le monde est au courant; voir certains en font un argument marketing (cf. https://kaosx.us/news/2016/june/ )
Mon avis sur systemd (pour continuer un peu le trolll
^W^Wla discussion) c'est que c'est à la fois trop et trop peu. Trop peu car j'ai un peu l'impression que c'est juste le produit d'une lubie pour faire jou-jou avec la dernière technique à la mode mais malheureusement sans profondes remises en questions ou innovations quant à la manière de concevoir un systèmes. Les avantages mis en avants sont souvent de l'ordre technique (ex. "pas de fuite possible de daemon", oui et ? moi j'ai jamais eu de daemon qui "fuite") voir rhéthorique (ex. "la classe tout le monde est dans son cgroup", mais maintenant, concrètement, qu'est-ce que je peux faire avec ?). Aussi paradoxalement, les techniques d'implémentations et les choix de conceptions sont décevants. À savoir: quantité importante de code dans un langage "unsafe", comportement difficilement explicable/non déterministe, API trop volatile/non-spécifiée, documentation imprécise et incomplète, dépendance sur d'autres composants et tous les problèmes qui vont avec (dbus), nécessite toujours un noyau récent, support déficient des montées en version sans rebooter (i.e. systemd est sensé sérialiser son état, mettre à jour son binaire puis recharger son état mais ça ne fonctionne pas très bien), flexibilité/configuratibilité très limitée, parti pris de ne pas vouloir être porté sur d'autre OS[2]… Conséquences de vouloir être ce "trop". En plus, il s'immisce partout, veut devenir une sorte d'API de-facto pour administrer un système: logind, timed, dbus, etc.Sans finalement apporter de réelles avancées, il ne justifie pas, à mon sens, un tel coût.
Finalement, je constate que la rapprochement avec la guerre des unix est fort pertinent.
[1]: La fonction daemon est donc un cas particulier avec un comportement spécifique suffisant pour certains ou inacceptable pour d'autres. N'est pas daemon uniquement celui qui appelle daemon(), elle n'est d'ailleurs pas spécifée par POSIX (AFAICT).
[2]: le plus drôle dans cette histoire c'est que la personne à l'origine de cette décision, Lennart pour le nommer, justifie (et assume) cette décision avec un argument idéologico-politique. I.e. quand il dit "unix est mort, il s'appelle Linux" on est en plein dans le discours d'idées. C'est un comble de faire l'apologie d'une perfection (appelons un chat un chat) et en même temps de se refuser un moyen peu coûteux et avéré pour améliorer la qualité de son produit. Mais bon on a jamais pris de bonnes décisions en étant dogmatique… :p
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 6. Dernière modification le 05 juin 2016 à 16:31.
Petit retour d'expérience personnelle.
Pour ma part c'est fait. Je n'ai rarement eu un système aussi stable, un fonctionnement aussi prévisible et une documentation aussi claire. Tout n'est pas parfait, mais je n'ai aucune régression par rapport à mon usage (firewall, vpn, http et quelques appli web, smtp, dns, dhcp…). Pour quiconque cherche une alternative à Linux pour ses serveurs, FreeBSD ou OpenBSD peuvent répondre parfaitement aux attentes. Pour le firewall cela est même bien plus pratique (packet filter, ♥).
[^] # Re: systemd, le nouveau Multics
Posté par briaeros007 . Évalué à 2.
tu as choisis quel distrib si ce n'est pas indiscret ?
J'ai la flemme de chercher, mais hammerfs de dragonfly il est enfin prêt ?
Dans mes souvenirs openbsd était quand même plus galère à installer/configurer que freebsd.
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 4.
OpenBSD. J'aime la philosophie du projet, ça colle avec ma vision du monde. Il y a moins de features que sur FreeBSD, mais je fais avec, je n'ai pas de gros besoins. Pour ce qui est du système de fichiers, FFS me va très bien, je n'ai pas regardé ailleurs. Côté configuration, je ne sais pas si on peut faire plus simple qu'OpenBSD ! Mais peut-être avons-nous des critères différents. :)
[^] # Re: systemd, le nouveau Multics
Posté par ookaze . Évalué à 3.
Il faut savoir de quoi on parle avant de venir raconter n'importe quoi, là ce sont carrément des mensonges que tu racontes, comme je le montre ci-après.
Les gens de *BSD ne se sont jamais sentis coincés par systemd, mais par les API de logind à fournir pour diverses applications de plus haut niveau, des API demandées depuis très longtemps et que personne n'a jamais daigné fournir. Ben oui, systemd écoute les autres développeurs.
Et puisque tu n'as absolument pas vu que les *BSD voulaient un équivalent à systemd, je te renvoies vers la présentation de J. Hubbard (rien que ça), en espérant qu'il soit une source assez fiable https://www.phoronix.com/scan.php?page=news_item&px=MTg0ODE .
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 1.
Arrête, si tu lui dis que FreeBSD va avoir son launchd/systemd like, il va faire un malaise le mec ;)
Bon, non, il lui reste les autres BSD, ouf!
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 3.
Non, le projet consiste bien à porter launchd (celui d'Appel) et accessoirement d'ajouter les fonctionnalités manquantes au noyau de NextBSD (une sorte d'IPC fournie par mach sous MacOSX… IIRC). Bref rien à voir avec l'approche "seul au monde" prônée par certains.
D'ailleurs, FreeBSD a hérité de DragonFly un appel système pour faire du baby-sitting de process, et donc démontre qu'il n'y a pas que les cgroups comme solution. Bref que rien n'empêche objectivement de porter systemd sur BSD, il n'y a que l'hostilité affichée de son auteur.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 1.
Source ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 9.
http://linuxfr.org/nodes/86687/comments/1249943
http://linuxfr.org/news/un-entretien-avec-lennart-poettering
«Oui, je ne pense pas que les BSD soient encore vraiment pertinents. Et je pense que l'obligation implicite de compatibilité avec ces systèmes, quand quelqu'un code un logiciel pour un bureau libre ou pour l'écosystème du Libre, est une charge qui nous tire en arrière pour très peu de bénéfices.
[…]
Ces systèmes sont non pertinents pour le but qui est de mettre du logiciel libre entre les mains de tout le monde, et je pense que cela devrait être notre but.
[…]
Debian kFreeBSD est juste un joujou et les gens ne doivent pas s'y tromper. C'est bien si les gens font des OS joujoux, tout le monde aime les joujoux après tout.»
En plus d'être méprisant du travail et des personnes qui travaillent sur ces systèmes, c'est assez clair qu'il ne souhaite pas la coopération, non ? Il me semble qu'il a aussi explicitement écrit qu'il ne mergerait pas de patch de portabilité mais qu'il n'empêcherait personne de forker ou qq chose du genre. À prendre avec des pincettes donc car je ne vais pas m'amuser à chercher la source, considérons simplement que c'est une interprétation de "est une charge qui nous tire en arrière".
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 6.
Note: la partie du milieu illustre bien que c'est d'abord un argumentaire idéologique ("cela devrait être notre but") et il rajoute une excuse soit disant rationnelle/technique:"une charge qui nous tire". Alors que, objectivement, porter un logiciel n'impacte pas sa qualité, au contraire. C'est tellement gros que venir affirmer le contraire est faire preuve d'une mauvaise foie flagrante.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . Évalué à 7.
Objectivement, il a en partie raison quand même sur ce point. Sinon c'est ignorer les impacts d'un portage.
Un portage, pour être réussi et élégant doit se résoudre à exploiter le dénominateur commun entre les deux systèmes à gérer. Cela impose des limites, typiquement systemd repose sur les cgroups que les *BSD n'ont pas (ou en équivalent clair). Porter systemd revient soit à virer tout ce qui exploite les cgroups, ou alors à faire du code sale / difficile à maintenir pour se comporter sous Linux et *BSD de manière différente. Ce qui en plus rend difficile la détection de problème, de la création de la documentation, etc. si les comportements doivent différer car les mécanismes sous-jacents sont différents.
Bref, la raison technique invoquée est loin d'être délirante et pour un projet comme systemd les risques de soit le vider de son sens, soit de le rendre vraiment horrible à maintenir sont grands. La question à se poser est : est-ce que cela a un grand intérêt qu'un composant qui fait l'interface entre le noyau et l'espace utilisateur soit portable ? C'est discutable. À dire vrai, je pense que pour exploiter au mieux les possibilités de chaque système, il est plus intéressant que ce soit disjoint. Après tout, cela a été globalement le cas depuis toujours (SysV n'a jamais été sous *BSD, et même entre les différents Linux ce n'était pas la joie). Pourquoi nécessairement changer ?
De la même façon que de nombreux outils autours du noyau ne sont pas portables pour des raisons évidentes, je dirais que systemd peut en faire partie. Par contre, je pense qu'il serait intéressant de faire une API commune sur certains points dans ces systèmes. Une sorte de POSIX plus moderne sur cette question, mais laissant libre court à sa mise en œuvre.
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 2.
Rapidement.
Non. Cela veut dire prendre en compte les différente spécificités.
Oui. Ne pas offrir un match à 100% des features ? Big deal… Évidemment qu'il n'y aura pas de cgroup sous bsd, et alors est-ce que ça rend le 99% restant des autres features non pertinant ?
Scoop: systemd se comporte différemment sur différentes distros (relire ce journal…)
Oui c'est plus difficile (logique) mais c'est ce travail qui rend au final la solution plus robuste.
Oui justement car ne pas le faire c'est reporter ce coût sur l'espace utilisateur justement…
Exactement la même situation: une solution d'un vendor, non standardisée, et non libre-réutilisable tel quel (surtout que la surface système dépendant de SysV init c'est un juste un sh, ça aurait été tout à fait possible). D'autres vendors s'en inspirent mais font un truc différent. Au final c'est l'utilisateur qui trinque et doit gèrer 50 façons différentes, ce qu'il ne fait pas. évidemment. Résultat ? Fragmentation de l'éco-système et affaiblissement/mort générale. Dire que seul Linux importe, c'est reffaire la même erreure et faire preuve de trop d'optimisme, il est probable qu'il soit perdant aussi…
Oui 100% d'accord. Vu que systemd est en gros cette nouvelle API/standard, c'est dommage de ne pas avoir pris l'opportunité de le faire correctement. 95% du code de systemd n'est pas du code system dépendant hein…
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . Évalué à 8.
Tout dépend de la quantité de code en dehors du socle commun.
Si la quantité est faible et peu impactant (ne change pas l'architecture du programme) oui tu peux te permettre à gérer l'ensemble des différences.
Ici, ce n'est pas le cas. Typiquement les cgroups sont trop liés à Linux et trop au cœur de son architecture pour rendre cela élégant et simple sur d'autres systèmes.
L'architecture de systemd a été conçue pour coller au fonctionnement de Linux car c'était son but d'exploiter les possibilités du noyau que ne permet pas POSIX par exemple.
C'est loin d'être aussi trivial que tu ne le prétends, et c'est pour ça que Lennart encourage les forks du projet plutôt que de gérer la portabilité.
Non.
Si le code a des #ifdef de partout pour gérer Linux d'un côté, *BSD de l'autre, XXXX finalement, c'est difficile à maintenir et ça va créer beaucoup de bogues pour un gain discutable.
La portabilité peut rendre robuste un programme, oui, mais pas si ce programme a couplage fort avec un autre composant où l'effet est inverse.
Pas forcément, la preuve j'ai parlé d'exposer et de déterminer une API publique qui serait commune à ces projets histoire d'étendre POSIX.
Et là l'espace utilisateur n'aurait rien à secouer de la "fragmentation" de systemd en différentes versions suivant les système.
SysV, ce n'est pas que le shell, c'est tout ce qu'il y a derrière les scripts et c'est là le problème. La gestion des périphériques ? Pas standardisée. Les modules de sécurité (SELinux et autres) ? Non plus. Les cgroups ? Oublie. Etc.
Même entre les différentes distributions ce n'était pas possible d’homogénéiser les scripts proprement. Et c'était très complexe dans une même distribution d'être cohérent, certains typiquement géraient que partiellement l'existence de SELinux par exemple.
Donc homogénéiser avec d'autres systèmes qui ont des différences fondamentales sur ces questions, c'est chercher la merde pour la maintenance de ce code unique.
À t'écouter on dirait que tout l'espace utilisateur doit prendre en charge systemd d'un côté, SysV de l'autre, etc.
C'est faux… À part quelques programmes assez spécifiques, les applications et utilisateurs s'en cognent de systemd. Les applications libres communes à Linux et *BSD n'ont pas cessé le support de l'un des deux depuis, et sans devoir être modifié…
Vu que tu trouves le correctif nécessaire trivial, je t'invite à l'écrire, le maintenir et le soumettre. Lennart refuse car il sait que ce serait un gros travail. On attend ton code pour prouver le contraire.
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 3. Dernière modification le 08 juin 2016 à 17:59.
Je parlais de SYSV au moment de la "guerre" des unix… Je vois pas en quoi systemd homogénéise quoi que ce soit de ta liste, à part refuser de fonctionner si CONFIG_XYZ n'est pas activée ? D'ailleurs je ne vois pas pourqoi tu pars sur un délire d'homogénéisation. c'est par rapport à quelque chose que j'ai dite ?
On est +/- d'accord sur ce point là. Sauf que systemd a pris la place, mais oui pourqoi pas, on peut le faire au dessus de systemd même si cela ne me semble pas la manière la plus économe en labeur.
Laisse moi sourire…
Tu sais lire ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 09 juin 2016 à 19:36.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . Évalué à 2.
Ce serait bien si tu étais moins agressif…
J'ai parlé des *BSD or apparemment un seul s'est penché pour le moment sur la question. Du coup mon point de vue reste valide : il n'y a pas d'équivalent sur l'ensemble des UNIX libres (on parle de portabilité globale je crois, c'est donc important comme précision).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . Évalué à 6.
Pour moi les *BSD c'est au minimum les trois connus : FreeBSD, OpenBSD et NetBSD pour des raisons historiques, de représentativité et de domaine d'exploitation.
Que seul l'un des deux est une telle interface et qu'on ignore l'avancement des autres sur le sujet (est-ce prévu à terme ?) est selon moi problématique.
Bon, je vais te poser la question :
tu as vérifié ta source avant de balancer des conneries ?
Ton graphe, si on somme l'ensemble donne 135.3%. Il est manifestement faux (ou alors tu as un livre génial de statistique qui va expliquer ce graphe) sans compter qu'on a aucune idée de comment cela a été mesuré (l'image vient de Wikimedia, mais qui a mesuré et comment ?)
Bref, ton chiffre, c'est du pipeau.
Avant de poster, tu pourrais au moins avoir des sources correctes et les lire correctement…
Je suis sûr que les utilisateurs d'OpenBSD et de NetBSD seront ravis de voir que la portabilité ils n'y ont pas le droit.
Après si on part du principe que les *BSD ont des PdM négligeables devant Linux, on peut dire que la portabilité de systemd actuelle est suffisante, non ?
Où est la limite donc ? C'est tellement arbitraire que s'en est ridicule.
Possiblement, je ne suis pas expert en systemd et Lennart a présenté le refus par volonté d'être proche de Linux et qu'il n'a pas envie d'avoir un code trop bizarre pour gérer tout le monde. Si quelqu'un se ramène avec un code simple à gérer, je suis sûr qu'il l'acceptera. Du coup, qui est volontaire ?
J'ai cherché et je maintiens mon point de vue : deux systèmes *BSD majeurs manquent à l'appel. On est donc loin d'une solution simple aussi générique que présenté (et évident à faire).
Mais balaye devant ta porte avant d'engueuler les autres. Merci.
Je ne t'ai pas pourri, donc je ne mérite pas ce traitement.
Si tu veux, je peux te conseiller des livres sur le respect et les règles de communication. Après tout, tu as du chercher sur le sujet avant, non ?
[^] # Re: systemd, le nouveau Multics
Posté par briaeros007 . Évalué à 7.
Je t'en pris, prends sur ton temps pour faire les recherches qu'a fait Alenvers sur vos questions.
Et l'état de l'art aurait du être fait initialement par Lennart pour proposé la meilleure façon de progresser, plutôt que de faire "on faut que comme ça et on essaie pas de voir ce qui pourrait être intéressant de mutualisé, ou si c'est possible".
Tu veux dire plus ridicule qu'un type qui t'explique que l'init doit "babysitter" les processus (son terme) et les utilisateurs ?
Plus ridicule que de considérer que linux est un château et qu'il ne faut surtout pas essayer de faire quelque chose qui pourrait servir à d'autres ?
Plus ridicule de rejeter le principe de base qui a permis aux *ix de bien fonctionner jusqu'à maintenant, pour au contraire faire un gros bloatware qui veut tout gérer, et prend des décisions franchement déplacée, en considérant uniquement leurs cas d'utilisation et disant que c'est tant pis pour ceux qui n'ont pas le sien ?
Tu es sur ? ou tu crois que peut être il acceptera ?
Tu as lu ses interventions sur le problème du journal ?
Oeil, paille poutre.
[^] # Re: systemd, le nouveau Multics
Posté par Renault (site web personnel) . Évalué à 3.
La seule source qu'il a utilisé contre mes arguments est erronée, donc bon.
Je ne parle pas de l'aspect technique des cgroups où je n'ai pas pris part à cette discussion.
C'est amusant.
En quoi c'est amusant ? Un gars va dire que l'avantage du Logiciel Libre, sa force, sa raison d'être c'est de fonctionner comme un bazar où chacun apporte ce qu'il veut, quand il veut, sa pierre à l'édifice, puis un autre va dire que non le gars plutôt que de faire ainsi il aurait du faire une RFC et y travailler pendant des années avant de proposer le projet final.
Quelle est la meilleure option ? Le bazar l'emporte je pense, déjà on ne peut pas forcer Lennart de faire un travail qu'il n'a pas forcément envie de faire.
De plus, il n'a forcé personne à utiliser son programme. Les gens l'ont pris telle qu'elle, c'est donc qu'il répondait au besoin ce qui ne l'incite pas à travailler sur la question de la portabilité. C'est à ceux qui veulent un systemd portable qui doivent y réfléchir.
N'oublions pas qu'à l'origine, le noyau Linux a été conçu pour être très proche de l'architecture i386. Pourtant aujourd'hui le noyau gère bien plus d'architectures matérielles, dont des architectures sans MMU…
systemd pourrait suivre cette voie. Pourquoi pas, personnellement je n'ai rien contre. Mais quelqu'un doit s'y atteler et prouver que c'est faisable sans tout foutre en l'air. En tout cas vouloir imposer cette tâche à Lennart est un non sens.
systemd n'est pas qu'un système d'init, faudrait arrêter un jour de se fixer là dessus.
Il est libre de faire ce qu'il veut pour son projet (ou son employeur peut décider de ce qu'il veut).
Si ce logiciels est si pourri, si techniquement horrible, pourquoi toutes les distributions y passent ? Pourquoi les gens se focalisent sur sa non portabilité sur les autres systèmes si ce programme ne les intéresse pas ?
Bref, râler là dessus n'a de sens que si on considère son utilité.
Est-ce important ?
L'avantage du libre, c'est que si le projet ne va pas dans le sens voulu par ses utilisateurs, on peut le forker. Si les gens n'ont pas confiance en Lennart ou veulent la portabilité absolument, le fork pourrait avoir lieu et détrôner la branche originale du projet.
Si le correctif pour la portabilité est simple et que Lennart refuse, il n'a pas de raison que le fork ne fonctionne pas.
Si tu as fait attention, mon message précédent était largement inspirée du style de mon ancien correspondant.
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 3.
Dans ce cas la pourquoi ne pas separer de facon bien clair le systeme d'init et le reste du merdier? En gros prendre la philosophie Unix: KISS?
Parceque a partir du moment ou l'on critique le comportement d'un logiciel la reponse est "mais ce logiciel ne fait pas que ca". Il y a clairement un probleme.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
C'est systemd le projet, pas systemd le logiciel.
systemd une fois compilé donne une 60aine de binaires.
Heureusement que c'est pas tout en un !!
Ça respecte bien la philosophie KISS, quand on s'y intéresse un minimum.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 3.
C'est probablement la reponse la plus stupide que tu puisses donner! "Je compile un logiciel qui donne plein de binaires differents donc il est FORCEMENT KISS".
Franchement tu dois pouvoir faire mieux.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
L'important à retenir, c'est que ce n'est pas un seul logiciel, mais plusieurs travaillant ensemble.
Chacun s'occupe d'une seule chose (le boot dans son ensemble, consulter le journal, donner la possibilité de modifier le nom de la machine, etc…).
Mais si tu t'intéressais à systemd un minimum au lieu de troller pour troller, tu saurais déjà tout ça.
Stupide troll.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 3.
Si tout est bien separe l'init et tout le merdie qui fait polemique et bien il suffit juste de separer les deux et faire deux projets disctincts et comme tu suis bien tout ce qui se passe sous systemd tu sais a quel point c'est evident de faire cela…
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -5.
1.Ca n'a aucun intérêt.
2.Tu mélanges tout.
3.Y'en a marre.
4.Ferme-la par pitié.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -1.
Pourquoi faire ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -2.
non mais vraiment : pourquoi faire ? (3ème)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 2.
Bon, je vais commencer par l'évident : demander 3 fois la même chose, toujours sur un ton méprisant, ce n'est pas pertinent. Tant d'animosité pour une simple question technique n'est pas nécessaire.
Ensuite pour répondre à la question, le principe même de séparer les systèmes en plein de programmes est une méthode de conception que l'on connait bien depuis facilement les années 70 : ça permet de simplifier les programmes. Le but de séparer l'init de tout le reste est là encore de simplifier les programmes. Un seul bloc de code réunissant des dizaines de bibliothèques et gérant des dizaines de choses différentes est bien plus complexe que de séparer tout ceci en programmes indépendants (oui, avoir juste plein de binaires ne veut pas dire que c'est simple s'ils sont tous dépendants les uns des autres).
Donc là le principe de séparer le système d'init du reste des projets de systemd a pour but une simplification : tu vois le code de l'init, t'as pas besoin de lire un bouquin sur les rouages du reste du système pour le comprendre.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -2.
ca tombe bien, c'est ce qui est fait dans systemd. :)
Mais là on parle de cisailler inutilement dans les dépendances (udev & co.) tout ça pour faire de l'over-engineering. Et la "simplification" devient une malédiction…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -2.
Ah, le bon vieux "je suis pas d'accord, mais j'ai aucun argument, je vais donc moinsser".
Un classique… pour les lâches.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 3.
Je pense surtout que tu ne veux pas essayer de comprendre, donc j'arrête la conversation là.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
je pense surtout que vous ne comprenez rien à systemd, et ce que vous lui reprochez tien du fantasme.
Il est modulaire : vous ne voulez pas le voir.
Il a besoin de udev & co. : ça vous horripile.
pourquoi on devrait séparer systemd de ses dépendances fortes : vous ne voulez pas répondre.
je vous laisse dans vos trolls de bas étage.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 2.
Desole cela va te choquer probablement mais tes interlocuteurs ne sont pas tous aussi idiot que moi et donc certains comprennent tres tres tres bien ce qu'est systemd. Ce qui est dommage c'est que les devs de systemd ne fassent pas l'inverse et comprenne les besoins des utilisateurs et cassent de facon reguliere l'experience utilisateur (maintenant tu peux aussi pretendre que Linus Torvalds est un idiot puisqu'il a deja gueule sur eux a ce propos).
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
Faire en sorte que les processus ne faisant plus partie d'une session se ferment comme ils le devraient, plutôt que de laisser cette tâche à l'utilisateur, je vois pas en quoi ça casse l'expérience utilisateur.
Ça l'améliore même. Ça évite une "fuite mémoire" (pour ainsi dire), et du gaspillage de ressources.
Et la proposition inverse, c'est à dire attendre de chaque programme imaginable qu'il ait le bon comportement, est clairement irréaliste.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 1.
Deja repondu a cela. Parceque le probleme c'est Gnome et le precedent bebe du papa de systemd, pulseaudio. Ce qui au passage pourrait m'inquieter profondement sur la qualite reel de systemd… mais heureusement ce n'est pas le cas. Les process KDE se ferme nickel , de meme pour E ou tout les autres desktop (non GTK/Gnome).
Par contre cela me casse et pas que moi mon utilisation quotidienne de screen, enfin si je n'avais pas remis la configuration comme il se doit et celle attendu.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
Source ?
Ah bon ? Chez moi il a fallu la dernière version de systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 1. Dernière modification le 20 juin 2016 à 12:56.
source
Source?
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0. Dernière modification le 20 juin 2016 à 13:02.
Ce n'est pas une source. Ce sont les sources de PulseAudio.
Donc tu fais du FUD. Bravo.
Moi. Et d'autres : http://linuxfr.org/nodes/109165/comments/1660050
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 3. Dernière modification le 20 juin 2016 à 14:06.
Man humour pour les source PA.
Sinon tu pretends donc que tu n'avais aucun processus qui tournait apres un logout? Desole mais la je suis extremement sceptique sur le sujet.
https://bugzilla.redhat.com/show_bug.cgi?id=555828
That's my take on it as well. Basically, poorly written stuff like PulseAudio doesn't properly shut down when you log off. The solution, obviously, is to break the normal behavior of Linux so that some moronic sound daemon properly shuts down when you log out. It's like watching a train wreck in slow motion.
Et pour ton probleme KDE change de distribution car chez moi ca marche. (Tu vois ton argument debile il se retourne contre toi). Mais j'attend des preuves de personne se servant de KDE et pas de Gnome car Briaros007 est passe a Gnome aux derenieres nouvelles.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -1.
Ah ouais, super la source. Des anti-PA… Source meilleure nécessaire.
Tu racontes des conneries. Désolé, mais c'est vrai.
Le fait est qu'avant j'avais plein de processus KDE qui restaient, et une fois systemd à jour : plus rien.
Merci qui ? Merci systemd !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 2. Dernière modification le 21 juin 2016 à 11:02.
Donc TA source, un utilisateur de Gnome, est donc meilleur que la mienne. Et si l'on voit les problemes d'un logiciel c'est etre anti-le logiciel amusant donc tu es un anti-KDE, un anti-linux etc. Et le bugzilla de Redhat ce sont des anti-systemd et anti-PA aussi? Allez juste pour te faire plaisir (mais bon ca doit encore etre un mechant monsieur qui aime pas les logiciels fantastique de Pottering) voici un autre lien:
But I really don't
see what the benefit of this change is, apart from maybe cleaning up
some stray gconf and pulseaudio processes from the list of processes.
Un autre encore:
https://bugs.freedesktop.org/show_bug.cgi?id=94508#c7
et un autre encore:
In summary, in the attachment we uploaded to Gentoo bugzilla, https://577416.bugs.gentoo.org/attachment.cgi?id=428490 ,you can see the systemd-cgls output just after logging out from a Gnome 3.18 session. With user-session disabled (or dbus-1.8) all processes end up dying after logout, but with user-session enabled, they (gvfs, pulseaudio, tracker, dconf, goa, evolution-*, mission-control…) are left running forever
Amusant comme quoi on parle TOUJOURS de Gnome et de PA mais jamais de KDE…
Donc moi j'ai trois sources differentes dont des rapports de bugs ouvert ou "won't fixed" et toi tu as quoi en comparaison?
Franchement tu te surpasses dans les poncifs et les cliches… sans compter le fait de demander quelque choses et de balayer la reponse sous la moquette parceque cela te gene!
Question tu utilises quoi au quotidien? KDE ou Gnome? Et tu n'as jamais eu de process gvfs qui traine apres un logout de Gnome? Tu dois bien etre le seul alors…
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 1.
s/trois/cinq/
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 2.
La lachete c'est plus d'exiger que les gens se taisent a mon avis … et de se plaindre apres de cela pour les faire passer pour les "mechants".
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
La lâcheté, c'est de ne pas admettre qu'on a tort, qu'on fait du FUD, et qu'on ne sait pas du tout de quoi on parle.
Comme toi. Le
lâchetroll suprême."Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 1.
C'est amusant moi qui croyait que les insultes et la violence etait l'arme des faibles et des laches… me serais-je trompe? :D
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
Bah non, vu que c'est tes armes préférées depuis le début.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 0.
Source? :D
(PS: celui qui exige aux autres de se taire ce n'est pas Albert_…)
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
Tu me l'a appris. :-)
Et quand on regarde ton lien, on voit bien que le bug est invalide… Bref, manipulation, tout ça … Du grand Albert !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 2.
Je suis impressionné par le manque d'honnêteté et la mauvaise fois. Enfin vu ton comportement cela n'est pas bien surprenant. Bon courage si tu te comportés dans la vraie vie de cette façon la tu dois être un être charmant à côtoyer…
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 2.
Premierement il y a 5 liens vers des bugs report avec les status suivant.
Status: CLOSED WONTFIX
Status: NEW
issue: open
Severity: normal
Ton niveau d'anglais laisse a desirer… car il n'y a aucun des liens pointant sur des bugs report considere comme "invalid"!
Juste pour ta culture on lit un bug report en ENTIER:
En resume bug trop vieux mais absolument pas invalide.
Deuxiemement, tu en as vraiment pas assez d'insulter et de faire des attaques ad hominem envers les personnes qui ne sont pas d'accord avec toi? Tu trouves vraiment cela constructif? Franchement grandit un peu s'il te plait. Je sais bien que sur internet nobody knows you're a dog mais franchement cela devient penible ce genre de personne sur ce site.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -1.
Ouais et quand on les lit bien, on voit que les statuts "WONTFIX" sont justifiés et pas parce que PA "c'est un daemon audio mongolien". Comme quoi…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 4.
Aller je vais etre gentil on va enlever ce bug report donc il n'en reste que 3 (je me suis trompe au dessus c'etait 5 sources mais 4 bug reports) ce qui fait:
3 bugs report disant que le comportement debile mise en place par defaut pour systemd a ete fait a cause de Gnome et de PA contre … 0 bug report de ton cote disant que c'est la faute de KDE.
Donc tu n'as aucune source plus fiable que un utilisateur de Gnome (briaros0007) et toi (et on ne sait pas ce que tu utilises…).
Mais tu n'es absolument pas de mauvaise foi…
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -1. Dernière modification le 22 juin 2016 à 10:59.
Je doute fortement que ce comportement (très bon et logique) ait été mis en place pour "corriger" PA (qui n'a aucun problème). C'est ridicule.
Tes sources sont plus que biaisés, tandis que moi j'ai google qui m'ndique plein de problèmes avec KDE au logout (PAF PREMIER RESULTAT !)… Bref, tchao !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 2.
Et le fait qu'ils aient fait un patch pour réparer ça sans inclure de solution à base de systemd ne te choque pas ? Ce n'était pourtant pas la solution adaptée au problème selon toi ? Les développeurs de KDE ne semblent pas le voir ainsi, contrairement à ce que tu prétends.
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 2. Dernière modification le 22 juin 2016 à 12:27.
Certaines personnes croient toujours que la terre est plate, cela ne veut pas dire que cela soit la verite…
De plus tu colles un lien sans lire ce qu'il y a dedans… Regarde donc le status. Comme je suis gentil:
Status RESOLVED FIXED
Traduction:
Status: Resolu fixe
Les devs KDE ont donc corrige le probleme! Different de "Won't fixed" de celui de gnome n'est ce pas.
Je n'ai jamais dit que cela n'a pas ete le cas avant, je dis juste que en tant que reel utilisateur de KDE (c'est mon bureau principal) cela n'existe plus.
Franchement cela ne te gene pas, intellectuellement parlant, que au lieu de corriger les causes d'un probleme on utilise une arme atomique?
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -2. Dernière modification le 22 juin 2016 à 12:53.
Non, car c'est le boulot d'un gestionnaire de sssions de base de fermer les programmes lors du logout (et pour ceux qui sont bien faits : avec un timeout / confirmation si certains programmes ne veulent pas se fermer et l'ont explicitement demandé au gestionnaire. Exemple : gravure en cours).
Qu'attendre que la cause du problème soit réglée dans chaque programme est clairement irréalisable. Tu auras toujours tôt ou tard un programme mal codé.
Que corriger à chaque fois le problème dans chaque programme est contre-productif et pas très intéressant.
Que de toutes façons, on peut désactiver l'option, ou utiliser une autre solution pour avoir des daemons/programmes qui restent.
Merci, je l'ai vu. Mais le truc, c'est qu'on s'en branle le coquillard avec une pelle à tarte tout en écoutant du George Brassens et en appelant Tata pour qu'elle vienne manger. Oui, à ce point.
Car le fait que le problème a existé. Qu'il n'y a aucune raison pour qu'on nouveau programme/daemon KDE soit de nouveau mal codé et ait ce problème. Ou que le gestionnaire de session KDE (si c'est lui qui s'en occupe) exhibe de nouveau ce problème.
D'ailleurs, y'a pas que Plasma 5 qui a eu énormément de problèmes (c'est quoi, la 3ème réécriture complète de KDE avec des problèmes partout ? Et souvent les mêmes ?), d'ailleurs…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 5.
Autant utiliser le power off dans ce cas… Cela revient plus a detruire la terre entiere mais bon au moins tu es sur que plus personne ne tourne en arriere…
Donc tu es bien de mauvaise foi.
Pourquoi change tu de troll? KDE a mange ton chat? Parceque le rapport avec le schmiblick est … faible on va dire.
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 3. Dernière modification le 22 juin 2016 à 13:04.
Le probleme vient des recent changement dans dbus, du coup cela fait une grosse merde pour nettoyer les process, en particulier Gnome et PA comme DECRIT dans les rapports de bug, dans ces memes rapport il n'est JAMAIS mention de KDE. La raison peut etre que personne n'utilise KDE, que personne n'utilise KDE et le dbus en question, que je n'au pas trouve les memes bugs relatif a KDE, que KDE ne fait pas comme Gnome et ne laisse plus de process derriere lui, je ne sais pas et je m'en fous. Ici j'ai:
dbus 1.10.8
systemd 230 (avec l'option enleve)
kde 16.04.2
kde4 4.14.3
kde5 5.6.5
Oui j'ai un melange de kde4 et kde5 car il y a des trucs de kde4 pas encore porte sur kde5. Et je n'ai pas de process KDE qui reste en me delogant. C'est un fait chez moi!
La solution donne est (voir lient ci dessous):
dbus-1.10 (1.10.6 and 1.0.8 tries) breaks gnome 3.18 logout leaving running processes et https://bugzilla.gnome.org/show_bug.cgi?id=764146
Maintenant tu peux donc douter que ce changement soit fait pour gnome et PA mais bon les rapports de bugs disent pourtant que c'est le cas. La cause direct vient des changement de dbus mais les consequences sont dans Gnome et PA niveau utilisateurs. Apres encore une fois, certaines personne pense que la terre est plate…
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
C'est pas du tout ce que je lis. Franchement, ta vue baisse.
Et y'en a qui croient qu'un problème qui a été résolu X fois avant d'être résolu une fois pour toutes pour systemd concerne un gestionnaire de son qui n'a aucun problème pour se fermer (et oui, c'est écrit dans le rapport de bug. Mais je comprends, tu as une dent contre PA donc tu fais tout pour le mettre en cause, quitte à tourner au ridicule).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 3.
In summary, in the attachment we uploaded to Gentoo bugzilla, https://577416.bugs.gentoo.org/attachment.cgi?id=428490 ,you can see the systemd-cgls output just after logging out from a Gnome 3.18 session. With user-session disabled (or dbus-1.8) all processes end up dying after logout, but with user-session enabled, they (gvfs, pulseaudio, tracker, dconf, goa, evolution-*, mission-control…) are left running forever
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -1.
Oui, ça ne parle pas que de PA, et ça parle de la désactivation de user-session. Quand c'est désactivé, les processus (dont PA), restent.
Rien à voir avec PA, donc.
Je sais bien que tu prends Lennart pour une buse, mais réussir à faire en sorte qu'un programme s'arrête, c'est pas un exploit… Pour personne…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 4. Dernière modification le 22 juin 2016 à 14:04.
Logique xcomcmdr: ce n'est pas que de PA donc PA n'a pas de probleme.
Enfin bon on arrete les conneries tu n'as trolle depuis le depart sans avoir fait la moindre recherche, tu as insulte, utilise l'homme de paille, changer le troll de direction (dernierement vers KDE5) etc.
Bye bye tu es trop poilu pour moi maintenant.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à -2.
Ben oui. C'est marqué noir sur blanc. PA est juste mentionné dans les process qui restent ou non selon si user-session est inactif ou non. À aucun moment il n'est mis en cause.
Même si que lui était mentionné, on voit bien que si user-session est actif il se ferme à la fermeture, comme tout le monde. Donc aucun problème avec PA.
Juste de l'anglais de base…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
Ben oui. C'est marqué noir sur blanc. PA est juste mentionné dans les process qui restent ou non selon si user-session est inactif ou non. À aucun moment il n'est mis en cause.
Même si que lui était mentionné, on voit bien que si user-session est actif il se ferme à la fermeture, comme tout le monde. Donc aucun problème avec PA.
Ce bug ne parle pas du tout de PA en fait. Mais comme il est mentionné, tu as été induit en erreur.
Relis-le bien et tu verras la lumière.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 3.
Et quand on lit ce blog on s'apercoit que l'equipe de systemd a cree le probleme dont la solution a ete fourni par systemd…
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 2.
Ou pas. C'est juste un remplacement facultatif à D-Bus et 100% compatible…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 1.
Source.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 2.
comique de repetition? mais que copies tu cela mal…
[^] # Re: systemd, le nouveau Multics
Posté par Sacha Trémoureux (site web personnel) . Évalué à 6.
Hey, aucun de vous deux n'arrivera à convaincre l'autre hein.
[^] # Re: systemd, le nouveau Multics
Posté par Albert_ . Évalué à 1.
Donc je pense que je ne vais pas continuer cette discussion que tu fais degenerer en troll de bas etage. Tu as donc ta reponse maintenant a:
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 1. Dernière modification le 08 juin 2016 à 11:11.
S'assurer qu'un logiciel soit multiplateforme est une charge de maintenance logiciel en plus, tout à fait.
Je comprends très bien qu'il considère ne pas avoir une force de travail suffisante pour cette charge additionnelle.
Et il n'est pas du tout hostile à l'idée d'un fork ou d'une tierce personne maintenant des patchs garantissant la compatibilité avec *BSD (lequel BSD, d'ailleurs ?)
Donc cette "hostilité" dont tu parles est pour le moins subjective.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 2.
Maintenir des patchs ? Sérieusement… Surtout que si chaque système doit le faire et au final on se retrouve avec 20 forks, ça n'est pas vraiment l'objectif. Une charge de travail supplémentaire ? On lui a jamais demandé de faire le travail, juste d'accepter le travail d'autres, de le fédérer afin que tout le monde y gagne et que la qualité du code commun augmente.
[^] # Re: systemd, le nouveau Multics
Posté par xcomcmdr . Évalué à 0.
Et ça reste du travail. C'est pas juste "j'intègre, ça compile, c'est bon".
Il faut :
- intégrer les patchs tiers
- tester, voir si le comportement attendu est là
- corriger éventuellement
- documenter
- qui va maintenir tout ça sur la durée ?
Franchement, c'est beaucoup pour pas grand chose.
Et puis, tu lui demandes de faire ça gratos ? Tu veux 100 balles et 1 mars aussi ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd, le nouveau Multics
Posté par benja . Évalué à 2. Dernière modification le 08 juin 2016 à 17:39.
Écoutes ça n'est pas uniquement moi qui le dit. Bénéfice > coût, si tu ne me crois pas, ben tant pis. Pose la question à des personnes qui maintiennent un logiciel d'envergure et portable.
T'inquiètes pas, s'il n'y a personne qui maintient/utilise, ben on retire le support. c'est aussi simple que ça… Juste laisser la possibilité.
(le reste de tes arguments convient à l'égard de toute contribution, pas uniquement de type "port"… bref ça pue la mauvaise foie).
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à 5.
Non, il faut savoir que c'est pas utilisé, il faut savoir à partir de quand tu le vire, gérer les haters qui vont te dire que tu es un tirant parce que tu es un méchant contre le système en question, etc Intégrer du code ça n'est pas aussi évident.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par briaeros007 . Évalué à 3.
Visiblement, même quand c'est utilisé, ça ne gêne pas Lennart de virer :D (je sais c'était facile).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 1.
C'est qui Sulman, un mec qui compte chez FreeBSD? :p
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 10. Dernière modification le 05 juin 2016 à 15:55.
Les gens de BSD n'en veulent pas du tout de systemd, mais suite à des problèmes de compatibilité dans des logiciels - puisqu'ils sont tous modifiés pour coller à la vision du monde de systemd - ils souhaitent développer une API de compatibilité. C'est uniquement pour ne pas avoir à redévelopper des outils qu'ils utilisent depuis toujours. Ça s'arrête là.
Et les gens qui n'apprécient pas systemd sont si virulents c'est aussi en partie parce qu'il modifie le comportement de plein de programmes qui fonctionnaient et étaient utilisés par différents systèmes. Du coup même si on n'a pas systemd sur sa machine, on est touché par les modifications.
[^] # Re: systemd, le nouveau Multics
Posté par gnumdk (site web personnel) . Évalué à 0.
C'est du logiciel libre, les devs de ces programmes font ce qu'ils veulent… Si les modification ne plaisent pas, il suffit de forker…
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 1.
Oui, les développeurs font ce qu'ils veulent. Ai-je dis le contraire ?
Il suffit de forker, oui, c'est bien ce qui est fait et c'est bel et bien ce dont nous parlons. Cela ne va pas sans peine non plus, se mettre à maintenir plus de programmes sous prétexte que les développeurs en upstream cassent la compatibilité (ou arrêtent de maintenir le programme) reste une charge supplémentaire, donc les réactions parfois exaspérées des mainteneurs est légitime. Donc oui, le fork est une possibilité, mais c'est aussi un peu facile de juste s'en remettre à ça pour dégager une responsabilité.
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à 2.
Une opportunité ! On va pouvoir avoir des logiciels qui tirent partie des spécificités de chaque plateforme plus facilement comme seccomp/tame/capsicum par exemple. Ne plus avoir à suivre le développement de linux et avoir une couche de compatibilité avec le noyau linux c'est aussi utile pour FreeBSD.
Bref arrêter de se leurrer avec une compatibilité qui était déjà un peu bralante pour hacter que ce sont des plateformes différentes qui s'utilisent différemment les unes des autres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par barmic . Évalué à 3.
Euh… il est impossible de patcher ces logiciels pour qu'ils soient compiler avec ou sans systemd ? Tout comme on indique de les compiler pour linux ou pour je ne sais quelle BSD pour bénéficier de seccomp, de tame ou de capsicum. C'est tout de même pas la première fois qu'il y a des différences entre ces plateformes et une partie de ces logiciels visent aussi Windows. On est entrain de dire que systemd a un fonctionnement qui casse plus de chose que windows ? Ou alors tous ces logiciels sont maintenu soit par des incompétents soit par des gens qui n'acceptent pas des patchs pour compatibilité avec autre chose que du linux/systemd ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, le nouveau Multics
Posté par karchnu . Évalué à 4.
La partie windows n'est simplement en rien compatible avec les BSD, en revanche la partie linux ne nécessite pas forcément de gros changements pour fonctionner puisque le fonctionnement du système a de forte similitudes par rapport aux BSD, du moins jusqu'à maintenant. Puisque tout passe à systemd, les développeurs principaux ne gèrent plus l'ancien fonctionnement, et donc il faut faire l'effort de créer une branche à part. Ça va à l'encontre de la philosophie « on ne répare pas si ce n'est pas cassé ». C'est plus ou moins ce qu'il s'est passé pour dbus.
Je ne suis pas expert, faut demander aux développeurs pour en savoir plus et voir d'autres exemples.
# Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par gipoisson . Évalué à 2.
Titre provocateur certes mais à la lecture des commentaires, je n'ai pas pu m'empêcher de penser que Fedora ne serait pas loin d'être une valeur aberrante si on tentait d’échantillonner sur les distributions des commentateurs sur ce fil. Pourquoi penser ça ?
Il est bien sûr flagrant que la discussion est riche, qu'il y a de riches propositions de configurations/comportements de systemd et des distributions qui en font usage. Cependant, ça m'a personnellement étonné de constater que l'endroit où s'est passé « la discussion upstream »1 n'est mentionné que très indirectement (voir le point 3 ici-haut) alors que bien de « discussions downstream » sont franchement reprises.
En parcourant ce fil1, on se rend compte que les commentateurs sont, non seulement des mainteneurs ou des développeurs de systemd, mais aussi maintes contributeurs à Linux soi-même y interviennent. Dans ce fil-là se trouvaient déjà la plupart des choses écrites dans ce fil-ci. Un exemple parmi tant d'autres : la notion intéressante de « controlling terminal » qui semble ne pas encore être consensuelle ici a déjà été débattue.
Bref, il me semblait être de notoriété publique que les versions de développement de systemd sont testées par leurs propres développeurs dans Fedora. En complément des mailing lists d'autres distributions, il irait de soi alors de jeter un coup d'œil à celles de Fedora si on cherchait à connaître le pourquoi du comment d'un choix fait dans systemd : la probabilité est élevée de lire dans ces dernières des avis de première main.
Ironie de l'histoire, un participant à la discussion upstream a annoncé la naissance d'un fil sur les listes Debian comme si c'était le moment idoine de servir du pop corn.
URL pour “systemd 230 change - KillUserProcesses defaults to yes” : https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/ ↩
[^] # Re: Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par benja . Évalué à 4.
Ouaw super merci pour le lien (comme quoi il n'y a pas que sur debian-devel qu'on a besoin de popcorn). Une petite perle, de DJ Delorie (pour ceux qui ne savent pas, le gars à porté gcc sur DOS parmis probablement plein d'autres trucs de dingues. Je ne résiste pas à la copier ici :p
(La réponse de l'intéressé ne vaut probablement pas la peine que je la recopie ici…)
[^] # Re: Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par Sufflope (site web personnel) . Évalué à 2.
Le mec peut bien avoir ouvert la Mer Rouge en 1970 que j'en aurais pas grand chose à faire de ses avis sur l'informatique des années 2010. En plus depuis quand un développeur qui aime s'amuser avec des défis de code inutiles (ouais parce que gcc sur DOS pardon mais faut avoir du temps libre à gâcher…) est forcément un bon adminsys ?
Oui bien sûr c'est marrant les réfractaires ont toujours "dû faire des contorsions horribles pour faire marcher le moindre truc", mais c'est marrant ils montrent jamais quoi.
[^] # Re: Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par karchnu . Évalué à 5. Dernière modification le 10 juin 2016 à 21:02.
Devoir intégrer du code à tmux parce que systemd, c'est normal ça ? Pas besoin d'aller chercher bien loin. Les programmes gérés par systemd doivent être modifiés, soit pour gérer les dépendances entre les process, soit pour [raison aléatoire]. Les plus réfractaires diront que le code est horrible, mais surtout il y a besoin de code, c'est beaucoup plus ça le problème : du code spécifique à systemd dans des programmes.
[^] # Re: Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par barmic . Évalué à 2.
Non il y a besoin de configuration dans systemd. Ça fait une semaine que c'est dit.
Ce dont il est question ici c'est d'un bug dans Debian dont le boulot est d'intégrer des logiciels et qui fournit 2 logiciels qui ne s'entendent pas bien. Ça fait 25 ans que Debian fait ça. Faudrait penser à se détendre
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par gipoisson . Évalué à 2.
En l'occurrence, ce qui était proposé pour tmux était plutôt du code spécifique à PAM, histoire de notifier le gestionnaire de session que le processus tmux pourrait être détaché de la session dans laquelle il a été lancé. Le mainteneur de tmux a refusé soit d'écrire pareil code soit de recevoir des patches implémentant ce comportement. systemd propose des possibilités de faire avec le statu quo tout en nettoyant le système après la fermeture des sessions. Mais dans la discussion sur Fedora-devel, la notion de « logout » n'a pas été explicitée malgré au moins deux demandes dans ce sens ; il paraît sous-entendu par les mainteneurs de systemd que logout est à prendre dans le sens de loginctl bien que d'autres types de logout soient envisageables, comme souligné dans différents fils sur le sujet.
Entretemps, Zbigniew Jędrzejewski-Szmek a promis de chercher un moyen de patcher systemd pour qu'il laisse screen en exécution même après un logout et sans passer par systemd-run.
[^] # Re: Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par Sufflope (site web personnel) . Évalué à -1.
Oh le joli mélange.
Bah, pour utiliser ses spécificités, oui. Sinon tu les utilises pas (tmux sera fermé comme toutes les autres applis), tu les utilises sans modifier tmux (tu le lances avec systemd-run), tu les utilises pas en changeant la config, tu les utilises pas en n'utilisant pas systemd… pfiou tous ces choix.
N'importe quoi.
Ou alors, à la limite, comme systemd, par sa nature, offre de bien plus fortes garanties sur le fait qu'un process soit démarré ou pas, la modif qu'on peut faire c'est virer le code qui vérifie à base d'heuristiques que le service précédent a été démarré ou pas. Quelle tristesse !
Le FUD anti-systemd habituel. Peu importe pourquoi, comment : systemd VA te faire du mal.
[^] # Re: Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par gipoisson . Évalué à 4.
Les discussions en rapport avec systemd ont une certaine tendance à déchaîner les passions. Si, disons dans une décennie pour prendre du recul, des anthropologues/sociologues se penchent sur les mécanismes en jeu pendant la naissance/(dé)croissance de systemd, plusieurs leçons pourront émerger à la place du côté popcorn actuel.
À noter que sur LWN aussi, les débats semblent avoir dégénéré : 226 commentaires au moment où ce message est rédigé ; quand l'embargo sur l'article sera levé, on verra sur quoi ça ferraillait.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.