Short story short:
J'ai installé systemd et j'aime ça, mais je me garde quand même une slackware avec un init sysV.
Long story:
J'utilise linux depuis longtemps, j'utilise un peu du Mac aussi. J'aimais beaucoup sous linux sa hackabilité: tout est documenté, tout est dans des fichiers textes, on peut modifier/hacker/tweaker simplement n'importe quelle partie du système et c'est génial.
Mais commençons par parler du Mac:
Sous mac, ça marche bien (on a un terminal, bash, ssh, vi et à peu près tous les langages de prog qu'on veut). Sous mac, ce qui m'ennuie, c'est le côté un peu obscur du machin. Alors, oui, certes on a un peu de documentation sur launchd (un genre de mécanisme d'init), mais bon, globalement j'aime pas trop toucher là dedans. Ca doit être le côté obscur. J'ai vu des tueurs lancer des commandes launchd de ouf', mais bon, je le laisse juste comme ça, ça boote et puis je laisse faire. Je perd en connaissance du système ce que je gagne en temps d'admin. Mébon, tant que ça marche et que je peux geeker dans un Terminal, hein..
Debian: l'obscurantisme au boot
Ensuite, sous debian, l'init commençait à me peser un peu. C'était un plat de spaghettis abominables, à grand renfort de liens symboliques de script shells difficiles à suivre et de programmes spécifiques (start-stop-daemon, update_rc.d etc..). Redhat, pareil.
slackware le KISS dans sa splendeur
Sous slackware, par contre, c'est le bonheur à hacker. Tout est simple (trop disent les contradicteurs), mais c'est juste bien. On fait ce qu'on veut, comme on veut. Un script de démarrage?
if [ -x /etc/rc.d/rc.serviceXXX ]; then
. /etc/rc.d/rc.serviceXXX start
fi
ajouter un service demande 15s, l'ajouter au boot pareil, le modifier tout aussi vite: pas de fonctions compliquées, juste un case start|stop|restart et vla.
Le drame: j'ai installé Jessie
Et puis bon, un jour, j'ai craqué, j'ai installé une debian Jessie, j'ai pas fait attention, et paf me voilà avec systemd. Déjà, première constatation: ça pousse. Ma racine est chiffrée, donc le temps kernel est long, mais pour l'userland, zbam:
$ systemd-analyze
Startup finished in 11.472s (kernel) + 2.104s (userspace) = 13.577s
J'ai joué avec quelques commandes systemctl, et bon j'ai eu les infos que je souhaitais. J'ai installé un programme qui a fait un service start à la fin de l'install, qui n'a pas plu à systemd. J'ai fait un enable service et c'est passé. J'ai tapé deux trois commandes status, j'ai un affichage coloré qui tient bien dans mon terminal. Je ne veux toucher à rien sur cette distro, donc je laisse comme c'est.
Moralité de l'histoire
Avant debian, c'était chiant de hacker les scripts d'init, maintenant c'est obscur mais je sais que je n'y toucherai pas plus qu'avant. Ca me fait penser au mac: on a un truc tout intégré qui "juste marche" et qui fait ce qui est censé faire. On ouvre pas le capot, on touche à rien, et on bosse (terminal, vi, ssh, prog, etc..)
Sur ma slack qui me sert de machine principale/test/dev je laisse init sysV car je sais comment elle boote, que je teste des combinaisons de noyaux/initrd/lancements démons etc.. et que j'ai besoin de garder la main dessus.
Je pense que les anti-systemd sont ceux qui hackent (ou ont hacké) le système de boot. C'est lumineusement simple, basé sur du shell, et le fait de passer par un truc binaire carré fait penser à la base de registre de microsoft: bien intégré, rapide mais obscur. Et comme systemd vient de partout, bah il faut le manger quand même, envie ou pas.
Les zamoureux de systemd ont du regarder vaguement un jour l'init, voient systemd avec des fichiers .unit tout basiques et disent que "ça marche, c'est rapide, et ça fait le job". Pourquoi pas.
Et vous?
Mais entre les deux, dans quel camp êtes-vous? Hackabilité max ou intégration max?
# Sur Mon Raspberry Pi
Posté par goernil . Évalué à 10.
Sur mon rasberry pi, j'ai une Arch linux, donc par défaut j'ai systemd. Je voulais qu'au boot mpd soit lancé de manière automatique. En consultant le wiki d'arch, ça ma pris 1m30 en créant le fichier .service, puis le lancer et l'activer avec un systemctl.
Donc je dirais Hackabilité max avec intégration poussée.
[^] # Re: Sur Mon Raspberry Pi
Posté par BAud (site web personnel) . Évalué à 7.
avec un peu d'élan je dois encore atteindre les 6m30, en moins de 10 s (blague SI inside)
# Et moi
Posté par CHP . Évalué à 10.
Je suis dans le camp de ceux qui en ont marre des trolls sur systemd…
Y'a pas un anti-avortement ou un motard dans le coin, pour changer ?
[^] # Re: Et moi
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
un motard bas du front pour tous ?
"La première sécurité est la liberté"
[^] # Re: Et moi
Posté par cram51 . Évalué à 4.
Comme disait le sage :
vieux motard que jamais ….
[^] # Re: Et moi
Posté par BAud (site web personnel) . Évalué à 5.
partir, c'est pourrir un pneu…
[^] # Re: Et moi
Posté par Maxime (site web personnel) . Évalué à 7.
Pourquoi "un" ? Y'en a marre du sexisme sur Linuxfr.
Avec plaisir.
[^] # Re: Et moi
Posté par AgentSteel (site web personnel) . Évalué à 10.
Bof, la motarde nous monte au nez.
[^] # Re: Et moi
Posté par Maclag . Évalué à 7.
Moi j'ai de moins en moins de temps à passer sur linuxfr alors je préfèrerais qu'on soit efficace:
Est-ce qu'il y aurait ici une motarde anti-avortement mais qui se considère quand même féministe et qui a fait la manif pour tous?
[^] # Re: Et moi
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Et est-ce qu'elle doit utiliser systemd, ou est-ce que si elle utilise sysV init on la prend quand même ?
[^] # Re: Et moi
Posté par Michaël (site web personnel) . Évalué à 2.
Elle peut utiliser sysV à condition d'avoir écrit un port en Elisp de
systemd, qui permettrait à Emacs de devenir un composant proche du noyau indispensable à tout système GNU/Linux ou DebianBSD.# Ah ah
Posté par barmic . Évalué à 6.
En fait ce sont des xénophobes, ils ont peur de ce qu'ils ne connaissent pas. Même si on adresse à longueur de troll chaque cas d'usage qui deviendrait impossible avec systemd.
Ou alors c'est ceux qui ont eu autre chose à faire que d'ajouter un petit script vite fais et qui ont galéré, ils sont donc content de pouvoir faire ce qui était impossible ou proche de l'impossible avec sysv ou rc.d.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ah ah
Posté par jadfa . Évalué à -4.
Ouais sans doute parce que moi, rien que d'essayer de passer mon rc.local sous systemd, ça merde grave.
Faut que je voie à faire plus compliqué…du coup j'aimerais peut-être systemd…
PS: excuse moi Michel j'ai corrigé la faute de conjugaison dans ma citation
PS2: et si j'en ai fait moi même n'hésitez pas à me reprendre
PS3: jamais essayé, pas plus que les XBox.
[^] # Re: Ah ah
Posté par Misc (site web personnel) . Évalué à 6.
Marrant, moi, j'ai un service de base qui va lancer /etc/rc.d/rc.local start. Donc j'aurais tendance à dire que ça marche de base.
( l'unité, c'est /usr/lib/systemd/system/rc-local.service )
[^] # Re: Ah ah
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 25 septembre 2014 à 10:05.
Ce n'est pas fournit avec systemd mais chez moi ça ressemble à ça (basé sur tlp.service)
gnumdk@archlaptop:~$ cat /etc/systemd/system/rclocal.service
[Unit]
Description=System startup/shutdown
After=multi-user.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/rc.local
[Install]
WantedBy=multi-user.target
[^] # Re: Ah ah
Posté par Moonz . Évalué à 3.
La dernière fois que j’ai testé, ça foirait lamentablement s’il y avait un
sleepdans le rc.local (ou autre blocage type montage d’un FS réseau).# Du point de vue utilisateur ou mainteneur ?
Posté par appzer0 (site web personnel) . Évalué à 10.
Je trouve que tu as bien saisi la nuance de jugement selon le public : les sysadmins/utilisateurs qui trouvent ça bien foutu et facile à utiliser (je suis aussi de cet avis), et les bidouilleurs et autres intégrateurs/packageurs qui ont vu l'envers du décor, pas forcément joli-joli.
Pour avoir intégré systemd il fut un temps à la distribution que je maintiens (http://0linux.org), c'est ce côté-là qui m'a rebuté : systemd ne sait pas se tenir tranquille. À chaque release ce sont des binaires supplémentaires qui apparaissent et s'accaparent un rôle supplémentaire, de nouvelles règles Udev qui modifient le comportement, des déplacements de binaires, un paquet qui devient finalement obèse tout comme sa documentation (que ce soit un bien ou un mal, il faut se la coltiner)…
Nous avons donc utilisé systemd pendant 6-8 mois avec quasi-bonheur (bien qu'on ait dû se taper quelques unités à écrire et bien faire attention au mécanisme de dépendances ainsi qu'à un vocabulaire qui évolue vite où de nouveaux mots-clés font leur entrée régulièrement) côté utilisateur, mais côté intégration/empaquetage on n'a jamais été vraiment à l'aise et confronté à des limitations et à un manque de souplesse qui a fini par avoir raison de sa présence dans 0Linux, car demandant trop de hacking, justement, de notre part sur un logiciel qu'on connaît quand même plutôt mal.
En vrac : la restriction du démarrage des sessions du bureau sur le tty1, la création de fichiers spécifiques plus ou moins obscurs pour démarrer un initramfs (pour un Live par exemple) nous forçant peu à peu à passer à dracut qui lui intègre tout ce qu'il faut, le journal binaire qui a occasionné de beaux plantages de la machine, les consoles qui sautent après un certain temps si on ne s'y connecte pas, le service d'optimisation du temps de démarrage « readahead » qui a fini par être encore plus lent que mes initscripts à la BSD/Slackware et sûrement d'autres aspects que j'oublie.
Mais de là à dire que systemd n'est pas du tout hackable, il y a un fossé. Mis à part le journal en binaire, tout est au contraire très modulaire et le vocabulaire des unités et des options des binaires couvre très largement les usages et besoins (même si ça doit passer par la réécriture de nombreuses unités mais c'est un autre problème, systemd fournit le maximum de fichiers pour que tout marche tout de suite, on ne va pas s'en plaindre).
Plus le temps passe et plus je me dis que Lennart aurait bien mieux fait de concevoir une sorte de protocole ou une norme/RFC bien définie et stable (car les idées sont toutes très bonnes à la base) mais surtout pas d'implémenter tout ça dans un gros machin comme systemd, qui veut tout savoir faire tout en continuant d'avancer très vite (il va peut-être même un jour gérer nos paquets !). Ici on va conserver notre init BSD-like en attendant que les choses se tassent.
Donc, pour répondre à ta question : les deux. Intégration pour l'utilisateur, hackabilité pour le mainteneur/bidouilleur. Et justement systemd est peut-être trop intégré pour être hackable, bien qu'il le soit suffisamment (hackable).
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Zenitram (site web personnel) . Évalué à -1.
Rigolo ce que tu dis : ce sont les intégrateurs/packageurs des distros qui ont choisi (Debian a même eu un vote sérré) systemd, et ceux qui râlent ne sont pas intégrateurs/packageurs…
Ho, zut, le monde évolue, Linux fait de plud en plud de choses! Oui, c'est peut-être dur de suivre, mais après pas la peine de réinventer la roue 1000x avec une n-ième distro. Le monde a besoin de fonctonnalités, pas n-ième distro. Systemd forunit les fonctionnalités.
Tu lui demandes de faire de la theorie, c'est ça? Un truc qui n'aurait pas marché? Ben non, jsutement, il a mis en pratique, et c'est ça qui fait que c'est utilisé!
Free Desktop et ses specs jamais utilisées, on a assez donné…
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par dinomasque . Évalué à 8.
Pourquoi continuer à râler contre Systemd quand il suffit de ne pas l'utiliser ?
A ceux que la complexification de GNU/Linux rebute, OpenBSD ouvre grand ses bras.
BeOS le faisait il y a 20 ans !
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par cosmocat . Évalué à 6.
ou le forker….
http://linux.slashdot.org/story/14/09/21/1427240/fork-of-systemd-leads-to-lightweight-uselessd
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 1.
Pfff j'allais le citer justement :)
Pour ceux qui ont la flemme d'aller cliquer sur le lien, en gros:
_ ça part de systemd208
_ ça à pour objectif d'utiliser des libC autres que celle de GNU, voire d'être utilisable avec un autre kernel. Portable quoi.
_ l'objectif est un truc qui ne gigote pas niveau features, que ça soit pas bloated.
En gros, j'ai l'impression que ça allie les qualités de systemd (les fichiers de config simples à comprendre pour quelqu'un qui n'est pas un guru shell, par exemple) sans prendre ses défauts (j'ai toujours autant de mal à piger l'intérêt des logs binaires, ou pourquoi le PID devrait gérer autant de choses).
Pour le coup, je pense que ce projet est très prometteur. Même si les fans du scripting traînerons toujours la patte, au moins ceux qui aiment les choses portables et stables n'aurons pas trop de remords à l'utiliser.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par xcomcmdr . Évalué à 10. Dernière modification le 24 septembre 2014 à 18:16.
Chez moi le PID 1 ne gère que l'init.
je crois qu'encore une fois, cette critique confond systemd le projet, et systemd le binaire.
systemctl, journalctl, ce n'est pas /lib/systemd/systemd (/usr/bin/init pointe vers cela).
Quand on regarde le man ou les options y'a trois fois rien. J'interagis jamais avec autre chose que systemctl et journalctl.
Évidemment systemctl start "quelquechose" fera appel à /usr/bin/init, mais y'a rien de surprenant là…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par claudex . Évalué à 6.
Un des très gros avantages de systemd, ce sont les cgroups. Du coup, sous d'autres kernel, ça perd beaucoup d'intérêt.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Michaël (site web personnel) . Évalué à 5.
Ton commentaire montre que
systemdperd beaucoup de son intérêt en lui-même sur les systèmes qui n'ont pas de cgroups. Mais des logiciels ajoutentsystemddans leurs dépendances dures — Gnome, paraît-il — parcequesystemdaurait phagocytéudevet qu'ils dépendaient deudev, ce qui rend tous ces logiciels non portables.Il y a donc un intérêt à avoir un
systemdportable.[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Renault (site web personnel) . Évalué à 4.
Certaines fonctionnalités de certains programmes, pas des programmes entiers.
Personnellement je trouve douteux la démarche de vouloir un système d'init portable qui est par essence un composant proche du noyau et ne pouvant exploiter ses spécificités s'il est trop portable.
Puis SysV n'a même pas été fichu de faire des scripts init portables entre distribution GNU/Linux, je ne parle même pas de la compatibilité avec *BSD…
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Michaël (site web personnel) . Évalué à 7.
Un beau jour d'automne, http://boycottsystemd.org/ prit sa plume et écrivit:
Apparemment ils ne sont pas d'accord avec toi—mais je ne suis pas allé vérifier!
Je suis assez de ton avis, mais voir que des programmes comme
gdmougnome-shelldépendent desystemdmontre — ou plutôt donne à penser que — quesystemdn'est pas juste un système d'init. C'est l'argument que développent ceux de Boycottsystemd, texte que j'ai lu avec intérêt — bien que j'utilise XFCE sous FreeBSD, c'est dire si ça me touche! — du moins, au premier degré![^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par gnumdk (site web personnel) . Évalué à 3.
gnome-shell dépend de l'API de systemd et il existe des alternatives proposant l'API systemd utilisées par Ubuntu par exemple.
Bref, encore le site web d'un mec qui n'a rien compris…
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 10.
Personnellement je trouve douteux la démarche de vouloir un système d'init portable qui est par essence un composant proche du noyau
GNI ???
Le système d'init un composant proche du noyau ?
Le système d'init est un jeu d'outils pur userland. Je suis conscient qu'avec la main mise de systemd sur tout un tas de fonctions qui n'ont pas grand chose à voir avec l'init on peut être dans la confusion, mais /bin/bash est un init tout à fait convenable - il suffit de faire rw init=/bin/bash dans grub pour s'en rendre compte.
De même une ligne de commande qui va simplement monter les disques pour ensuite lancer (même pas en mode démonisé) un petit serveur genre apache statique, ça se fait très bien.
L'init traditionnel n'a aucun rapport avec le noyau, du moins pas plus de rapport qu'un utilisateur root qui lance des commandes depuis un terminal.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Renault (site web personnel) . Évalué à 0.
Le but de l'init est d'initialiser tout le système et participe à la gestion du processus et des services. Pour faire tout ceci correctement l'init est proche du noyau car c'est ce dernier qui offre des abstractions pour gérer des processus (notamment les cgroups dans le noyau Linux, mais pas que).
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 10.
Le but de l'init est d'initialiser tout le système
Tout dépend de ce que tu appelles le système. Si tu parles de la partie userland, l'init peut effectivement mettre en place l'ensemble du userland, mais ce n'est en rien une obligation. Un certain nombre d'autres éléments peuvent s'en charger. L'init va lancer le premier processus qui a son tour peut lancer d'autres processus. Sur des terminaux type NCD l'inti va juste lancer un listener qui lui lancera le reste des applications en fonction des demandes.
Par contre pour que l'init puisse se lancer il faut que le système non userland soit déjà dans un état très avancé.
Pour faire tout ceci correctement l'init est proche du noyau car c'est ce dernier qui offre des abstractions pour gérer des processus
Le kernel n'offre pas des abstractions pour gérer les processus, il fournit des interfaces userland. Généralement ces interfaces sont utilisées ensuite pour créer des abstractions (typiquement le pseudo file system /proc ). Mais l'init (traditionnel, systemd étant en train de changer la donne à ce niveau là) n'a aucun avantage au niveau de ses interfaces ou des pseudo-fs comparé à n'importe quel processus avec les droits root. D'ailleurs de nombreux logiciel de gestion des processus (de nice à psDoom) bypassent complètement l'init.
De façon générale le noyau offre toute les fonctionnalités possibles et imaginables de l'OS. C'est le seul à pouvoir attribuer de la mémoire, du temps d'éxécution, un PID, des droits d'accès sur les devices ou les pseudo-devices, des changements de contexte etc.
On pourrait dire que pour faire son travail correctement Postgresql est proche du noyau parceque c'est ce dernier qui offre la ram et les accès disque dont il a beson pour faire son travail correctement. Ou encore que ping est proche du noyeau parceque c'est lui qui offre les accès réseau et les abstractions ICMP dont il a besoin.
L'init est juste un processus comme les autres, lancé en premier et avec les droits root. Il n'est pas plus "proche" du noyeau que n'importe quel autre processus. Le fait que systemd commence par fermer la porte à double tour pour s'assurer que l'on ne puisse pas lui piquer le contrôle des cgroups ne change rien à celà. C'est exactement comme si un init traditionnel bloquait le port 80 en se mettant dessus.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . Évalué à 4.
Pourquoi s'arrêter en si bon chemin ? Le noyau devrait lancer l'init qui lance le premier processus (mais c'est quoi alors l'init ?) qui lance un autre premier processus (appelons-le init) qui va lancer un processus (genre l'init), là s'il fait beau c'est lui qui va initialiser le système, mais les années bissextiles il va se contenter d'appeler un autre init…
Tout ça pour ? Rien on est dans l'userland depuis le premier processus.
Hum ? J'ai jamais entendu parlé de changement à ce niveau là pour systemd. Ce dernier ne se gène juste pas pour utiliser toutes les interfaces que linux utilise (et n'hésite pas à aller voir la ligne de commande qui a lancé le noyau (mais ça tout le monde peut le faire).
Et en quoi c'est différent avec systemd ? Il y a dans le noyau des
if (init == SYSTEMD)?Pour ce qu'il voulait dire, je pense qu'il dit que c'est cool de voir des init qui utilisent toute la puissance du noyau sous-jacent. Linux est un noyau particulièrement avancé (qui propose beaucoup d'API en plus de POSIX), mais si demain rc.d de FreeBSD simplifie l'utilisation des capabilities de zfs ou des jails ce sera tout aussi cool et ça ne fonctionnera pas sous linux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Renault (site web personnel) . Évalué à 3.
C'est exactement ce que je voulais dire. Certains processus en espace utilisateur ont tout intérêt à exploiter au maximum les possibilités du noyau utilisé pour permettre plus de fonctionnalités quitte à être non ou difficilement portable. Et ce n'est pas grave pour autant.
Si tous les processus doivent être à 100% portable, tout ce qui est non-POSIX dans les noyaux ne sert à rien ce qui est embêtant quand même.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . Évalué à 5.
La question n'est pas nouvelle : https://linuxfr.org/users/patrick_g/journaux/linux-ou-posix
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 6.
Et en quoi c'est différent avec systemd ? Il y a dans le noyau des if (init == SYSTEMD) ?
J'ai jamais dit qu'il y avait des différences avec l'init systemd. C'est bien le truc, il n'y a aucune raison pour que l'init soit considéré comme "proche" du noyau, du moins ni plus ni moins que n'importe quel autre processus.
Par contre la nébuleuse systemd elle, en mettant des locks exclusifs dans tous les sens créé une vraie différence avec le déroulement traditionnel d'un init. Ca apporte de bonnes choses et des choses moins bonnes, mais ça change réellement la donne. Systemd en tant que gestionnaire système (c'est à dire tout ce qui va au delà de l'init) change complètement les interactions avec les processus.
Pour ce qu'il voulait dire, je pense qu'il dit que c'est cool de voir des init qui utilisent toute la puissance du noyau sous-jacent
Et ce que je veux dire c'est qu'il n'y a pas de raison que ce soit plus cool pour l'init que pour n'importe quel autre processus. A part le fait qu'il ne doit pas mourir sous peine de faire s’arrêter le système, l'init est un processus comme les autres. Je ne vois pas en quoi c'est un vrai plus que l'init tire partie des fonctionnalités avancées du noyau, du moins pas plus que si il s'agit d'Apache, de MySQL ou de Xorg.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . Évalué à 2.
"dans tous les sens" ? Carrément ? Ça veut dire quoi pour toi dans tous les sens ? Vu que les mots n'ont plus vraiment de sens il semble.
Sérieusement ? Va falloir réexpliquer l'intérêt de l'utilisation des cgroup dans l'init ? T'es juste ridicule.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 9.
"dans tous les sens" ? Carrément ? Ça veut dire quoi pour toi dans tous les sens ?
Ben le login, le réseau, les cgroups, certains paramètres LXC, certaines fonctionnalités acpi/apm, et bien entendu toute la couche d'interface DBus de discussion avec les processus (et j'en passe). Je pense que dans tous les sens est assez approprié dans ce cas.
Sérieusement ? Va falloir réexpliquer l'intérêt de l'utilisation des cgroup dans l'init ? T'es juste ridicule.
Oui il va falloir réexpliquer encore et encore. Par exemple l'intéret qu'il y a de lancer un résolveur local unique dans un cgroup. Il existe en une seule instance, le mapping service/pid est évident, il ne spawnera jamais de fils, son empreinte mémoire et CPU ne varira pas et si je veux de la sécurisation il faudra de toute façon que je passe par des MAC. Donc pourquoi le caller dans un cgroup et exiger les droits root pour pouvoir modifier sa config ?
Mais surtout pourquoi m'obliger à passer par systemd pour gérer mes cgroups. Contrairement à ce que tu impliques je connais et j'utilise les cgroups depuis un bon moment, et par exemple je veux que certains de mes services soit dans le même cgroup. Avant systemd c'était très simple, avec systemd à jour avec les slices et les scopes c'est une horreur (de l'aveu de Lennart lui même, c'est une des raisons pour laquelle il est en train de modifier complètement les intefaces cgroup).
Les cgroups sont très interressant dans certains cas, à savoir tague des processus qui sont potentiellement capables de faire spawner d'autres processus, ou suivre une instance spécifique d'un service que l'on lance en 25 exemplaires. Mais pour une majorité de cas c'est juste un overhead dont on aurait pu se passer.
ces logiciels peuvent toujours se servir des cgroups
Dans le nouvelle version de systemd avec lock exclusif sur les cgroups ca n'est possible que si
a) le processus en question possède les libs DBus et systemd qui vont bien
b) le processus en question a les droits root
c) la gestion des cgroups voulues par les processus n'est pas en conflit avec le tagging cgroup de systemd.
ces logiciels ne se sont JAMAIS servi des cgroups
Magie du code respectueux de la philosophie Unix, même si ces logiciels n'ont jamais implémenté de fonctionnalités cgroups en interne, il était tout à fait possible pour un admin de gérer et de faire gérer par ces processus des cgroup. En d'autres termes c'était flexible. L'inconviennient de systemd est que désormais les cgroup ne peuvent plus être appelés qe d'une seule façon et depuis un seul point d'entrée. En plus la modification d'appartenance d'un processus à un cgroup avant de le relancer est devenue une tache complexe. (Modifier dynamiquement la slice d'une unit est loin d'être uen sinécure) etc.
c'est une problématique d'intégration. L'administrateur d'un site d'e-commerce peu vouloir gérer ça différemment de celui qui fait de l'hébergement. Donc c'est forcément au niveau de l'intégration dans l'OS que ça va devoir se gérer
Donc le fait que systemd oblige tout le monde à utiliser le même tuyau de la même façon est une pénalité non ?
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par oinkoink_daotter . Évalué à -1.
Euh, /proc n'est pas directement fourni par le kernel ?
C'est quoi le rapport entre la gestion des processus et le system d'init ?
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 4.
Euh, /proc n'est pas directement fourni par le kernel ?
C'est un pseudo file-systeme, si tu ne le montes pas ca ne dérange en rien le kernel et tu peux quand même intéragir avec les processus (mais c'est plus compliqué.)
C'est quoi le rapport entre la gestion des processus et le system d'init ?
Là quand même, un système d'init se doit un minimum de pouvoir lancer au moins un processus, de vérifier qu'il s'est bien lancé et de réessayer de le lancer un peu plus tard le cas échéant. Et puis l'init est supposé surveiller tous les processus en dessous ou rataché à lui pour éviter un remake de la nuit des morts-vivants…
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par oinkoink_daotter . Évalué à 1. Dernière modification le 26 septembre 2014 à 21:33.
Certes, mais tu écris :
Ce que je relève, cette abstraction dans le cas /proc est faite directement par le kernel et pas du tout par l'init (tu es évidemment libre ou pas de monter /proc). Ca n'a rien à voir de près ou de loin avec systemd.
Oui, merci, je sais comment marche un système d'init et à quoi ça sert. Et pour le coup niveau monitoring systemd le fait beaucoup mieux que le bricolage immonde qui était de mise avant.
Mais encore un fois je suis allé trop vite. La partie qui me gênait était celle la (en parallèle à ce que je cite juste au dessus):
Et ça m'inspire surtout "so what ?". Le kernel aussi, et alors ?
Je comprends bien que tu n'aimes pas systemd pour des raisons qui te sont propres, mais il faut un minimum rester cohérent dans les arguments.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 6. Dernière modification le 26 septembre 2014 à 22:36.
Alors je reprends lentement.
Phase 1:
Renault déclare dans son post qu'il est normal que l'init utilise des fonctionnalités spécifiques du noyeau, vu que c'ets un composant proche du noyau
Phase 2:
Je répond que l'init n'est pas plus proche du noyau que n'importe quel autre processus qui tourne en root.
Phase 3:
Renault surrenchérit en disant que l'init est bien proche du noyau car c'est le noyau qui fournit les abstractions qui permettent de gérer entre autres, porcessus et cgroups
Phase 4:
Je signale tout d'abord que le noyau ne fournit pas d'abstractions (je reviens dessus dans un instant) mais des interfaces et que le noyau fournissant de façon générale toute les interfaces, dire qu'un processus est privilégié parcequ'il a besoin d'interragir avec le noyau est pas franchement discriminant.
Je reste sur ma lancé, l'init processus comme les autres qui n'a ni plus ni moins de raisons que les autres d'utiliser des fonctionnalités spécifiques de Linux.
C'est sur ce post là que tu interviens. Je n'ai pas encore commencé à taper sur systemd (ce que je ferai plus tard, suites aux provocations de Barret Michel)
Tout ce que j'ai dit pour l'instant c'est que au niveau des interractions avec le kernel, l'init est un processus root comme les autres.
Maintenant ton propos :
a) je n'ai jamais dit que /proc était fait par l'init. J'ai même dit à plusieurs reprise que l'init n'avait pas plus de prise sur les abstractions que n'importe quel processus root. Si l'init était nécessairement à l'origine du /proc, je me serais abstenu.
b) L'abstraction n'est pas faite directement par le kernel. Le kernel (si on a les bonnes options de compilation) peut, si on lui en fait la demande créer une interface secondaire pour le suivi des processus, réserver une zone mémoire, et créer une abstraction filesystem sous forme de pseudo-device mappé en ram et présentée en userland. Dire que cet abstraction est fournie directement par le kernel c'est comme de dire que l'abstraction /media/vcdrom de montage d'une image iso est fournie directement par le kernel. A ce compte là tout est fourni directement par le kernel. Ce que l'on considère directement fourni par le kernel se sont les interfaces, c'est à dire des fonctions userland pour envoyer des commandes au kernel et recevoir ses réponses sans passer par des drivers. Et niveau drivers /proc est plutôt chargé (ram mapping + pseudoFS + moniteur).
La gestion de processus par le kernel, à savoir l'attribution de PID, l'ordonnancement, l'attribution mémoire et son mapping, présentation des appels systèmes d'attentes etc, n'a rien à voir avec la gestion userland des processus. Une fois de plus je ne fais que répondre à Renault qui me dit que l'init est proche du noyau car il participe à la gestion des processus. Je ne fais que lui répondre qu'il ne participe pas plus à la gestion des processus que d'autres processus lancés en root qu'on va avoir du mal à considérer comme proche du noyau (psDoom franchement…)
Je comprends que tu n'aimes pas les gens qui n'aiment pas systemd, mais il faut lire un minimum les threads auquels tu réponds. A l'instant ou tu réponds dans le thread je n'ai pas dit un mot sur systemd ni spécifiquement en tant qu'init, ni généralement en tant que framework. La seule et unique chose que je défends est que vis à vis des interractions avec le noyau, l'init a exactement les mêmes accès et besoins que n'importe quel autre processus.
Deuxièmement quand on attaque une personne sur la cohérence de ses arguments, il faut un minimum vérifier que les arguments qu'on lui prête sont véritables.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par oinkoink_daotter . Évalué à 3.
En fait c'est un peu ça, mount met en musique les interfaces du noyau mais ne fait de lui même quasi rien. Quand le truc est monté c'est du full kernel sans intervention de l'userland.
Pour /proc, la fonctionnalité est fournie directement et complètement par le kernel (ie le kernel fournit un filesystem virtuel complet et transparent pour tout l'userland). Mount le rend accessible au début, mais il n'y a pas de couche logicielle d'adaptation userland qui ferait la glue entre les interfaces du noyau et les écritures dans le filesystem en question. Tout est géré par le ring 0.
Ca c'est Linus qu'a voulu.
Effectivement. J'ai relu le thread et tu as même été trop gentil, car tu as écrit :
Pas un seul système de gestion de processus n'utilise l'init (au sens de système d'init). Sauf le system d'init lui même pour traquer ses processus et bien sur les commandes pour gérer les démons gérés via le système d'init.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par xcomcmdr . Évalué à 5. Dernière modification le 24 septembre 2014 à 22:28.
Euh il y a des forks d'udev, compatibles je présume avec les programmes qui dépendaient de udev (sinon ils n'ont pas beaucoup d'intérêt).
Et depuis quand on ne peut pas utiliser udev sans systemd ?
Quant à Gnome, il tourne toujours bien sous OpenBSD, au moins
Et Gnome 3 utilise les APIs de timedated, localed, hostnamed et logind. Et là, on peut réimplémenter les APIs, utiliser systemd, ou faire en sorte qu'ils soient utilisables sans systemd (et un moment, Ubuntu utilisait logind sans systemd).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 3.
(et un moment, Ubuntu utilisait logind sans systemd)
Non, Ubuntu utilisait logind sans utiliser l'init systemd, mais faisait quand même appel à une palanqué d'outils systemd, bidouillés à fond les ballons pour que ca marche. Les libsystemd-* qui permettent plus ou moins d'avoir les fonctionnalités systemd même quand systemd n'est pas lancé en tant qu'init avec un PID 1
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par eingousef . Évalué à 10.
Il faudrait pousser les BSD à remplacer leur kernel par linux.
*splash!*
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par claudex . Évalué à 3.
Il faudrait pousser à un équivalent des cgroups pour POSIX, mais ce soir, je suis un peu fatigué, je te laisse y aller.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par eingousef . Évalué à 10.
Il faudrait surtout pousser Lennart Poettering par la fenêtre :o
*splash!*
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 8.
Pour le moment, le mec a surtout retiré du code, et appliquer des patchs refusés upstream pour musl. L'argument des devs de systemd étant "il faut rajouter le code dans musl", et les devs de musl "il faut rajouter le code partout ailleurs" ( mais bon, y en a qu'un des 2 qui se fait traiter de fachiste pour refuser du code ).
Donc oui, c'est sur qu'en ne faisant que retirer du code d'une vielle version, ça va pas exploser. Bien sur, c'est intenable sur le long terme sauf à ce que rien d'autre ne bouge à coté.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 7.
On peut aussi appeler ça, réduire la complexité, refactorer, ce qui réduit le nombre de bugs potentiels, et accroit la facilité de maintenance.
Ou peut-être que ce qui est intenable sur le long terme, c'est un outil qui n'est pas stable dans ses fonctionnalités, qui ajoute en permanence de nouvelles choses (qui sait s'il ne finira pas par en supprimer?). Un tel outil, c'est bien pour jouer, mais en tant que dev, je ne me baserais jamais sur un outil plus glissant qu'une anguille, et les raisons sont simples:
10 ans, ce n'est pas si énorme que ça, du code peut très bien tourner avec 10 ans d'âge sans souci, et on peut très bien avoir besoin de déployer le même programme sur une machine plus récente. Sauf qu'en 10 ans, bien des choses peuvent se passer en informatique…
Et d'ailleurs, un code qui augmente de taille en permanence, dont personne ne connaît la finalité réelle, c'est ça, qui est vraiment intenable. Ça finit en usine à gaz, et, en admettant que systemd ait la même solidité et le même futur que Xorg, regardes donc les arguments pour la création de wayland: repartir sur une base de code propre qui ne fasse pas peur à tout le monde, qui ne fasse pas fuir les éventuels contributeurs.
Systemd ne me semble pas du tout dans cette optique: au début, le but, c'était juste de se passer de scripts shell pour gérer les daemons, maintenant j'ai pas l'impression que ce soit toujours le même: il s'insère dans les systèmes de journalisation (ce qui aurait très bien pu être fait, mais par un projet autre, complètement séparé, pourquoi pas), de login, et j'en oublie.
Avoir un projet qui sait limiter sa sphère d'influence, c'est avoir plus de chances d'avoir un truc fiable à la fin. Et quand ça bug, c'est plus simple de cerner l'origine du bug, et de le corriger sans en rajouter ailleurs. Ça ne semble pas être le cas de systemd, et uselessd semble vouloir corriger ce problème.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 7.
Dans ce cas, tu doit faire que du C ou du perl. Parce que le python, le ruby et le php d'il y a 10 ans, y a des chances que ça marche plus.
je suis d'accord qu'il faut de la stabilité, mais je pense que c'est à la distribution d'assurer ça. Le reste, c'est juste une conséquence de la R&D distribué qu'est le mouvement du logiciel libre. Il y a les outils ou personne n'innove,
Systemd a une page qui liste les interfaces et la promesse de pas les changer, ce qui est largement mieux que la majorité des projets que je connais, même si certains s'en sortent aussi bien voir mieux.
Mais maintenant, je pense qu'on peut pas soutenir les devs kernels qui soutiennent que les interfaces internes du kernel peuvent bouger, alors qu'il y a de la demande pour la stabilité (pour les drivers), que d'autres arrivent à le faire (solaris, windows ), et en même temps réclamer que rien ne change sur les autres projets.
Ça me semblerait juste hypocrite, et je doute qu'une séparation arbitraire il y a un bout de temps entre kernel space et user space soit une raison suffisante pour dire "c'est normal d'être emmerdé pour les drivers, bout de code compilé qui tourne sur ton pc, mais pour les softs en user space, autre truc compilé qui tourne sur ton pc, c'est différent".
Et je pense que le but n'est pas de remplacer init, mais de remplacer les initscripts ( au sens paquet du même nom ). Et en effet, par la suite, d'offrir une API pour gerer la machine tant qu'à faire.
Les initscripts, les trucs qui montent le LVM, lance le réseau, lance les softs, etc. Tout des trucs qui étaient déjà fait à gauche et à droite de façon différente par chaque distro.
Tu donnes l'exemple de la journalisation, mais il faut bien voir que le journal est une conséquence du design et de la position de systemd. Tu voudrais mettre ça en dehors de systemd, mais comment est ce qu'un programme en dehors de systemd accède à stdin et stdout ? Donc une fois que tu te dit "ça serait une idée de choper ça", tu te retrouves à avoir un cache. Et tu te dit "je peux rajouter plus de données". Et ensuite, "je peux sans doute faire des recherches dans ce cache", et le mettre sur le disque et voila, journald dans sa forme actuelle, cad un programme qui va en effet faire le même travail que les fichiers syslog, mais dans une base de données indexé lisible.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 1.
En effet, entres autres. Et je travaille avec du code qui à pas loin de 10 ans, installé sur des machines dont l'âge varie de 6 ans à dans quelques jours (install et param en cours).
Au niveau des langages utilisés sur ces systèmes, on trouve (non exhaustif): du shell, du sql, du C et un peu de C++. Et clairement je trouve ça agréable de savoir que dans 10 ans, ces programmes compilerons encore avec les nouvelles versions des compilateurs (pour le code C/C++, le SQL je ne suis pas sûr même si j'ose espérer que oui, et le shell je n'en mettrais pas ma main à couper).
Je ne dis pas que les choses ne peuvent pas bouger, je ne suis pas bête… enfin, si, mais pas à ce point là. Je dis juste que systemd ne me semble pas assez mûr pour que je me permette de baser un développement dessus, sentiment que je ressens principalement à cause du fait que, comme ceux qui ont forké, je n'ai pas l'impression que le projet ait des limites claires.
Chose que se propose de définir l'auteur du fork uselessd.
Lisible avec combien d'outils différents? Un seul? Et que faire si un "hypothétique" bug apparaît qui corrompt la base de données (qui, j'imagine, est unique: une seule BDD pour l'ensemble du système?) ? On perds tous les journaux? Je suis pas admin, mais je suppose que ce n'est pas très acceptable, si?
Alors que les journaux tels que je les connaît à l'heure actuelle, je peux les lire avec une pléthore d'outils. Et si jamais l'un d'eux, pour une raison X ou Y était corrompu, cela ne m'empêcherait pas d'accéder aux autres (manifestement, il n'y a pas qu'un seul fichier de log pour l'ensemble des services des systèmes que je côtoie, une éventuelle corruption ne me ferait donc perdre qu'un seul fichier, voire qu'une seule partie de ce fichier…).
Enfin, j'ai envie de citer le seul autre outil de journalisation binaire que j'aie vu, celui de windows. Franchement, pas quelque chose que j'ai envie de voir arriver sur Linux, vue la galère que c'est (ou du moins, que c'était à l'époque d'XP) que d'essayer d'y tirer la moindre information utile… non merci, vraiment. Après, ça s'est peut-être amélioré, et systemd est peut-être mieux… à prouver.
Et vu que les logs me servent régulièrement (toujours utile pour détecter les symptômes réels d'un bug d'une appli de ma boîte, ou pour les discerner d'un pebcak ;) ) je préfère avoir un truc en lequel j'aie confiance.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par fmaz fmaz . Évalué à -1.
Parce que s'il existe 15 progs différents, ça veut dire qu'il n'y aura pas de bugs dans celui que tu va utiliser et donc aucune chance de perdre tous les journaux ?
C'est au contraire très très bien qu'il n'y ait qu'un seul outil. Les bugs seront trouvés beaucoup plus vite.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 4.
C'est un point de vue. Le miens est qu'il vaut mieux avoir plusieurs implémentations pour une même fonctionnalité, car cela permets de ne pas transformer des bugs/comportements indéfinis en pseudo standard. Cela évite aussi l'enfermement.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par fmaz fmaz . Évalué à 5.
Je ne vois absolument pas le rapport.
J'ai l'impression que
- des gens reprochent à l'équipe de systemd d'avoir implémenté leur idée.
- des gens pensent que les standards freedesktop morts-nés, c'est bien mais pas très utile. Au moins, là c'est utile.
- des gens se disent qu'à partir du moment où c'est implémenté, alors, forcément, ce n'est pas documenté.
Je ne me suis pas penché dessus mais j'ai l'impression que tout ce que le projet systemd fait est très documenté. Je suppose donc que le format de stockage des logs l'est aussi. En fait, en 3 minutes, j'ai trouvé ça: http://www.freedesktop.org/wiki/Software/systemd/journal-files/
À partir de ce moment, tu peux t'amuser à implémenter un programme spécifique pour lire ces logs. Et si tu trouve une incompatibilité, tu peux ouvrir un bug. Tu n'es donc pas enfermé.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 4.
Bien sur qu'il vaut mieux plusieurs implémentations, mais l'équipe systemd en a écrit une, il manque plus que les autres pour le faire.
Ensuite, il y a aussi le fait que faire plusieurs implémentations, c'est aussi dupliquer le code, donc c'est pas exactement gratuit en terme de ressources. Si l'unique motivation est d'avoir plusieurs implémentations, ça suffit généralement pas, il y a souvent d'autres raisons ( license, architecture différente, choix d'implémentation, etc ). Sous Linux, on a attendu longtemps d'avoir autre chose que la libjpeg, et je suis pas sur d'avoir vu autre chose que la libpng.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par fmaz fmaz . Évalué à 4.
Au passage, combien d'implémentations concurrentes d'ext4 connais-tu?
Te sens-tu enfermé pour autant ?
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 3.
Il y a sans doute une version dans grub, et une dans les BSD, et une sous windows. Bon, peut être readonly pour grub, peut être incomplete pour freebsd et windows.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 3.
Je n'en connaissais aucune, mais c'est une excellente question, qui mène à ceci:
Donc, il semble qu'il en existe d'autre, sur d'autres OS.
Accessoirement, il me semble avoir lu qu'il est possible de lire de l'ext4 (jamais testé cependant) en mode dégradé avec des outils lisant ses prédécesseurs? (question rélle)
Et pour finir, ext4 est nettement moins invasif. Je veux dire, quel que soit le système de fichiers de mes partoches, je ne crois pas qu'un seul outil s'en apercevra, sauf ceux dédiés à la gestion des FS.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . Évalué à 5.
Et pour finir,
ext4les logs systemd sont nettement moins invasifs. Je veux dire, quel que soit le système defichiers de mes partochesde mon système, je ne crois pas qu'un seul outil s'en apercevra, sauf ceux dédiés à la gestion des logsFS. :)Il continue d'implémenter l'API syslog.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Anonyme . Évalué à 10.
On peut dire la meme chose de gzip, xz, postgresql, ext4, et tout un tas d'autres trucs.
Que faire si un hypothétique bug apparait qui corrompt ta base de données postgresql ? Ou bien ton systeme de fichier ext4 ?
Pour tout le reste, personne ne s'en inquiète particulièrement. Mais quand ca concerne systemd, c'est tout de suite un problème bloquant.
C'est completement stupide comme raisonnement.
Le systeme de logs de windows c'est la galère, et ca utilise des logs binaires. Donc un systeme qui utilise des logs binaires c'est forcement la galère ?
Dans la liste des sophismes, ca doit etre le cum hoc ergo propter hoc:
https://fr.wikipedia.org/wiki/Cum_hoc_ergo_propter_hoc
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 8.
Je pense que soit tu estimes les logs sont transients, et tu t'en fout de les perdre.
Soit tu estimes qu'ils sont importants, et tu traites ça comme tel ( cad, des backups, ou tu logues en double sur 2 machines, etc ). Et à ce niveau la, journald permet de tirer les logs, ou de les pousser de façon native. On va me dire que les logs non binaire le font aussi, mais c'est un peu moins simple en pratique. En fait, pour la partie "pousser", c'est kifkif.
Tout d'abord pour tirer les logs, car il faut mettre rsync en place pour tirer les logs de façon sécurisé. C'est pas dur, mais c'est un peu chiant si on le fait par ssh ( je passe à chaque fois 5 minutes sur la syntaxe de forcecommand et les options exactes à mettre, donc 4 minutes à retrouver le truc pour les voir ). Ca se fait bien via rsync tout court ( via xinetd par exemple ), mais ç'est en clair, et je suis pas sur que tout le monde soit ok avec ça. On peut monter ça via nfs, ftp, http, etc, mais c'est moins efficace sur des gros fichiers que rsync AMHA.
L'autre souci, c'est la configuration par défaut des distributions et de logrotate. Par défaut sur certaines distribs ( Debian based, Mandriva ), logrotate va renommer les fichiers en utilisant un incrément, ce qui fait qu'un fichier nommé logrotate.2.gz un jour sera logrotate.3.gz plus tard, ce qui est pas terrible pour faire des backups. Il semble que RHEL 7 utilise l'option dateext dans logrotate.conf pour éviter ça, donc on peut éviter ( il semble aussi que ça date de 2007, donc je me prends un peu la honte sur ma demonstration ).
Journald utilise un timestamp ( encodé en hexa , le 3eme champ du nom de fichier cf http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-server.c#n273 ) ce qui fait que c'est facile de trier et de retirer les plus anciens. Je regrette ceci dit que le timestamp ne soit pas lisible à l'oeil nu. Mais il a le bon gout d'avoir une taille fixe, ce qui evite des corners cases avec le tri en shell ( genre, oublier de faire un tric sur une valeur numérique au lieu d'une valeur lexicographique, ce qui fait que toto-400 est vu comme avant toto-50, car on compare caractères par caractères ).
Donc rien d'insurmontable bien sur, rien de novateur, mais la force de systemd, c'est aussi d'offrir ça par défaut, ce qui permet de construire par dessus des choses haut niveau réutilisable, et ce qui démocratise la bonne pratique.
Un truc bien fait avec journald, c'est que le logiciel va gérer nativement le faire d'avoir des fichiers de log venant de n'importe ou, car le nommage le permet, et le logiciel en tire parti. On peut tout mettre tel quel dans /var/log/journal, et journal va faire "the right thing". On peut donc suivre les logs sur plusieurs machines, etc, etc. Le nommage des logs classiques implique un post traitement plus complexe, ce qui est faisable encore une fois. Par exemple, splunk, elastic search sont des solutions pour ça qui vont bien au delà de journald. mais qui requiert une infra plus conséquente, la ou journald va juste tirer parti du nommage des fichiers et d'un design simple.
C'est donc vraiment dans l'approche d'offrir un truc parce que c'est facile à faire, une solution intermédiaire entre rien et le truc plus complet et plus compliqué ( un peu comme le protocole de notification de systemd ). Ça règle pas tout les soucis de tout le monde, mais ça peut aider.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Moonz . Évalué à 3. Dernière modification le 28 septembre 2014 à 10:32.
Déjà si ton système de fichier est inutilisable à cause d’un bloc corrompu tu devrais en changer très vite.
Pour gzip, postgres, xz, etc c’est pour ça qu’on fait des sauvegardes. Ça marche beaucoup moins bien pour les logs, parce que si problème il y a, il est certainement dans les logs… dans la partie corrompue non encore sauvegardée.
Scénario d’exemple : je sauvegarde tout à 5h du matin.
À 6h du matin il se passe je ne sais pas quoi qui corrompt à peu près tout.
Mes informations importantes, du point de vue base de données, sont dans les sauvegardes, donc pas de problème, j’ai eu une alerte SMS/mail, je bascule sur le système secondaire à 7h du matin et je restaure la base, tout le monde pourra bosser normalement en arrivant à 8h sans même savoir qu’il y a eu un problème.
Mes informations importantes, du point de vue du log, c’est ce qu’il s’est passé aux alentours de 6h. Ça a vachement intérêt à être lisible même avec un bon paquet de pertes, parce que ce qui est intéressant n’est par définition pas dans le backup (vu que tout tournait bien au moment du backup).
Bref c’est pas une question de systemd/reste du monde, c’est une question de log/reste du monde, le reste du monde peut se permettre de se reposer sur les sauvegardes en guise d’intégrité des données, les logs ne le peuvent pas, ils doivent se reposer sur eux-mêmes.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . Évalué à 3.
Qu'est-ce qui te fais dire que ce n'est pas le cas des log binaires de systemd ? Ils sont ouvert en mode append si je ne m'abuse donc il n'y a pas ce genre de corruption totale.
Tu aura accès à toutes les entrée qui précèdent le problème (si le problème a bien corrompu les logs ce qui reste à imaginer).
Ensuite pour le reste, tu dois pouvoir te retrouver grâce à l'entête de chaque entrée et donc pouvoir lire la suite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 2.
Qu'est-ce qui te fais dire que ce n'est pas le cas des log binaires de systemd ?
Zbigniew Jedrzejewski-Szmek et Lennart Pottering en l'occurence.
https://bugs.freedesktop.org/show_bug.cgi?id=64116
The only way to deal with journal corruptions, currently, is to ignore them:
Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence.
La corruption d'un journal binaire est très compliqué à corriger, surtout si des extensions sont activés ou si c'est un tag qui est altéré.
Dans le cas de l'altération d'un tag, toutes les entrées à la suite du tag sont bonne à mettre à la poubelle.
A noter que jorunald n'a pas d'équivalent fsck au boot ou de controle continue. Il se peut donc parfaitement qu'il continue à écrire dans un journal corrompu, et ce même après un reboot. Je recommande vivement à tous les utilisateurs systemd qui utilisent journald de faire un renvoi des logs vers un logger fiable, et de lancer journalctl --verify de temps en temps.
A noter également qu'un journal parfaitement valide, mais qui n'aura pas été indexé, ou pas tagué (par exemple suite à une perte brutale de l'alimentation) sera lui considéré comme corrompu, et sera donc remplacé par un nouveau fichier.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Zenitram (site web personnel) . Évalué à 3.
De ce journal binaire.
En n'importe quel binaire, on peut faire exactement comme pour ton "texte" (qui est juste une forme de binaire), et avoir un élément de synchro (pour ton "texte", c'est l'octet 0x0A, ben oui du "binaire", qui fait office de synchro). Par exemple, dans le monde vidéo envoyé par satelitte, on peu se raccrocher n'importe quand au contenu, le fait qu'on ne soit pas la au début de la transmission ou qu'on ai 5% de pertes de paquets n'empéchant pas de se resynchroniser souvent.
En l'occurence, le choix de ne pas faire de code de synchro est un choix qui n'a rien à voire avec "texte" ou non "texte", c'est un choix de design supplémentaire qui n'a pas l'air de déranger ceux qui choisissent systemd (et ils sont nombreux), sans doute parce que les avantages de leur format compensent les quelques désavantages.
Bref, rien à voire avec la guéguerre "texte" contre non "texte", à part pour ceux qui veuelnt absolument voir le "binaire" comme le bouc émissaire.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . Évalué à 5.
En n'importe quel binaire, on peut faire exactement comme pour ton "texte"
Non, on ne peut pas. Sur un fichier texte avec des corruptions (mettons 3% de caractères soit remplacés, soit tronqués, soit illisibles) on arrive encore humainement à faire les corrections qui vont bien si c'est possibles.
Sur un fichier binaire, surtout comme ceux de journald avec une entête qui défini la taille de l'objet, si il manque un seul octet c'est la mort.
Les mecs qui écrivent journald, disent eux même que c'est extrêmement compliqué de corriger un fichier binaire, que ce soit automatiquement ou humainement.
Da façon générale si j'ai une corruption unique dans un fichier texte, je vais avoir une ligne de logs inexploitable. Si j'ai une unique corruption dans un fichier au format journald, ca peut aller jusqu'à faire que toutes les entrées suivant la corruption sont inexploitables. (Cas de corruption de tag)
qui n'a pas l'air de déranger ceux qui choisissent systemd (et ils sont nombreux), sans doute parce que les avantages de leur format compensent les quelques désavantages.
Je n'ai pas dit que le format binaire n'avait que des défauts et qu'il était idiot. Néanmoins dire que le format binaire, surtout tel que choisit par journald présente exactement la même résistance à la corruption que les fichiers, chose que même les créateurs du format réfutent, est une connerie.
On peut parfaitement préférer journald à syslog, c'est une question de choix, de besoin et de gouts personnels. Mais dire que le format de logs texte est extrèmement résistant à la corruption alors que le format journald est extrèmement sensible à cette même corruption est un fait. Ne pas être d'accord avec l'impact de la corruption sur les journaux journald, c'est comme ne pas être d'accord avec le fait que 2+2=4. Tout le monde est libre d'avoir son opinion, mais là ca ne va pas changer grand chose au résultat.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 2.
Bien que je préfère ça aussi, je suis parfois hélas obliger de faire face à un monde différent du tien, ou les choses bougent plus vite. Exemple, ruby, ou python. Donc oui, c'est chiant d'avoir des écosystèmes qui bougent, mais c'est le prix à payer pour avoir des améliorations. Et si le libre n'évolue pas, je pense qu'il risque de tomber en désuétude, même sur des domaines ou il est dominant. Exemple, les webmails, les forges, qui ont globalement pris une grande claque via gmail et github ( même si github a aussi bénéficier d'un effet réseau mais pas uniquement ). Je sais que des gens préfèrent jira à bugzilla pour les bugs trackers ( ou confluence à mediawiki, pour les wikis ).
Ensuite, on est pas à l'abri d'une évolution ( genre apache qui a changé son format, chose que j'aurais pas cru possible, surtout si c'est pas pour corriger les fautes de grammaires ).
Il y en a d'autres. Par exemple, splunk. Le souci des logs windows, c'est quand même que le contenu ne veut rien dire sauf pour le développeur. Ou alors, c'est l'UI qui est pourri ? Franchement, je t'invite à choper une centos 7 et à jouer avec. mets un serveur ftp, regarde journalctl, etc. Pour ma part, je me demande comment j'ai fait pour me passer de l'option -u.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par claudex . Évalué à 3.
--sinceet-bont l'air bien pratiques aussi (mais je n'ai pas encore de journald en prod pour être sûr).« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 0.
Naturellement que les choses peuvent bouger. Et ça ne me pose même pas de problème, en soit. Le problème que les gesticulations de systemd me pose, en fait, c'est qu'il s'agit d'un élément central du système (du moins, il souhaite le devenir, et semble y parvenir…), et que donc on peut légitimement je pense, craindre pour le reste du système du même coup.
Python est, ma foi, un excellent exemple. On m'a parlé d'un code python 2.7 qui ne pouvait être exécuté par un interpréteur 2.8. Pour une version majeure, je peux le comprendre hein, pas de souci, parfois il faut savoir péter les API. Mais habituellement, le numéro de version mineur d'un outil est quand même censé être une garantie qu'un interpréteur plus récent pourra digérer de la même façon si ce n'est mieux un code plus ancien que lui (raisonnablement, on parle d'une différence d'une version mineure ici).
Bien sûr, il n'y à pas que python, si j'en crois apt, lsof dépend soit de perl < 5.12.3 (sur ma machine actuelle) soit de libperl4-corelibs-perl. Au moins pour perl, il y à une lib de compat… maintenant, pour me convaincre que c'est une bonne chose, que de casser la compat descendante, ça risque de ne pas être simple.
Oh, et, bien sûr, dans le cas de python/perl/langage-X il est souvent possible d'installer plusieurs fois l'interpréteur/compilateur/whatever. Dans le cas de systemd, j'ai un gros doute?
J'ai précisé que je ne connaissais que celui de windows… savoir qu'il en existe des exploitables est une excellente nouvelle!
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 3.
Sans doute parce que la version 2.8 de python n'existe pas ?
Python a aussi une politique claire de depreciation, qui va afficher des warnings longtemps à l'avance.
C'est curieux, car lsof est écrit en C. Je vois pas ce que perl vient faire la. Mais dans tout les cas, ça serait sans doute un souci d'ABI, pas d'API.
Tout comme le kernel. Et le kernel a bien plus de choses qui en dépendent. On a beau dire "les modules proprios sont le mal", le fait est qu'ils existent, que les constructeurs les utilisent, et que ça fait chier de pas avoir d'ABI stable pour les drivers de leur point de vue.
Mais comme c'est Linus qui dit fuck off, on applaudit des 2 mains. Si quelqu'un d'autre le fait avec les mêmes arguments, ça serait anormal, voir même bloquant avant même d'avoir tenté d'étendre quoi que ce soit. J'ai beau tourner ça dans tout les sens, ça reste 2 poids, 2 mesures.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par dinomasque . Évalué à 3.
wmfinder était un chouette gestionnaire de fichiers graphiques inspiré de NeXTSTEP pour Linux.
La dernière version des sources date de la fin des années 90 et ne compilait plus avec les GCC du début des années 2000.
Parceque le langage ou plus exactement les extensions de GCC avaient évolué.
Je serai curieux de savoir combien de codes sources C/C++ d'il y a 10 ans compilent encore avec les compilateurs d'aujourd'hui (y compris les révisions de GCC).
BeOS le faisait il y a 20 ans !
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 2.
D'où l'intérêt de ne pas utiliser d'extensions. Si ces langages (C et C++) se tapent des procédures assez longues, c'est qu'il doit bien y avoir une raison autre que faire chier à rester immobile, non?
Je serai curieux de savoir combien de codes sources C/C++ standards d'il y à 10 ans ne compilent plus avec un compilateur qui supporte le standard de l'époque (aka: c++98* ou c++03. On à aussi le -ansi.), et donc qui respecte le standard de cette époque. Je ne sais plus laquelle…) récent.
Évidemment, il faut alors se "résoudre" à utiliser les flags qui forcent l'utilisation d'un standard, sinon c'est s'exposer aux emmerdes…
*:
Attention tout de même au standard 98, qui intègre de mémoire une fonctionnalité tellement à la con qu'il n'y à que commeau à l'avoir implémentée --ils avaient d'ailleurs fortement conseillé aux autres de ne pas le faire, la feature en question ayant coûté un refacto massif pour un usage très… parcellaire.-- je ne pourrai pas citer le nom exact de la feature en question: je n'ai appris mes premières notion de C que bien après 98… et donc je ne m'en suis jamais servi.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 29 septembre 2014 à 20:57.
Encore une raison de ne pas utiliser les extensions de GCC.
C++ != C++ avec extensions (de qui que ce soit).
Déj, il suffisait de prendre un autre compile de l'époque pour voir que ça compilait pas, pas la peine d'attendre. Bref, le bonheur du libre qui aime les standards sauf quand il ne les respecte pas et ne prend pas le temps d'aller voir les organismes de standardisation.
Tous les codes conformes à la norme C/C++ (encore une fois, un code C++ avec extensions GCC n'est pas un code C++ valide, HS ici), à quelques exceptions près qui se corrigent très vite.
C'est un des très gros avantages de C/C++ par rapport à d'autres langages (le coup du Python 2 à 3 étant assez rigolo). Les modes changes (Avant c'était PHP, après on a eu Java, puis Python, puis…), C/C++ traverse les ages.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par fmaz fmaz . Évalué à 3.
J'ai toujours trouvé étrange l'histoire des logs « binaires » vs les logs « non binaires ».
Dans tous les cas, c'est binaire. Dans tous les cas, il faut un outil pour les lires. Le fait qu'on utilise utilise un programme étiqueté « non binaire » comme less ne rend pas le format de stockage moins binaire. Si ça te rassure, fais un alias less-log sur la commande binaire qui lit les logs, tu verras, ça ira tout de suite beaucoup mieux.
Au passage, chez moi, j'ai plein de logs qui sont compressés à coup de gzip. Dans le genre format binaire, ça se pose là. Mais c'est pas grave, je peux les lire avec zless et dans zless, il y a less. Ce n'est donc pas un format binaire.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 4.
Bien, alors.
Je vais faire une citation à un site souvent utilisé en tant que référence, notamment quand ça concerne les trucs de base comme c'est ici le cas:
Binary file:
Text file:
Pourtant, il me semble que c'est assez répandu, que d'opposer les formats binaires, aux formats dits de "texte brut", c'est à dire stockant
Tant qu'a faire du mal aux mouches, je te dirais qu'en fait non, rien n'est binaire, puisque ton information n'est jamais exactement une suite de 0 et 1: entre les changements d'états il y à toujours une valeur indéterminée, gérée par l'électronique d'une façon ou d'une autre.
Le problème ici, c'est que pour un fichier ne contenant pas de texte brut, l'outil nécessaire pour lire ton fichier est complexe.
Donc, ce ne sont pas tes logs que tu lis, avec tes outils, mais bien des archives. Et les outils en question font un travail largement différent d'un (oui je sais, version on ne peut plus naïve et bugguée):
Et au final il faut des programmes complexes pour lire des formats qui n'ont aucune fonction standard pour pouvoir les manier.
Sauf que, bien sûr, dans ton cas tu as choisi d'archiver ces journaux pour une raison X ou Y (le manque de place, logiquement?).
C'est là, à mon avis, le problème: si tu choisis de stocker tes fichiers dans un format à la con, ok, mais assumes. Si tu préfères les garder sous une forme triviale, de fichier textes, ok, mais tu assumes aussi les conséquences: les deux ont des avantages.
Dans le cas de systemd, on à un outil qui récupère du texte brut, le rentre dans des structures, puis, si tu le souhaites, recraches éventuellement (oui, je suis au courant qu'il est possible d'avoir à nouveau du texte brut) le contenu en texte brut.
Le problème, c'est que 1) ce n'est pas le comportement par défaut (sauf sur Debian, il semblerait) et 2) quel est l'intérêt de transformer un journal, qui est du texte brut à la base (une grande part des programmes qui font du log, soit écrivent dans des fichiers de texte brut, soit crachent sur stderr ou stdout sous forme de texte brut) en format complexe, puis de le décomplexifier en format texte?
Je sais que quand on parle de performance, de ne pas faire de choses inutiles, on nous rétorque qu'à l'heure actuelle ce n'est pas important, que "le client rachètera de la ram" (bon, ok, un proc plus puissant, ici, mais c'est une réplique d'un prof que j'ai eu et qui m'a vraiment marqué), mais je trouve ce raisonnement stupide. Et pire encore: ajouter des étapes complexes dans du code, ajouter du code qui au final ne sert à rien (puisqu'un peu plus loin on exécute du code qui annule… sans qu'il y ait eu de transformation entre deux!) c'est ajouter de la complexité de maintenance inutilement.
Il existe un mot pour résumer ça: bloatware!
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par fmaz fmaz . Évalué à 7.
La question devient: qu'est-ce que ça veut dire qu'un fichier est /structuré/ en lignes de texte ?
Si on prend comme définition: un caractère prend 8 bits (ou 16 bits ou une taille fixe), alors on n'a pas le droit d'utiliser utf8. Si on autorise les caractères de taille variable, alors un document texte compressé par un algorithme à la Huffman est un fichier texte. Selon toi, mes fichiers de log compressés ne sont pas des fichiers textes. Pourtant, même si la représentation interne est différente, ils sont pourtant clairement structurés en lignes de texte.
Je pense que ton principal problème est que tu as des habitudes. Pour travailler avec tes fichiers de logs, tu utilises certaines programmes (less, grep, sed, awk, cat, perl…) et qu'avec ce changement de format, tu dois changer tes habitudes. Et ça te fait chier (et je te comprends).
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 2.
Admettons.
Donc, systemd utilise une représentation sous forme de lignes? Dans ce cas, pourquoi avoir réinventé la roue, surtout quand on sait à quel point systemd avait déjà tendance à hérisser les poils de certains? En quoi les anciens standards n'étaient-ils pas suffisants? 14 standards ce n'était pas assez?
On verra quand j'aurai un systemd en prod. Pour le moment, ce n'est pas le cas. Par contre, oui, c'est clair, ça me ferait bien chier de devoir utiliser des outils différents pour faire la même chose, et si je me mets à la place d'un admin qui s'est constitué sa collection de scripts au fil du temps, je pense qu'on est plus sur le simple "faire chier", mais sur l'augmentation de la charge de travail: tout à refaire, à déboguer à nouveau, etc.
Youpi.
Tout ça pour quoi? Parce qu'un type à décidé que, non, les fichiers plats, c'est has been? Humpf.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Zenitram (site web personnel) . Évalué à 5.
1/ Cet admin demande simplement à systemd de faire aussi dans l'ancien format. C'est simple, sans doute trop simple, et ce genre d' "argument" ressort encore…
2/ Sous excuse qu'un admin va devoir adapter ses scripts, on bloque toute évolution qui apportent plein de choses? tu es vriament sérieux quand tu sors ça?
3/ Rien n'interdit à l'admin de rester avec son ancien système. On lui dit juste que les autres ne bosseront plus pour lui, mais comme il n'y a pas de contrat pas de soucis. ou est le problème? Rappel : systemd n'interdit à personne de mettre comme avant, ou un concurrent.
C'est merdique, et il a déjà été dit 100x pourquoi. Le monde évolue, et n'a plus les mêmes besoins. Libre à toi de rester avec des fichiers texte (tu peux!), libres aux autres de choisir autre chose. freem n'a d'ordres à recevoir de personne, mais n'a d'ordres à donne à personne non plus.
Ou est donc le problème?
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . Évalué à 1.
Je n'ai jamais dit que quelqu'un était forcé d'utiliser systemd. Ne me fais pas dire ce que je n'ai pas dit.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 3.
Ça part aussi du principe que l'admin change jamais de boulot, et qu'il n'a jamais personne qui le remplace, et qu'il a jamais une personne pour l'aider qui a son propre jeu de scripts avec des workarounds différents, etc :)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . Évalué à 10.
Je suis pas d'accord. Je suis packageur depuis un numbre d'année à 2 chiffres, et j'ai vu les soucis que pose les scripts en bash, à savoir que tout le monde ne maitrise pas le bash, ce qui justement donne des soucis super compliqués.
J'ai donné les exemples de bind, sur debian sur openbsd etc lors des nombreuses discussions sur systemd, mais juste pour montrer les trucs récents sur ansible lié à des fichiers d'init foireux :
Le fichier de nginx sur ubuntu :
https://github.com/ansible/ansible/issues/9108
le fichier de proftpd
https://github.com/ansible/ansible/issues/9069
https://github.com/ansible/ansible/issues/7918
https://github.com/ansible/ansible/issues/6286
Postgresql :
https://github.com/ansible/ansible/issues/8183
https://github.com/ansible/ansible/issues/7695
Et pourquoi ? parce que les gens qui font les scripts se préoccupent pas des détails comme la synchronisation entre le script et le soft qui est geré, ou des détails comme filer les codes de retour.
Donc je pense que la séparation "j'ai vu comment ça marche, c'est moche", c'est faux. Les conséquences d'avoir du bash à tout les étages sont simple à piger, tu as des scripts dupliqués ( car personne n'envoie les scripts upstream et il y a pas d'unité dans ce que tu fais ), parfois de qualité inégale, du au fait que personne ne peux penser à tout à chaque fois, surtout quand ça requiert des compétences que tout le monde n'a pas ( genre, se préoccuper de l'automatisation, ça te viens pas à l'esprit quand tu es un packageur débutant ). Et tu le voit assez vite quand tu fait du mentoring auprès des nouveaux arrivants.
Ensuite, l'intégration de systemd est plus complexe que celle de sysvinit, mais c'est surtout parce que systemd bouge la ou sysvinit ne bouge pas. mais l'intégration de sysvinit n'etait pas non plus une partie de plaisir y a 6/7 ans quand les gens étaient encore en trian de le faire bouger, et que par exemple, mandriva devait refaire les patchs en bash sur le soft venant de Fedora/RH.
Il faut espérer que systemd va finir par se stabiliser un peu plus et innover moins, pour réduire ta charge de travail.
# sinon...
Posté par jcnewb . Évalué à -4.
…sinon j'ai pas compris le titre.
mais bon j'ai lu en diagonale.
parce que bon, hein, quand même quoi.
[^] # Re: sinon...
Posté par yohann (site web personnel) . Évalué à 2.
Je crois que c'est une référence un à bouquin de Jacques Seguela: ne dites pas à ma mère que je suis dans la pub, elle croit que je suis pianiste dans un bordel.
Seguela c'est une peu le Begbeder des années 80
[^] # Re: sinon...
Posté par jcnewb . Évalué à -1.
jacques "si-t-as-pas-1-rolex-à-50-an-t-as-raté-ta-vie" seguala ?
les grands esprits se rencontrent.
[^] # Re: sinon...
Posté par CHP . Évalué à 10.
Quel con ce Séguéla…
"Si à cinquante ans, on n'a pas une Rolex, on a quand même raté sa vie."
"Le Net est la plus grande saloperie qu'aient jamais inventée les hommes."
"Une société de consommation qui refuse de consommer, c'est comme une jolie femme qui refuse de faire l'amour"
[^] # Re: sinon...
Posté par lasher . Évalué à 2.
Je ne sais pas pour les autres citations, mais celle de la Rolex a été complètement détournée. Si tu trouves la vidéo de l'interview initiale (ou une retranscription), tu verras que cette phrase est utilisée dans un contexte ironique.
[^] # Re: sinon...
Posté par CHP . Évalué à 3.
Il me semble pas.
Je me souviens d'avoir vu l'interview en question, et c'etait au sujet de Sarkozy et le bling-bling et en gros il disait "faut arreter de lui reprocher le bling-bling, c'est quoi cette polémique sur les rolex ? Aujourd'hui tout le monde à une rolex ; si a 50 ans on a pas une rolex on a raté sa vie"
[^] # Re: sinon...
Posté par CHP . Évalué à 7.
Vu que tu m'as mis le doute, je suis allé vérifier.
Tiré de wikiquote :
Olivier Galzi : Au début de son mandat, Nicolas Sarkozy a été accusé de «Bling-bling», ce côté ostentatoire. Son goût pour les montres de luxe, c'est l'époque qui a changé, ou une erreur de com' ? De communication …
Jacques Séguéla : Non c'est une erreur journalistique. Comment peut-on reprocher à un président d'avoir une Rolex ? Enfin… tout le monde a une Rolex. Si à cinquante ans, on n'a pas une Rolex, on a quand même raté sa vie.
Jacques Séguéla, Les 4 vérités, France 2, 4 février 2009
[^] # Re: sinon...
Posté par lasher . Évalué à 3.
Mince, je ma mémoire me joue des tours. :(
Bon ben, pan sur le bec alors.
[^] # Re: sinon...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
C'est une blague, basée sur la situation d'origine (fictive) de quelqu'un qui serait pianiste dans un bordel, mais qui ferait croire à sa mère qu'il est [autre chose]. Là donc, cette situation est détournée, comme si utiliser systemd était vu comme quelque chose de honteux, et que l'auteur fasse donc croire à sa mère qu'il est pianiste dans un bordel, ce qui serait un métier honorable, plutôt qu'utilisateur de systemd.
[^] # Re: sinon...
Posté par Lutin . Évalué à 7.
Comme dans la bande dessinée Soda, le héro est policier et fait croise à sa mère qu'il est pasteur, pour qu'elle ne s'inquiète pas.
[^] # Re: sinon...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
C'est ça.
# Ca me fait penser au mac
Posté par Guillaume T . Évalué à 10.
Ca me fait penser au mac
Enfin une critique majeure et constructive concernant systemd
[^] # Re: Ca me fait penser au mac
Posté par ariasuni . Évalué à -1.
Tu nous le refais avec le bon formatage? Tu écris ça:
Et ça donne ça:
(sinon il y a l’aide mémoire que tu peux consulter lors de la rédaction d’un commentaire)
Écrit en Bépo selon l’orthographe de 1990
# Surprenant, non ?
Posté par gnutux95 . Évalué à 1.
Bonsoir,
Pour être honnête, j'ai trouvé surpenant la venue progressive de systemd dans les distributions : RHEL6/RHEL7/Debian Jessie/Arch Linux/… et toujours notre ami la distribution Ubuntu qui n'en fait qu'à sa tête avec Upstart :) mais ubuntu a certainement donné des idées à d'autres quant au choix de systemd.
le SysV c'est vraiment l'histoire découlant d'UNIX, un monument, le remplacer du jour au lendemain… ça fait un choc, mais je trouve que les changements/évolutions n'ont jamais été autant marqués que ces derniers temps… et cela ne s'arrête pas à systemd, les nouvelles commandes tel que ip address, ip rules, ip link etc… devant faire à terme des commandes existantes (tel que ifconfig / route …) depuis des dizaines d'années. L'industrie et les acteurs du monde s'y intéressent de plus en plus.
Quelques questions se posent :
Malgré l'accord entre la majorité des poids lourds des distributions, systemd sera t-il une mode ou deviendra t-il obsolète dans quelques temps ?
systemd doit permettre de mieux gérer le lancement des scripts avec les dépendances, cela semble noble, mais quid de la stabilité et de la pérennité.
Ces simplifications ne viennent-elles pas des besoins du monde de la virtualisation et par extension du "cloud" ? : faciliter l'accès/l'administration de linux tel OpenLMI en mettant une couche d'abstraction permettant à terme de faire des opérations depuis l'hyperviseur directement ou depuis l'interface d'administration du cloud ?
Ne va t-on pas devenu des pousses boutons ou certains ne souhaitent ils pas que l'on devienne des pousses boutons à force de mettre des niveaux d'abstractions et donc ne plus avoir besoin de comprendre pour l'utiliser ?
Linuxement
[^] # Re: Surprenant, non ?
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 25 septembre 2014 à 07:47.
Euh… Tu n'as sans doute pas suivi, mais le jour où Debian a annoncé qu'ils passaient à systemd, Canonical a annoncé… Qu'ils passaient à systemd.
Tu peux donc rajouter Ubuntu à la liste, c'est jsute une question de calendrier.
Justement, c'est un des buts de systemd, parce que tes scripts SysV qui cassent tous les 2 jours et à refaire dès que tu changes de distro, c'est lourd. C'est justement un but que pour les mainteneurs ça soit stable et perenne.
Et perenne jusqu'à quand? Ben si il y a mieux, prenons! C'est la vie. Pour le moment, du moins, rien en vue.
La machine est ua service de l'homme, et non l'inverse : pourquoi veux-tu que ce soit compliqué quand on peut faire simple? Tu dis juste que quand on peut avoir un presse-bouton, tu veux un ingé payé 100x plus cher qui va se faire plaisir à coder un truc qui… Fera la même chose. Ca n'a pas d'interêt.
Et cest très bien! Je ne veux pas comprendre. J'ai autre chose à faire que de comprendre toutes les machines dans ma vie. Et toi, sais-tu comment fonctionne tous les outils que tu utilises dans ta vie? jusqu'au dernier boulon? Non, car tu n'as pas la capacité d'apprendre tout. On permet juste aux gens qui veulent utiliser (leur but) d'utiliser, et aux passionné de mettre la main dans le cambouis (systemd ne t'en empèche pas, c'est plus dur qu'avec SysV, mais bon, pareil pour tout : la technologie évolue, plus de choses, donc plus complexe, normal).
Rappel : personne ne force à passer à systemd, tu peux te faire chier à continuer à maintenir le vieux bousin si tu as envie, juste que personne ne veut plus le faire à ta place, et , tu peux rester avec des fonctionnalités des années 1970 si tu as envie, jsute que d'autres veulent un truc qui fait plus de choses que gérer X25 ou IPX (oui, j'ai des souvenirs d'avant IP :) ).
[^] # Re: Surprenant, non ? finalement non...
Posté par gnutux95 . Évalué à 0.
Oui, bien vue.
On notera que certaine distribution y compris RHEL6/CentOS6 était muni d'upstart, la distribution ubuntu n'était pas seule avec upstart, mais c'était le bébé de Canonical…Ce n'était pas dit que systemd en sorte vainqueur…
Rq : GNU/Linux semble s'éloigner des programmes historiques commun UNIX (BSD ou System V) en ayant de plus en plus de spécifiques.
[^] # Re: Surprenant, non ? finalement non...
Posté par barmic . Évalué à 4.
Qui utilise sysvinit mis à part GNU/Linux ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Surprenant, non ?
Posté par Olivier Serve (site web personnel) . Évalué à -1.
Euh si, les distributions. Ou alors tu m'expliques comment rester sur Arch ou Fedora sans systemd ? Et pour rappel, il n'y a pas que SysV en dehors de systemd.
Et même si on ne l'utilise pas, on ne peut pas l'ignorer (comme pour pulseaudio, Gnome3 ou KDE4) car il phagocyte petit-à-petit tous les composants de base d'un système Linux moderne.
Mots de Lennart lui-même ( http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html ) :
we will not support non-systemd systems with udev anymore
C'est assez clair. udev fonctionnait bien sans systemd, et paf.
[^] # Re: Surprenant, non ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Pas mal ta blague.
Quelqu'un te force à utiliser Arch ou Fedora?
Pire : quelqu'un t'empèche de forker?
Ah oui, dure la vie en démocratie, ou on ne peut t'imposer une chose, mais en contrepartie tu ne peux pas imposer aux autres de bosser grato pour toi…
Donc : euh non, personne ne force à passer à systemd.
J'attends une démonstration qu'on te met une flingue sur la tempe pour y passer.
Tu peux totalement l'ignorer, rien de de rien ne t'es imposé. Mais par contre, les autres sont libres aussi… Saloperie de liberté!
[^] # Re: Surprenant, non ?
Posté par freem . Évalué à 2.
Qu'est-ce qui te force à utiliser udev?
[^] # Re: Surprenant, non ?
Posté par xcomcmdr . Évalué à 3.
Ce n'est pas si surprenant. systemd a prouvé qu'il était bien plus utile et utilisable que SysV. Ce qui aurait été surprenant, c'est que tout le monde l'adopte sans se poser de questions, ce qui n'a pas été le cas.
Oui enfin Ubuntu a prévu d'adopter systemd suite à l'adoption de systemd par Debian.
Bah systemd s'inspire de Upstart et launchd.
Bah ce n'est qu'un logiciel. Je comprends pas trop cet attachement.
Bah d'une part je vois pas en quoi c'est un mal de changer les logiciels. Surtout que ce n'est jamais changer pour changer (il y a des arguments techniques pour ip, pour systemd, pour wayland, … Et une implémentation qui marche plutôt qu'un énième standard théorique et irréaliste qui ne sera pas utilisé)
Bah tout logiciel naît, vit, est utilisé, et meurt. On l'a vu avec SysV, qui fut au final qu'une mode. ;-)
Si c'est la stabilité au sens "fiabilité", perso j'ai rien à reprocher à systemd de ce côté là.
Si c'est au sens Debian, je dirais que c'est OK :
- compatible avec les scripts SysV
- nul besoin d'écrire une unité pour la distribution X, une autre pour la distribution Y, et encore une autre pour la distribution Z. On l'écrit une fois et c'est réglé. Et ça fonctionne avec les futurs versions de systemd.
Vu que systemd a un code clair et accompagné de tests unitaires, et qu'il est bien plus documenté que ne l'a été SysV ou Upstart, je dirais qu'il est assez pérenne. :-p
Au delà, je crois que beaucoup de gens du libre confondent stabilité et immobilisme. A chaque fois que Linux change, les BSDistes disent que ça change encore uniquement pour changer (alors que ce n'est jamais le cas).
L'autre jour encore dans un édito d'un hors-série de GN/Linux pratique sur les systèmes *BSD (un "mook", il paraît), je suis tombé sur ces deux perles :
(je résume le troll de l'auteur avec la dernière phrase)
Peut être qu'en bougeant peu un logiciel peut donner l'impression d'être parfait. Mais pour moi c'est surtout le signe d'un manque de contributeurs, comme c'est le cas chez Xfce par exemple.
Et puis, en tant qu'utilisateur de Linux, l'avalanche de technologies noyau… Comment dire… Ah oui : ça touche une oreille sans faire remuer l'autre.
Oui, il y a des changements à une vitesse peut-être affolante. Mais :
1. Je vois pas en quoi ça devrait m'affoler. Au mieux, ça m'excite. ;-) (comme kf5)
2.Ça ne m'a jamais cassé ma distrib du jour au lendemain (même sous Arch ;-) ) car les développeurs noyaux font tout pour ne pas casser l'userspace, que les mainteneurs de distribs font leur boulot, et que ce sont ici des APIs noyau qui sont très loin de concerner l'utilisateur lambda.
l'auteur confond encore systemd le binaire qui ne s'occupe que de l'init, et systemd le projet qui regroupent des dizaines d'utilitaires qui font chacun une tâche et qui la font bien. ;-)
SysV n'était pas une bonne abstraction. On devait revenir tout le temps sur son script parce que la distribution X n'est pas compatible et qu'on avait écrit ce script avec la distribution Y à l'esprit. Quant à la compatibilité avec les *BSD dudit script, c'était encore une autre histoire…
Une abstraction qui m'oblige à savoir comment elle fonctionne pour l'utiliser, ce n'est pas une abstraction.
C'est juste du boulot pas intéressant en plus.
Ne va t-on pas devenu des pousses boutons ou certains ne souhaitent ils pas que l'on devienne des pousses boutons à force de mettre des niveaux d'abstractions et donc ne plus avoir besoin de comprendre pour l'utiliser ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Surprenant, non ?
Posté par zul (site web personnel) . Évalué à 2.
Avis à l'emporte-pièce. Ça dépend du projet, de ses buts et de son degré de maturité.
Y'a des gens qui font du developpement aussi, dans le noyal, ou plus généralement du système. Bref, ça peut être chiant. Que tu sois protégé par les distributeurs n'implique pas que ça ne pose pas de problème.
[^] # Re: Surprenant, non ?
Posté par gnumdk (site web personnel) . Évalué à 1.
Je vais rebondir la dessus, qui a déjà lu rc.sysinit sous RedHat/Mandrake? C'était juste le truc le plus moche que j'ai pus voir de ma vie, un script shell de plus de 1000 lignes si mes souvenirs sont bons…
Bref, vive systemd… Quand je vois mes serveurs Debian se vautrer au reboot à cause d'un service récalcitrant, je peux te dire qu'il me tarde systemd sous Debian.
[^] # Re: Surprenant, non ?
Posté par zebra3 . Évalué à 10.
J'ai beau aimer systemd, c'est pas encore pour demain. J'ai fait une petite unité pour lancer Apache sous Debian, ça ne fonctionnera pas sous RHEL : la première nomme le binaire apache quand la seconde l'appelle httpd…
Et ne parlons pas des chemins (/var/www contre /var/www/html ou /etc/apache2 contre /etc/httpd/)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Surprenant, non ?
Posté par freem . Évalué à 5.
C'est gênant, parce que c'est pourtant un des points qui étaient évoqués comme l'un des points forts de systemd, non? Ceci étant dit, je pensais que Debian aurait utilisé leur système d'alternatives pour un truc comme apache/httpd, je suis déçu quelque part.
[^] # Re: Surprenant, non ?
Posté par ariasuni . Évalué à 2. Dernière modification le 30 septembre 2014 à 00:23.
C’est un peu la faute à Debian (qui change le nom du binaire…). Mais bon, c’est pas comme si la modification était énorme (logiquement, une bonne partie du reste reste identique).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Surprenant, non ?
Posté par freem . Évalué à 1.
Je ne sais pas à qui la faute, et franchement je m'en moque. Quelque part, ça me semble pertinent de ne pas appeler apache httpd, puisqu'on pourrait imaginer installer plusieurs httpd sur la même machine.
Mais ils auraient pu utiliser le système d'alternatives (comme pour les éditeurs de texte, émulateurs de terminal, etc) pour fournir un lien symbolique vers le fichier qui va bien.
Ça aurait permis une meilleure généricité, non? Mais je suppose qu'il doit y avoir une raison.
[^] # Re: Surprenant, non ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Apache est le nom de l'entité.
httpd est le nom du logiciel faisant un serveur HTTP.
Google: httpd.
Aucune raison de changer le nom. D'autres serveurs HTTP peuvent s'appeler autrement, il cohabiteront car noms différents (après, si tu appelles ton serveurs HTTP "httpd" alorsq u'il y en a un qui existe déja, ben…).
Après, bon, voila, c'était une connerie historique, il faut vivre avec (mais sans pour autant trouver normal un renommage à l'arrache)
[^] # Re: Surprenant, non ?
Posté par barmic . Évalué à 3.
Ça deviendrais tordu quand tu utilise plusieurs serveurs web (par exemple nginx en reverse proxy d'apache).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Surprenant, non ?
Posté par Misc (site web personnel) . Évalué à 9.
L'unix de base ( celui des 70s ) n'avait pas l'air d'avoir un système de script d'init, si je regarde le code sur google code
https://code.google.com/p/unix-jun72/source/browse/#svn%2Ftrunk%2Ffs%2Froot%2Fetc
C'est donc arriver par la suite, dans les années 80. Et si je me souviens bien des headers de copyright, les scripts qu'on retrouve au moins sur les distros rpms datent de milieu/fin 90 sur Linux, donc pas très unix à la base.
Ensuite, Apple l'a remplacé du jour au lendemain ( lors de la release 10.4 ). Gentoo l'a remplacé du jour au lendemain ( genre dés le début ). Ubuntu l'a remplacé du jour au lendemain ( même si ils ont eu des journées longues ). Sun l'a remplacé du jour au lendemain ( sur solaris 10 ). Les BSD, qui sont bien plus Unix que Linux par définition n'ont pas sysvinit, sauf erreur de ma part.
Enfin, du jour au lendemain, tu veux sans doute dire "en 2 ou 3 ans".
Et autant que je sache, Solaris a encore le droit de s'appeler Unix, ce que la majorité des distributions Linux n'ont jamais eu le droit. Donc si Solaris et Apple sont assez "Unix" pour l'open group ( que OS X 10.7 avait la certification, et je doute pas que Solaris aussi ), je pense qu'il faut pas être plus royaliste que le roi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.