Sommaire
Salut Journal,
Aujourd'hui, je me suis forcé à faire un peu de veille technologique afin de me préparer aux prochaines mises à jour de mes serveurs.
Je te le dis tout de suite: j'ai un gros a priori sur systemd. Je ne suis pas un dinosaure, mais en 20 ans j'ai pris mes petites habitudes, et à vrai dire l'init SystemV est une des choses qui m'a séduit à mes débuts (quoi qu'on en dise, personnellement, j'avais trouvé ce système simple et élégant).
En plus de ca, tout ce que j'ai pu lire sur systemd ne me rassurait pas.
Alors c'est parti, je me lance, une installation de RHEL7.
Bon, des choses ont changé, mais je recherche surtout ce qui est lié à systemd.
/etc/inittab
Alors ca c'est sympa, l'inittab est là. Certes il ne sert plus a rien, mais un commentaire indique comment gérer le Ctrl-Alt-Del et le runlevel par défaut.
Pour le runlevel, c'est simple, il suffit de faire un symlink de /lib/systemd/system/multi-user.target vers /etc/systemd/system/default.target. Bon, ok. Ma mauvaise foi me pousserait bien à dire que les paths sont un peu chiants à taper (la complétion n'aide pas trop), mais honnêtement, je trouve ca tout aussi bien comme technique.
Le Ctrl-Alt-Del est géré par /etc/systemd/system/ctrl-alt-del.target. Souci, il n'est pas présent. C'est pas grave, je vais voir dans /lib/systemd/system/, il est bien là, je vois qu'il est prédéfini pour un reboot. En principe, je désactive cette combinaison de touche dangereuse en faisant un echo plutôt qu'un reboot. Je me dis que vu que le lien n'est pas fait dans /etc/systemd/system/, le reboot est bien désactivé. Je tente… bon ben ca reboot. Râté.
En 2 secondes, je trouve la solution sur le net: ln -s /dev/null /etc/systemd/system/ctrl-alt-del.target … mouais.
chkconfig
Pour ceux qui ne sont pas familiers avec RHEL, chkconfig --list permet de lister les services lancés (ou non) au boot. Je tente et la pareil, on m'indique que maintenant il faut voir la commande systemctl list-unit-files. Ca fonctionne, j'en ai 325… soit 5 fois plus d'entrées que je n'avais sur une config équivalente de RHEL6.
Là encore, je pourrais être de mauvaise foi, mais cette commande est (je pense) volontairement verbeuse. systemctl list-units est déjà plus raisonnable.
Note pour plus tard: regarder tout ca.
mount
Je ne sais plus trop pourquoi (par réflexe sûrement), je regarde ce qui est monté. Le résultat fait 28 lignes, 11 pour des cgroups. Bon, là j'avoue que je ne connais pas trop ces histoires de cgroups, et puis systemd n'est peut-être pas le seul fautif. N'empêche que ca commence à me faire mal aux yeux.
Note pour plus tard: regarder tout ca.
config réseau
Là encore j'ai mes petites habitudes: je désactive NetworkManager:
systemctl stop NetworkManager
systemctl disable NetworkManager
Je fais mes modifs dans /etc/sysconfig/network-scripts/ et je redémarre le "old-fashioned" service… oui mais lequel? En faisant mon chkconfig tout à l'heure, j'ai vu qu'il y avait encore le service "network" mais j'ai vu un service de ce nom dans systemctl list-unit-files… Je regarde dans /etc/systemd/system/, pas de symlink pour network, du coup je lance façon SysV: /etc/init.d/network start. Bizarre, j'ai le message "Starting network (via systemctl)" et effectivement cette commande fait la même chose que systemctl start network. ah… ma théorie comme quoi les services effectivement démarrés sont dans /etc/systemd/system/ s'écroule pour de bon.
Les Unit files dans /lib/systemd/system/ ne m'apprennent pas plus de choses (network et network-online contiennent seulement une description et un lien vers la doc, j'ai lu le man une fois, j'ai pas mieux compris). Systemd démarre mon réseau, mais je ne sais pas comment.
Note pour plus tard: prendre un doliprane, relire le man.
firewall
Un peu par réflexe, je fais un iptables -L. euh, wow… firewalld doit faire partie de l'install par défaut. Résultat: je n'ai encore rien configuré que j'ai déjà 24 chaînes… Les gars, franchement… c'est bien gentil de me mâcher le travail, mais si je pouvais organiser ma machine comme je veux…
Note pour plus tard: regarder tout ca penser à désactiver firewalld.
fstab
J'ai tenté un "bug" connu, à savoir: que se passe-t-il si une entrée dans fstab ne peut pas être montée lors du boot?
Alors c'est parti, je m'invente un sdb1 à monter dans /mnt avec les options par défaut.
Effectivement, au boot, j'ai un timeout puis le choix de retenter ou d'entrer dans un shell de secours. Sympa, on m'indique la commande journalctl -xb pour m'aider à trouver l'erreur. Je regarde dedans mais il faut dire qu'il ne faut pas être pressé de booter: l'erreur apparaît bien, mais un peu plus de 400 lignes avant la fin du-dit log.
Le côté sympa s'arrête donc là: je vois l'erreur, mais aucune idée de ce qu'il faut faire pour passer outre.
Là encore, internet est notre ami: la solution est systemctl mask mnt.mount, ce qui bazarde le lien symbolique correspondant. Ca veut dire qu'au prochain reboot, si je ne pense pas à faire un "unmask", alors le disque ne sera pas monté.
Ca veut aussi dire que si une chose de ce genre m'arrive, j'ai intérêt à avoir une version papier de la doc de systemd, parce que sans accès à internet, je risque de mettre du temps avant de démarrer mon pc…
Note pour plus tard: acheter un deuxième PC et penser à ne jamais les rebooter en même temps.
Conclusion
Comme je le disais, j'ai un a priori, donc je ne suis pas objectif. Ceci dit, quand je me suis mis à Unix, je n'ai jamais éprouvé le besoin de lire la doc de SysV. Ce côté assez "simple" et "transparent" de la phase d'init a disparu avec systemd. (C'est d'autant plus dommage que systemd n'a pas seulement un impact sur la phase de boot).
Après, il faut dire que les mainteneurs des différentes distributions ont bien travaillé. Je m'attendais franchement à tomber sur des "No such file or directory" quand j'allais lire /etc/inittab. Au lieu de ca, j'ai qqs lignes qui m'expliquent la nouvelle procédure.
Il reste plein de choses à voir, là j'ai seulement joué avec durant 30 minutes. Mais finalement, je n'ai pas fait de gros blocage et il y a des solutions à tout.
Malgré tout, avant le passage en prod, je crois que le passage obligé c'est RTFM (et ca c'est la vraie conclusion!)
Allez… dans qqs heures c'est vendredi!
# firewalld et systemd
Posté par Storm . Évalué à 10.
Juste une petite précision, firewalld n'est pas (encore ? ;)) un morceau de systemd : c'est un projet séparé (qui a dit "pour le moment ?" :d), hébergé chez Fedora : https://fedorahosted.org/firewalld/
[^] # Re: firewalld et systemd
Posté par zurvan . Évalué à 10.
le parefeu
openofficelibreoffice est bientôt prévu également :https://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/posts/VUzeRLf5g5m
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: firewalld et systemd
Posté par pingoomax . Évalué à 1.
Hahaha, j'ai eu la même surprise.
Perso, j'ai laissé activé firewalld sur mon laptop pour pouvoir appréhender cette conf tranquillement. En prod :
et la… on retrouve nos petites habitudes.
# .
Posté par Sufflope (site web personnel) . Évalué à 4.
Je pense que t'as mal lu le dit commmentaire. Plutôt que te faire chier avec les chemins : systemctl set-default TARGET.target
Je veux bidouiller moi-même mais je ne veux pas lire la moindre ligne de man
cat << EOSARCASM
Oui moi aussi j'ai immédiatement trouvé les fichiers /etc/rc.d/K92initmoncul symlink vers /etc/rcX.d/K92initmoncul eux-mémes symlink vers /etc/init.d/truc hyper clairs
EOSARCASM
Encore un journal anti-systemd (encore que celui-ci est plus doux, enfin passif-aggressif, que les il faut tuer Lennart pour venger le prophète SysV) dont la vacuité des critiques renforce mon appréciation de systemd.
[^] # Re: .
Posté par Albert_ . Évalué à 10.
Et le coup du systeme qui demarre pas parcque il y une ligne non utile dans le fstab c'est un comportement que tu trouves:
Je propose pas les choix cela serait inutile je sens:
[^] # Re: .
Posté par Vincent Bernat (site web personnel) . Évalué à 10.
sdb1peut très bien apparaître plus tard. Du coup, systemd attend un certain temps plutôt que de ne pas monter le bidule. En l'absence d'indication contraire (notamment de la présence de l'optionnofail), il ne démarre pas d'autres services car ceux-ci pourraient avoir besoin de ce point de montage./etc/fstabne permet pas d'exprimer des dépendances très complexes. Cela ne serait pas le cas avec un point de montage défini sous forme d'unit (en.mount).[^] # Re: .
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 10.
Ben d'après le journal ce qui se passe c'est que :
Je trouve que ça mangerait pas de pain de proposer une option supplémentaire pour continuer le démarrage en ne montant pas cette partition ce coup-ci.
[^] # Re: .
Posté par Maclag . Évalué à 10.
Je suis sûr que si c'était possible, d'autres râleraient en disant que systemd autorise à démarrer avec des partitions critiques pas disponibles sur une simple question.
[^] # Re: .
Posté par Albert_ . Évalué à 5.
Alors que la au moins il ne demarre absolument pas le systeme c'est encore mieux. Prenons un exemple con avec un disque qui est mort de sa belle mort physique. Certe cela n'arrive jamais mais bon en fait si cela arrive et au lieu de booter sur un systeme qui permettrait d'analyser correctement le probleme il faut aller chercher dans un log immense.
Je suis bizarre mais je ne trouve pas ce comportement comme etant tres user friendly mais bon je suis bizarre comme tout le monde le sait.
[^] # Re: .
Posté par Misc (site web personnel) . Évalué à 9.
Ca me parait une bonne idée, oui, est ce que tu peux ouvrir un bug sur le sujet ?
[^] # Re: .
Posté par GeneralZod . Évalué à 6.
T'as pas honte de proposer des actions constructives ? En plus un trolldi !
Et comment qu'on va troller sur systemd si c'est corrigé ?!
[^] # Re: .
Posté par hervé Couvelard . Évalué à 8.
Nan, le truc c'est que les vieux qui connaissent leur système à force d'habitude et de travail, ce sont des vieux cons de ne pas vouloir changer et ils vont devoir se retaper des palanquée de page de man pour trouver des infos cryptiques ou trouver dans des forums des abrutis qui plutôt que de donner la réponse à une question lui répondent : "bah veut même pas regarder les pages de man".
Sauf que quel page de man tu regardes lorsque le réseau ne démarre pas ? quel page de man tu regardes pour trouver que systemd gère ton réseau et que si tu désinstalles pas network-manager pour le wifi c'est que pouic.
systemd est bien trop jeune pour que l'on trouve suffisamment d'information sur le net lorsque l'on est confronté à des soucis et donc forcément on a envie de conchier violemment le mec qui a changé le truc et qui te laisse désemparé parce que ton système ne veut pas démarrer. Si en plus tu as vécu la mise en place de pulsaudio (que je désactive par habitude du coup), tu as un peu de mal à tendre l'autre joue.
Alors je sais bien que si je suis pas content, j'ai qu'à maintenir une branche sans, ou même changer de distribution, mais on se plaint de microsoft avec embrace et extend et lorsque red hat phagocyte petit à petit des briques essentielles et se rend de fait obligatoire j'ai la même réaction que face à microsoft qui implémente un java de merde ou un javascript de merde. D'ailleurs tu peux tout à fait maintenir une branche de java ou javascript pour microsoft qui respecte les standards java plutôt que de râler, mais c'est zarb tout le monde râle quand c'est microsoft et ceux qui râlent quand c'est lennard ce sont des vieux cons aigris qui veulent pas changer…
[^] # Re: .
Posté par xcomcmdr . Évalué à 8. Dernière modification le 12 février 2015 à 20:22.
WUT, systemd est bien plus documenté sur son site officiel que ne l'ont été SysV ou Upstart.
Et network-manager n'a RIEN à voir avec systemd.
bla-bla, rien à voir.
D'abord systemd c'était au début un projet de Lennart, et il a fallu batailler au sein de RedHat pour que le projet soit accepté.
Ensuite, embrace, extend, and extinguish ça n'a RIEN à voir. Ca veut dire se conformer à un standard ouvert ou ISO (exemple : kerberos), lui rajouter des extensions proprios, et remplacer finalement le standard par un standard de fait propriétaire, à force de prendre des parts de marché.
Ici, c'est du logiciel libre, donc déjà c'est même pas comparable.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: .
Posté par hervé Couvelard . Évalué à 10.
Ouais rien à voir sauf sur une distribution qui installe les 2 et paff le wifi.
Sur la documentation tu biaises la question : documenter sysV ou autre n'a aucune espèce d'importance parce que tu as des scripts dans des dossiers et il ne se lance QUE ces scripts. Il ne gérait pas effectivement les dépendances, tu devais le faire tout seul avec les numéros de scripts. C'est pas si simple, mais ce n'est pas si complexe non plus. Dans le doute tu le mets à la fin. Bien entendu ce n'est pas optimum. mais ça avait le mérite d'être simple à comprendre et simple à appréhender. Lorsque tout se lance en parallèle, tu peux avoir du mal à savoir OU ça plante.
De toute façon, plus un soft fait de chose, plus il est complexe et plus il est compliqué à appréhender. Chacun choisi le degré de performance et le degré de compréhension qu'il veut. C'est marrant, ici pratiquement tout le monde va conchier un code cryptique qui fait son boulot avec compétence et rapidité mais compliqué à comprendre et tout le monde va préférer un code moins performant mais plus lisible et simple à comprendre.Pour systemd c'est l'inverse, ca ne fait que m'interroger. Par contre, toi tu es certain que blablabla rien à voir. À la hache que je te sabre, juste parce que je trouve que ce n'est pas la révolution tant attendue.
Que systemd soit plus documenté qu'un autre truc ne va pas t'aider avec les messages d'erreur, lorsque tu cherches avec un message d'erreur, ca ne te renvoie JAMAIS vers une doc officiel mais avec les réponses dans un forum de quelqu'un qui a résolu la question. Par exemple avec TA réponse entre systemd et network-manager tu vas induire celui qui a un soucis en erreur. Ils n'ont rien a voir SAUF que les 2 gèrent le réseaux (faut le savoir hein que systemd gère le réseau tout seul nativement sans rien lui demander) et si tu installes nm, il va regèrer le réseau par dessus et va faire planter la carte wifi.
J'ai passé une après midi à comprendre pourquoi le réseau ne marchait pas, mais marchait lorsque je le lançais à la main en ayant auparavant éteind/rallumé la carte wifi. Et je n'ai trouvé, sur le net (français, anglais,espagnol) AUCUNE piste, j'ai du me démerder tout seul pour comprendre. De mon point de vue c'est une régression. Et le truc le plus marrant, lorsque j'en parle il y a quelqu'un qui n'a JAMAIS vu le problème mais qui est CERTAIN que ça n'a aucun rapport, alors que je SAIS que c'est lié. Je ne peut pas dire QUI est responsable, mais je peux te dire que c'est lié, très lié même.
Alors si tu veux ton opinion est très loin de pouvoir me faire changer d'avis.
[^] # Re: .
Posté par vv222 . Évalué à 3.
Bien sûr.
Debian Jessie (version GNU/Linux) installe par défaut systemd et network-manager (appelé en dépendance de GNOME).
Et il est bien connu qu’il est impossible d’utiliser une connexion WIFI sous Debian Jessie. Ce qui me fait me demander comment le PC portable posé sur mon bureau fait pour se connecter à Internet sans câble.
Après il est tout-à-fait possible que ta config perso de network-manager soit incompatible avec systemd, mais dans ce cas est-ce la faute de systemd, de network-manager ou… de l’administrateur de la machine ?
[^] # Re: .
Posté par freem . Évalué à 6.
Network over butterfly?
[^] # Re: .
Posté par groumly . Évalué à 10.
Parce que bien sur, les scripts d'init eux sont largement documentes, simple a comprendre et tout, quand quelque chose pete, c'est limpide de comprendre pourquoi et de detricoter le merdier…
C'est a se taper le cul par terre les debats sur systemd. Oui, l'ingienerie c'est complique, que ca soit systemd ou sysv, et oui, l'informatique change en permanence. Est ce qu'on peut arreter ces debats puerils sans fin, en plus d'etre inutiles?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: .
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
Je crois que tu viens de mettre le doigt sur un problème psychologique et non technique. On accusera toujours plus facilement le petit nouveau de "foutre la merde", mais jamais l'ancien qui est là depuis toujours.
"La première sécurité est la liberté"
[^] # Re: .
Posté par gnumdk (site web personnel) . Évalué à 0.
De toute façon, les anti systemd, c'est juste la réaction de gens qui n'ont pas envie d'évoluer, un peu comme ces admins qui ont des boutons quand tu leur parles de Linux…
Ce sont exactement les même boulets que l'on se traine tous dans nos boulots :-(
[^] # Re: .
Posté par fearan . Évalué à 7.
c'est des scripts, c'est auto documenté :P
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: .
Posté par Maclag . Évalué à 10.
C'est vrai, quand tu fais une recherche sur systemd, les premiers résultats sont le plus souvent de longues déclarations haineuses qui mentionnent vaguement le problème rencontré et pas la solution, au milieu des complots et le reste.
À la fin, ton problème n'est pas résolu, mais au moins tu as appris que Lennart est un extra-terrestre envoyé par la planète GJtnghht pour détruire l'humanité, tout comme Bill Gates et Rebecca Black.
[^] # Re: .
Posté par zurvan . Évalué à 3.
Je souscris entièrement à ton commentaire.
Je trouve sysv assez imbuvable, dans le genre d'init la méthode BSD, que l'on retrouvait sur feu archlinux, était vraiment le top, juste un fichier unique à modifier pour activer, désactiver un service ou un module, mais à côté du marasme systemd on va finir par regretter quand même sysv…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: .
Posté par Padishah . Évalué à 10.
Des scripts shell dans /etc/init.d avec des symlinks vers rcX.d je trouvait cela propre et assez basique à comprendre. Le contenu des scripts, c'était pas non plus la mer à boire.
[^] # Re: .
Posté par Albert_ . Évalué à -7.
Impressionnant les notations sur mon message au dessus. Cela montre a quel point les opinions sur systemd sont partages:
10 + versus 9 -
Bon desole je dois sortir la, j'ai ma reserve de pop-corn qui diminue mais continuer je m'amuse bien.
[^] # Re: .
Posté par apkwa . Évalué à 10.
Euh non, j'ai cité le commentaire qui dit bien de faire un ln -sf. D'ailleurs, si je lance ta commande telle quelle, j'ai un
Failed to issue method call: File exists(oui, je sais).Je ne veux pas bidouiller, je constate. Je ne vais pas me farcir toute la théorie de systemd dans les moindres détails AVANT de voir à quoi ca ressemble. Certes ce serait mieux, mais que celui qui lit toute la doc de tel logiciel avant de le lancer me jette la première pierre. Là je ne fais pas une mise à jour d'un programme critique. On met un nouveau PC sur mon bureau et je regarde comment ca a l'air de fonctionner (d'autant plus que malgré tout j'ai lu beaucoup de choses sur systemd, je vois à peu près son fonctionnement global, et j'essayais juste de mettre les différentes pièces ensemble).
Ben j'ai peut-être l'esprit tordu, mais oui, ca m'a paru clair. Ceci dit, je conçois que ca ne soit pas le cas pour tout le monde. Moi quand on me dit que Ruby est un langage super simple et clair je reste béat.
Ce n'est pas le sens que je voulais donner. Désolé si c'est ce qui apparaît.
Quand on lit les journaux sur systemd, c'est toujours un discours de sourds. On a:
- les anti-systemd qui le sont par principe mais ne l'ont jamais testé
- les pro-systemd qui gueulent dès que la moindre critique (même justifiée) apparaît
Entre les deux, il y a quand même un paquet de gens et je pense être de ceux-là.
[^] # Re: .
Posté par SChauveau . Évalué à 10.
Il me semble que le problème de ton journal est que tu décris systemd par rapport à ce que tu avais l'habitude de faire avec sysv. C'est compréhensible mais beaucoup de choses ne marchent évidemment plus donc ton journal ne peut que donner une vision négative de systemd même si ce n'était pas ton intention.
Le fait que les distributions conservent une couche de compatibilité avec sysv n'améliore pas la situation car les utilisateurs, moi compris, ont plutôt tendance à se tourner vers les interfaces qu'ils connaissent et qui deviennent progressivement obsolètes. J'expérimente actuellement systemd sous Debian. Cela fonctionne bien mais quasiment tout sysv est encore présent (/etc/init.d , /etc/inittab, …) et je serais bien incapable de dire ce qui est encore utilisé.
[^] # Re: .
Posté par reynum (site web personnel) . Évalué à 10.
Tu exagère même si il dit lui même qu'il a un a priori, je l'ai trouvé relativement pragmatique dans ses propos.
kentoc'h mervel eget bezan saotred
# services
Posté par SChauveau . Évalué à 10.
J'ai aussi passé quelques minutes à explorer systemd récemment.
Je trouve aussi que le nombre d'entrées fourni par systemctl list-units est un peu trop grand pour être lisible. C'est surtout parce que les services sont des
'units' parmi d'autres. Il faut filtrer.
Par exemple, pour voir uniquement les services actifs
Pour voir tout les services
Il est aussi possible de spécifier un pattern
Pour inspecter la définition d'un service on pourra utiliser la commande cat
Il est clair que systemd n'a pas été fait pour être entièrement bidouillable à la main comme pouvait l'être SysV. Cela reste généralement possible mais ce n'est pas convivial et quasiment tout est censé se faire via systemctl.
[^] # Re: services
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
En parlant de services, le travail d’intégration fourni sous RHEL/Centos 7 pour la commande
serviceest excellent et permet d'effectuer la transition en douceur.service httpd start invoquera systemctl start httpd.service
service network start invoquera /etc/init.d/network start
[^] # Re: services
Posté par claudex . Évalué à 9.
Et sous Debian
(en regardant vite fait, je ne vois pas où est fait l'appel à systemd, parce que le script a l'air d'être doté de quoi fonctionner systemd).
Par contre, la commande service sous Debian ne fait qu'un appel à systemd (si présent) qui lui-même appellera le script dans /etc/init.d s'il n'y a pas de .service correspondant.
« 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: services
Posté par nud . Évalué à 7.
C'est fait via /lib/lsb/init-functions, qui est sourcé au début de la plupart des scripts présents dans /etc/init.d. Le fichier installé par systemd (/lib/lsb/init-functions.d/40-systemd/) appelle systemctl et exite s'il détecte que systemd est en train de tourner.
# tu t'y prends mal.
Posté par Le Gab . Évalué à 10.
Je n'ai pas encore testé systemd mais je vais devoir le faire et je le ferai d'abords à l'aide d'une documentation de référence, au hasard la documentation de RHEL 7.
Quitte à voir comment se comporte systemd quand il rencontre tel problème, autant le faire avec méthodologie.
Et au final, 30 min c'est très peu. Il y a tout de même un énorme travail d'infrastructure derrière systemd alors oui, on ne se tape pas toute la documentation de long en large avant utilisation mais il me semble que tu voulais l'utiliser dans une optique professionnelle et bien, il va falloir le faire avec professionnalisme. :)
Après, il est tout aussi possible que tu n'aimeras plus jamais GNU/Linux. :)
# RHEL et les init modernes
Posté par Tonton Benoit . Évalué à 8. Dernière modification le 13 février 2015 à 00:04.
Je comprends que tu testes systemd avec une RHEL7 si c'est ce que tu va utiliser dans le futur, mais je ne suis pas sur que se soit la distribution qui présente cet init sous son meilleur jour.
DISCLAIMER: Je n'ai pas encore sérieusement testé RHEL/CentOS 7
Rappelez-vous RHEL6 avec upstart. Une version d'upstart tellement vielle quelle ne gérais même pas la désactivation d'une unité. Un upstart tellement mal utilisé qu'il n'était placé qu'en sandwich entre le rc.sysvinit et le reste de l'init classique à base de scripts dans /etc/init.d
Oui, c'est ironique vu que c'est au sein de RedHat que systemd est développé mais RHEL a un tel besoin de compatibilité ascendante et de fournir une interface stable pour les progiciels tiers genre Oracle que l'intégration d'un nouvel init se fera forcement à grand coup de masse et le résultat mettra plusieurs release majeures avant d'attendre le niveau, ne serait-ce que d'une Arch. À la condition, encore, que RHEL ne re-change pas d'init pour la prochaine version.
# systemctl list-unit-etc.
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Amusant, je ne me suis pas encore du tout penché sur le pourquoi du comment de systemd, mais sur mon Ubuntu actuelle :
Bon il va falloir que je me tape les centaines d’entrées, et sans mauvaise foi. :p
Quelqu'un pour expliquer ce qui se passe ? Les données de
list-unit-fileset delist-unitssont pas fournies par la même ressource ?ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: systemctl list-unit-etc.
Posté par Tonton Benoit . Évalué à 4.
Ubuntu a DÉJÀ migré ?!
Faut que je me mette à jour moi… :D
Sinon sous Gentoo, les deux marchent :
[^] # Re: systemctl list-unit-etc.
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Je ne suis pas sûr que systemd y soit déjà par défaut, mais il y est déjà disponible, oui.
J’utilise quelques dépôts ppa testing pour Ubuntu-Gnome / Gnome-Shell, et je pense que dans l’hypothèse où systemd ne serait pas encore par défaut, la dépendance systemd serait venue de là.
Personnellement je n’ai pas à y toucher et ça marche tout simplement.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: systemctl list-unit-etc.
Posté par nigaiden . Évalué à 6.
Tu es certain que systemd est vraiment utilisé ? Par exemple un "cat /proc/cmdline" t'indique-t'il explicitement que l'init se fait avec systemd ?
Tes commentaires me donnent l'impression qu'il a été installé par le jeu des dépendances pour avoir un libsystemd.so ou quelque chose comme ça, mais qu'il n'est pas lancé au démarrage. Le "list-unit-files" t'indiquerait tout ce qui peut être potentiellement géré, et "list-unit" t'indiquerait ce qui l'est vraiment - c'est-à-dire rien du tout puisque c'est probablement upstart qui tourne.
[^] # Re: systemctl list-unit-etc.
Posté par SChauveau . Évalué à 3.
La distinction entre list-units et list-unit-files est expliquée dans la documentation;
The list-units command only displays units that systemd has attempted to parse and load into memory. Since systemd will only read units that it thinks it needs, this will not necessarily include all of the available units on the system.
En gros, chaque unit est décrite par un fichier mais systemd ne charge que ceux dont il a besoin. list-units indique donc les units qui ont été chargés par systemd depuis le début alors list-unit-files les donne tous.
Une analogie un peu foireuse avec sysv est que list-units donne les services utilisés dans le runlevel actuel alors que list-unit-files donne tout les services disponibles dans /etc/init.d/ (mais c'est approximatif car un unit non activé pour le runlevel actuel peut quand même être chargé (mais pas démarré) par systemd si il est référencé par un autre unit).
Concernant le grand nombre d'units, le problème est que tous ne sont pas des services dans le sens de sysv. Par exemple, chaque mount est un unit et il y a aussi des 'target' qui correspondent à des ensembles d'units comparable au runlevel de sys).
Pour ne voir que les services, il faut passer l'option -t service ou utiliser le pattern '*.service'
[^] # Re: systemctl list-unit-etc.
Posté par gnumdk (site web personnel) . Évalué à 5.
Ubuntu n'utilise pas systemd, mais il est vrai que les commandes sont dispos on ne sais pas trop pourquoi…
[^] # Re: systemctl list-unit-etc.
Posté par freem . Évalué à 3.
Peut-être pour faire les choses plus en douceur?
[^] # Re: systemctl list-unit-etc.
Posté par freeze . Évalué à 3.
L'installation par défaut n'utilise pas systemd, mais il est possible d'installer un paquet systemd-sysv pour basculer complètement dans le merveilleux monde de systemd, avec tout ce qu'il faut pour utiliser selon les services les .unit ou les fichiers dans /etc/init.d
Bref, la transition est en cours.
# ...
Posté par M . Évalué à 1.
Moi aussi j'ai installé une machine avec systemd.
Et ben c'est magique. J'ai le réseau qui se configure tout seul sans aucune entrée dans /etc.
Ça fait bizarre, on dirait que ta machine pense à ta place.
J'ai pas encore tenté de voir ce qui se passe si je rajoute une entrée dans /etc/network/interfaces.
[^] # Re: ...
Posté par Katyucha (site web personnel) . Évalué à 10.
Justement le coté magique, je n'aime pas, sinon je ferai du windows. Quand j'installe un système, je veux le maitriser de bout en bout.
Alors comme l'auteur de ce Nal, je commence à me mettre doucement dans systemd.
J'avais bien réussi ma migration sous Solaris entre l'init et la SMF parce que cette dernière est moins intrusive que Systemd.
Pour l'instant, je suis dans le même cas que l'auteur du Nal: assez sceptique, 15 ans de commandes de gestion de boot / service à revoir. Pas si simple
[^] # Re: ...
Posté par SChauveau . Évalué à 2.
Es tu certain qu'il ne fait pas tourner NetworkManager ou le script /etc/init.d/networking de SysV? c'est que ma Debian Jessy fait actuellement,
Si il utilise systemd-networkd alors la configuration de chaque interface devrait être dans un fichier .network.
Ils peuvent se trouver dans plusieurs endroits: voir 'man systemd.network'. Je ne serais pas surpris que le système configure DHCP par défaut sur toutes les prises Ethernet.
Je n'ai pas encore essayé d'activer systemd-networkd sur ma Jessie. La configuration n'a pas l'air difficile mais je comprend comment on peut activer et désactiver individuellement les interfaces réseaux. Je n'ai pas l'impression que l'on puisse encore utiliser ifup & ifdown. Est ce que les '.network' sont aussi des units qui peuvent être gérées par systemctl? Je n'ai fait que parcourir très brièvement les docs.
[^] # Re: ...
Posté par claudex . Évalué à 4.
J'ai fais des tests avec networkd sur ma tour et effectivement, je n'ai pas trouvé comment faire des ifup/ifdown. Pire, si on fait un
ip l set down dev eth0, un up ne va pas relancer la reconfiguration de l'interface.Pour moi, ce n'est clairement pas à utiliser sur des machines physiques mais sur des conteneurs (en tout cas, pour l'instant).
« 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: ...
Posté par totof2000 . Évalué à 1. Dernière modification le 14 février 2015 à 12:48.
???? Ca sert à quoi de l'avoir à plusieurs endroits ?
[^] # Re: ...
Posté par Prosper . Évalué à 6.
A faire de la surcharge de configuration
[^] # Re: ...
Posté par SChauveau . Évalué à 7.
Dans man serviced.network
Donc si comprend bien l'idée sous-jacente l'ordre de priorité est /etc/systemd/network pour la configuration manuelle
puis /run/systemd/network pour les configurations automatiques temporaires (du genre NetworkManager. /run est généralement un ramdisk) puis /lib/systemd/network pour des configurations par défaut (du genre DHCP sur tout les ports ethernet)
En fait c'est une configuration assez futée. J'ai toujours été agacé par les outils qui écrasent les fichiers de configuration dans /etc/.
# L'argument kitu
Posté par reynum (site web personnel) . Évalué à 3.
Moi je m'en fou, j'aime bien systemd il boot mon PC rapidement ! :-D
kentoc'h mervel eget bezan saotred
[^] # Re: L'argument kitu
Posté par David Demelier (site web personnel) . Évalué à 2.
Personnellement, ma Fedora 21 boot bien plus lentement que mon ancienne Ubuntu 14.10. Et elle boot même plus lentement que ma FreeBSD (et dieu sait à quel point FreeBSD c'est pas ce qui a de plus rapide pour le temps de boot).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: L'argument kitu
Posté par gnumdk (site web personnel) . Évalué à 0.
Pour la simple et bonne raison que systemd accélère le boot sur les SSD…
Sur un XPS 13, Fedora et ArchLinux, c'est le boot en 2 secondes… Debian SID, c'est pas encore ça vu que c'est toujours du systemd+sysv
[^] # Re: L'argument kitu
Posté par neil . Évalué à 3. Dernière modification le 13 février 2015 à 18:37.
Tu as des références pour cette affirmation ? Sur un système avec SSD qui bootait il y a cinq ans en 3–4 secondes, je n’ai pas d’amélioration depuis le passage à systemd. Je croyais au contraire que les améliorations de vitesse concernaient les utilisateurs sans SSD. Peut-être que le noyau met plus de temps et que systemd beaucoup moins, mais je n’y crois que peu.
[^] # Re: L'argument kitu
Posté par SChauveau . Évalué à 3.
Comparer les vitesses de boot c'est un peu comme comparer la taille de sa … :-)
Sérieusement, il y a tellement de facteurs qui peuvent affecter la vitesse de boot que cela n'a généralement aucun sens.
Si vous voulez être constructif, passez un coup de bootchart et postez le résultat (si possible après avoir actualisé readahead).
[^] # Re: L'argument kitu
Posté par Prosper . Évalué à 5.
Ce qui n'a pas grand intérêt avec un SSD.
[^] # Re: L'argument kitu
Posté par SChauveau . Évalué à 2.
En effet. Les SSD ont un 'seek time' quasiment nul mais ils sont généralement optimisés pour des accès par grand blocks de 2Mo ou plus. Je ne sais pas si readahead peut en tirer partie surtout que les mecanismes de wear-leveling complexifies probablement les choses. Cela se mesure.
[^] # Encore une victime de Lennart
Posté par Arthur Accroc . Évalué à 5.
C’est fini readahead (lien qui ne pointera plus au bon endroit quand le fichier grandira), depuis systemd 217 : « systemd's readahead implementation has been removed. In many circumstances it didn't give expected benefits even for rotational disk drives and was becoming less relevant in the age of SSDs. As none of the developers has been using rotating media anymore, and nobody stepped up to actively maintain this component of systemd it has now been removed ».
Avec systemd-readahead, mon portable (sous Arch avec disque dur classique) démarrait aussi rapidement qu’avant systemd (où après le début du boot et le lancement de dbus, je lançais presque tous les services en parallèle), maintenant, il démarre plus lentement, sûrement du fait du nombre de fichiers d’unités de systemd à lire.
Côté Fedora, dont le démarrage n’est traditionnellement pas rapide, la plus rapide à démarrer (sur des machines à disque dur classique) m’a semblé être la 15, celle où systemd fonctionnait en mode compatible (donc avec beaucoup moins de petits fichiers à lire). Depuis, c’est allé en ralentissant (passage au mode natif avec tous les petits fichiers d’unités, disparition de readahead), même s’il me semble que ça reste quand même plus rapide qu’avant systemd (où le démarrage était séquentiel).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Encore une victime de Lennart
Posté par totof2000 . Évalué à 5.
L'excuse pour ne pas continuer à le développer est quand même complêtement bidon : Prétendre que les développeurs n'ont pas de disque classique mais que des SSD pour ne plus maintenir leur développeent, c'est vraiment n'importe quoi. Ca me quand même des doutes sur la vabilité du projet en lui-même : si les développeurs ne continuent pas à maintenir leur produit sur des technologies que eux jugent obsolètes (alors que les disques non-ssd sont toujours présents), il y a de quoi avoir peur.
[^] # Re: Encore une victime de Lennart
Posté par Foutaises . Évalué à 8. Dernière modification le 15 février 2015 à 06:26.
C'est vrai que c'est juste hallucinant…
Surtout quand ensuite tu tombes sur ce rapport de bug et que tu lis :
Remarquez que ça s'inscrit bien dans la tendance du moment dans le monde Linux, qui est de tout virer…
[^] # Re: Encore une victime de Lennart
Posté par groumly . Évalué à 1.
Ben visiblement, ils seraient pas contre un mainteneur, mais visiblement ceux qui ont des spinners s'en foutent, ou preferent troller, si j'ai bien suivi.
Ben d'un autre cote, c'est pas delirant de ne pas maintenir du code pour une technologie obsolete, je vois pas ce qu'il y a d'effrayant la dedan.
A moins que t'ai voulu dire "ils estiment que le spinners sont obsolete et ca fait peur", et meme la c'est tire par les cheveux. Oui, les spinners sont obsolete. Sorti d'un disque utilise pour du stockage pur et dur (genre backup), ca court plus vraiment les rues sur des machines grand publique. Surtout si au final ca avancait pas tellement le schimilimili.
On attend ton bench qui les contredit (et les patchs qui vont avec)!
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Encore une victime de Lennart
Posté par totof2000 . Évalué à 3.
Pour info, je ne juge pas du fond, ils ont peut-être raison, mais de la façon de se justifier (les développeurs n'ont que des SSD) : Il me semble que les développeurs de systemd sont employés chez RedHAt : ils ne peuvent pas demander une machine de dev/test à leur employeur ?
[^] # Re: Encore une victime de Lennart
Posté par xcomcmdr . Évalué à 0.
La justifiction complète est :
"les gains de performances n'étaient pas au rendez-vous la plupart du temps, et on a pas de quoi tester (donc l'améliorer)".
Code pas fiable, pas maintenu : ça vire au bout d'un moment. Très classique. Pas de quoi troller.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Encore une victime de Lennart
Posté par shbrol . Évalué à 6.
Une fonctionnalité intéressante pour certains utilisateurs est offerte par un projet autonome. Un nouveau projet, plus ambitieux, reprend la fonctionnalité histoire d'attirer ces utilisateurs. Alors, le projet d'origine, devenu obsolète, ferme boutique au profit du nouveau… qui abandonne ensuite cette fonctionnalité parce que bon, au final, osef, l'important c'était d'obtenir les utilisateurs, pas de les satisfaire.
C'est étrange, j'ai une impression de déja vu…
[^] # Re: Encore une victime de Lennart
Posté par SChauveau . Évalué à -2.
Amusant! Cette fois ci, la complainte est qe Systemd décide de ne pas intégrer une fonctionnalité déjà existante.
Fait un petit apt-get install readahead et tu auras ton readahead comme dans le bon vieux temps.
Il n'y a pas de conspiration; Aucun plan diabolique pour obtenir des utilisateurs à tout prix.
[^] # Re: Encore une victime de Lennart
Posté par shbrol . Évalué à 4.
Pas tout a fait: systemd a intégré, puis ensuite supprimé, une fonctionnalité existante.
Oui, et le projet est en très bonne santé: https://fedorahosted.org/readahead/
Si c'est pas une conspiration, c'est quoi ? de l'incompétence ?
[^] # Re: Encore une victime de Lennart
Posté par Foutaises . Évalué à 2. Dernière modification le 20 février 2015 à 17:17.
Il ne faut pas exagérer non plus, le marché mondial du SSD était de 11 milliards de dollars en 2013 (pour 83 millions d'unités vendues), même pas le tiers du marché du HDD (pour 552 millions d'unités vendues, quasi 7 fois plus), et ce alors que le prix au Go des SSD est 5 fois supérieur. Et ça c'est sans compter le parc gigantesque installé, et qui ne sera pas remplacé avant un moment.
Que la tendance soit au SDD sur les machines haut de gamme c'est un fait, mais le haut de gamme n'a jamais représenté le marché de masse, qui comme son nom l'indique représente la très grosse majorité des ventes. Pour 2016 et 2017, il devrait se vendre 200 à 230 millions de SSD dans le mondre contre 550 à 500 millions de HDD. Ce n'est pas ça que j'appelle être « obsolète ».
C'est comme les mecs qui t'annoncent la mort des lecteurs/supports optiques parce que, soit-disant, les gens préfèrent le streaming. Encore des qui vivent dans des grandes agglomérations, totalement déconnectés des réalités de l'Internet « haut-débit» en dehors, et de l'archivage hors « cloud ».
[^] # Re: Encore une victime de Lennart
Posté par shbrol . Évalué à 6.
Sur une machine un peu vieille avec un disque classique, j'avais installé fedora-readahead qui divisait par 2 la durée du boot (bootchart, toussa…). Apres passage a systemd, j'étais content de voir que le readahead était intégré, c'était plus simple, ça marchait tout aussi bien.
Puisque readahead disparait de systemd, il ne me reste plus qu'a retourner sur la version fedora, en espérant que ça fonctionne encore… merci systemd.
[^] # Re: Encore une victime de Lennart
Posté par Arthur Accroc . Évalué à 3.
J’ai plutôt l’impression qu’elle a disparu en faveur de la version de systemd…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: L'argument kitu
Posté par Dr BG . Évalué à 5.
C'est vraiment plus lent, ou alors c'est parce qu'Ubuntu affiche la page de connexion avant la fin contrairement à Fedora, et les mêmes services sont-ils lancés ? Je ne sais pas si c'est ça, mais c'est une possibilité.
[^] # Re: L'argument kitu
Posté par gnumdk (site web personnel) . Évalué à 5.
Oui, mais c'est nul, avec un SSD, j'ai même pas le temps de voir mon bootsplash :-(
[^] # Re: L'argument kitu
Posté par Albert_ . Évalué à 5.
Ah l'epoque de bootsplash que l'on changeait. C'etait du temps de windows 95. Je me souviens avoir mis Pinky and Brain a l'epoque. Nettement plus fun que le logo windows :). Ca rajeunit pas tout ca! Merci gnumdk< de me rappeler que je suis vieux.
# C'est là tout le problème
Posté par Ife . Évalué à 10.
Combien de fois je me suis retrouvé à maintenir des systèmes par des gens qui n'avait jamais lu la documentation de sysvinit. Et qui pensaient être expert en la matière.
Des "administrateurs système" qui écrivaient des scripts à la main, qui n'étaient pas basés sur
/etc/init.d/skeleton. Ou pire, des adminsys qui modifiaient entièrement leskeletonpour changer un comportement, alors qu'il aurait put être changé avec une simple variable d'environnement.Des gens qui auraient mieux fait de lire le manuel.
Mon avis, sur systemd c'est que ça permet de faire un filtrage des administrateur systèmes incompétents/non-passionnés qui ne font pas de veille. (en plus du fait que ça résout 70% des problèmes que j'avais avec sysvinit. Oui, je suis un fan de systemd, mais je sais reconnaître que ce n'est pas parfait, c'est juste mieux)
Et quand on recrute des administrateurs systèmes avec un salaire bien au dessus de la moyenne on peut se permettre de demander d'avoir une personne passionnée. (Je comprends que l'adminsys à 30k€ ne soit ni passionné, et parfois un peu incompétent.)
Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »
[^] # Re: C'est là tout le problème
Posté par Kaane . Évalué à 1.
Mon avis, sur systemd c'est que ça permet de faire un filtrage des administrateur systèmes incompétents/non-passionnés qui ne font pas de veille.
Entièrement d'accord. Un admin système qui n'est pas capable de citer au moins trois gros défaut de systemd, ou qui te dit sans rire que systemd c'est génial parce que ça apporte au choix du boot parallélisé, du tag de processus par cgroups ou des vrais outils de suivi des services - ben tu sais tout de suite que c'est une personne qui n'est pas sorti des forums de sa distrib favorite voire des site de news open source. Le genre de mec qui voulait mettre tous les fichiers de config en XML il y a cinq ans ou qui voulait remplacer les proxys par des scripts en python3 JIT/numba il y a deux ans.
Personnellement tout ce que m'apporte systemd c'est le log très tôt dans le boot, tout le reste je l'avais déjà ou je n'en ai pas l'utilité (voire ca me bloque) - je vais donc rester dans le camps des incompétents aigris et réactionnaires encore un peu, et écrire des scripts d'init qui ne ressemblent pas du tout mais alors pas du tout du tout à /etc/init.d/skeleton.
[^] # Re: C'est là tout le problème
Posté par xcomcmdr . Évalué à 2.
Euh, juste non. SysV a un vrai problème pour surveiller les services de manière fiable. Sans compter que SysV s'attend à ce que chaque script réimplémente la même chose (le fait de se mettre en daemon, d'être compatible avec le LSM du jour, etc…). Dire le contraire, c'est juste de la mauvaise foi. Et puis perso, je pense qu'on peut faire mieux que ça :
Sérieusement, SysV ou Upstart, c'était vachement plus cassé que systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est là tout le problème
Posté par fearan . Évalué à 4.
Ça, j'en sais rien; ce que je sais par contre c'est qu'un gars ayant des notions de base de bash était capable de réparer/tweaker un SysV sans apprentissage supplémentaire; ensuite au vu de la complexité grandissante des systèmes, et du nombres de service toujours plus important, rationaliser tout ça et avoir des automatismes (comme la daemonisation), est plutôt une bonne chose.
Bref, je trouve dommage la perte de facilité de bricolage, mais apprécie grandement la rationalisation du schmilblick.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est là tout le problème
Posté par xcomcmdr . Évalué à 0.
Non, ça c'est juste faux. Rien que pour faire en sorte qu'un script se mette en daemon proprement, ça requiert bien plus que des compétences de base.
A l'inverse, faire en sorte qu'une unité systemd se comporte différemment, ça veut dire la copier ailleurs et modifier une des valeurs, voire en rajouter. Même pas besoin de savoir ce qu'est bash, juste de savoir ce que veulent dire les clés et valeurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est là tout le problème
Posté par totof2000 . Évalué à 3.
Mais pourquoi veux-tu qu'un script se mette en daemon ?
[^] # Re: C'est là tout le problème
Posté par xcomcmdr . Évalué à 0.
Et si j'en ai envie ? Ça fait partie du "tweak" de services SysV, non ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est là tout le problème
Posté par totof2000 . Évalué à 2.
Je reformule ma questyion : pourrais-tu nous donner un exemple? Je ne vois pas du tout ce que tu veux faire : j'ai une petite idée, mais je veux être sur d'avoir compris avant de te répondre.
[^] # Re: C'est là tout le problème
Posté par totof2000 . Évalué à 4.
Hum, c'est ce que je faisais avec les scripts d'init. NetBSD par exemple implémente un système de scripts assez propre ou la plupart du temps, pour mettre en place un service tu as juste à mettre un truc du genre mondaemon=YES et ajouter dans rc.d un fichier (que tu copies par ailleurs) avec simplement le nom du binaire à lancer.
[^] # Re: C'est là tout le problème
Posté par fearan . Évalué à 2.
On a pas la même notion de bricolage pour moi un nohup sur un script comme celui ci me convient pour bricoler
tu peux même l'améliorer pour faire plus générique
Si tu veux faire dans les règles de l'art, c'est plus du bricolage, mais de l'administration système
Si le gars qui va éditer les fichier de conf à la main ne sais pas ce qu'est bash (ou un shell), j'espère ne JAMAIS être sur une machine qu'il administre.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est là tout le problème
Posté par xcomcmdr . Évalué à 1.
Si le gars sait juste au mieux bricoler au lieu de faire dans les règles de l'art, j'espère ne JAMAIS être sur une machine qu'il administre !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est là tout le problème
Posté par fearan . Évalué à 2.
en même temps y a quoi qui te choque dans le bricolage ci-dessus ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est là tout le problème
Posté par Kaane . Évalué à 4.
Euh, juste non. SysV a un vrai problème pour surveiller les services de manière fiable.
Et pour cause, c'est pas son job. Regarde plutôt du coté de runit ou daemontools.
Sans compter que SysV s'attend à ce que chaque script réimplémente la même chose (le fait de se mettre en daemon, d'être compatible avec le LSM du jour, etc…)
Non plus, SysV init s'attend juste à ce que le process rende la main. Ca peut être fait de pleins de façons différentes, la plus courante étant la daemonisation via double fork, mais c'est loin d'être la seule (hint : bsd).
Après pour simplifier la maintenance et avoir un peu cohérence dans les scripts, des templates ont été créés. Ils ne sont ni nécessaires ni forcément pertinents.
Sérieusement, SysV ou Upstart, c'était vachement plus cassé que systemd.
C'est une question de point de vue. Voici une petite liste de choses cassées dans systemd
- Logs centralisés distants sans I/O locaux (on peut configurer un syslog pour qu'il rebalance les logs à distance, mais pas rediriger les logs directement sur le réseau)
- Chiffrement non LUKS (c'est à dire juste les banques, l'armée et pas mal de matos médical - une paille en terme de clients pros, et je laisse de coté les éditeurs propriétaires qui pensent qu'en réinventant la roue leur appli sera mieux protégée)
- cgroups (oui, oui on peut vouloir faire autres choses avec les cgroups que ce que systemd à décidé - voire le nombre de patch à ce sujet dans docker pour comprendre)
- services dynamiques (ie services lancés - éventuellement par un autre service - avec une floppée de paramètres pour le configurer dynamiquement)
- contrôle de services par utilisateur sans droits root (avec SE Linux pour l'instant on ne peut qu'élever les droits d'un utilisateur pour lui donner un accès root au dbus "system")
- initialisation synchrone de périphériques (parfois nécessaire par exemple si il faut initialiser une carte avant de pouvoir initialiser le matos qui est derrière) - en cours de correction, mais je sens que le bébé va être refilé au kernel.
Toute ces choses (et de nombreuses autres) marchent très bien dans upstart, sysV init, runnit, daemontools, rc.d, openrc etc.
Il se trouve que dans certains environnements les fonctions citées plus haut sont absolument nécessaires.
Je suis content pour toi si systemd résout tes problèmes, mais il est loin d'être iso-fonctionnel avec les inits historiques et il ne prend pas vraiment le bon chemin pour le devenir.
[^] # Re: C'est là tout le problème
Posté par xcomcmdr . Évalué à -2. Dernière modification le 16 février 2015 à 12:51.
Ouais, génial. Donc il faut changer d'init, ou au moins avoir plusieurs outils pour tenter de savoir si un service est démarré ou non (pratique…).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est là tout le problème
Posté par Kaane . Évalué à 6.
Ouais, génial. Donc il faut changer d'init,
Parcequ'avec systemd on ne change pas d'init j'imagine…
ou au moins avoir plusieurs outils pour tenter de savoir si un service est démarré ou non (pratique…).
On peut aussi avoir un admin système compétent à la place. Le fait que Debian prévoit plusieurs scénarios pour lancer sshd ne veut pas dire que tu es obligé de tous les garder. Si tu as besoin de 50 outils pour savoir si oui ou non un service est lancé c'est un soucis à voir avec ton admin système, SysV init n'y est pour rien. Et puis très honnêtement si tu es en mode rescue, mono utilisateur, mono console tu es supposé t'en rendre compte. Si /usr ne s'est pas monté et que seuls les services primaires compilés en statique tournent, tu es supposé le voir aussi assez rapidement. Donc bon le mec qui se demande si par hasard sshd ne se serait pas lancé via un des autres scripts, il est supposé avoir une excellente raison de le faire.
En ce qui concerne ta longue citation, c'est l'opinion du monsieur. J'ai exactement l'opinion inverse. Je suis très content avec un système d'init qui en fait le minimum et qui me laisse le champs libre pour choisir ce que je veux pour faire le reste. Je peux prendre les outils de monitoring que je veux, utiliser les cgroups comme bon me semble, décider seul des mécanismes de respawn etc.
Le problème de la daemonisation a déjà été évoqué. Ca n'a rien à avoir avec SysV init, daemoniser un processus c'est complexe quel que soit la raison pour laquelle on a besoin de le faire. SysV init demande juste à ce qu'on lui rende la main - il se moque complètement de savoir comment. Dire que pour être compatible avec SysV init un processus doit passer par les quinze étapes de la daemonisation est juste faux.
En ce qui concerne les ports, c'est une des façons de faire, il y en a d'autres. Par exemple, aucun de mes services n'a jamais les droit root à part ssh, du coup je n'ai jamais à dropper de privilèges. Si un service a besoin d'un port privilégié par exemple, ben il ouvre un port non privilégié sur une interface interne et ce sont des règles firewall qui font le mapping.
Pour finir avec les logs, oui les logs sont une fonctionnalité que chaque service doit ré-implémenter. Mais là je suis curieux de savoir comment faire autrement. Le monsieur a une machine qui permet de déterminer la pertinence d'une info interne à une appli et de la remonter toute seule vers les logs ? Parceque sinon ca va rester le boulot du dev de l'appli de gérer les logs. Quant aux metadatas infalsifiables ajoutés par journald, il y a des fois ou c'est juste pénible. (par exemple un routeur téléphonique de petit opérateur va générer environ 1000 lignes de logs par secondes - logs que l'on est légalement obligé de conserver). On est parti pour 15-20ko/s d'I/O, de bande passante et d'espace disque gaspillé chaque seconde par routeur.
Tout ça pour dire ce sont des points de vue, je les comprend mais j'ai des problématiques et des besoins différents qui font qu'à aujourd'hui systemd ne peut pas me servir.
[^] # Re: C'est là tout le problème
Posté par MCMic (site web personnel) . Évalué à 4.
Je te le redis parce qu’on te l’avait déjà signalé mais visiblement ça a pas été pris en compte, il y a une syntaxe pour les citations sur linuxfr, il faut faire:
> citation
réponse
Visiblement tu utilise «_» , ce qui donne de l’italique, et n’a pas la décoration des citations fournie par les CSS linuxfr. Ça rend tes posts très difficiles à lire par rapport au reste.
[^] # Re: C'est là tout le problème
Posté par Thomas Douillard . Évalué à 3.
Nan, c'est juste un trolleur patenté qui glisse des provoc' ça et là à tout les niveaux pour espérer provoquer ce genre de threads /o\
[^] # Re: C'est là tout le problème
Posté par Thomas Douillard . Évalué à 3.
En fait t'es aigri parce que ta rend tes compétences de fou qui faisait des tonnes de config pour avoir un équivalent à systemd obsolètes et accessibles à plus de monde ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.