Journal systemd: je me lance

Posté par  . Licence CC By‑SA.
Étiquettes :
44
12
fév.
2015

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  . É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  . Évalué à 10.

      le parefeu openoffice libreoffice 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  . Évalué à 1.

      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…

      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 :

      systemctl stop firewalld
      systemctl disable firewalld
      yum install iptables-service ip6tables-service
      systemctl start iptables
      systemctl start ip6tables
      systemctl enable iptables
      systemctl enable ip6tables

      et la… on retrouve nos petites habitudes.

  • # .

    Posté par  (site web personnel) . Évalué à 4.

    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.

    Je pense que t'as mal lu le dit commmentaire. Plutôt que te faire chier avec les chemins : systemctl set-default TARGET.target

    ma théorie comme quoi les services effectivement démarrés sont dans /etc/systemd/system/ s'écroule pour de bon.

    Je veux bidouiller moi-même mais je ne veux pas lire la moindre ligne de man

    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

    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  . É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:

      • normal
      • une nouveaute a faire sauter les bouchons de champagnes
      • enfin les feignants de IT vont devoir nettoyer les merdes qui sont dans le fstab

      Je propose pas les choix cela serait inutile je sens:

      • bizarre
      • anormale
      • horripilant
      • WTF?
      • Pourquoi je peux pas demarrer mon systeme?
      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 10.

        sdb1 peut 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'option nofail), il ne démarre pas d'autres services car ceux-ci pourraient avoir besoin de ce point de montage. /etc/fstab ne 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  (site web personnel) . Évalué à 10.

          Ben d'après le journal ce qui se passe c'est que :

          Effectivement, au boot, j'ai un timeout puis le choix de retenter ou d'entrer dans un shell de secours.

          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  . É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  . É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  (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  . É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  . É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  . Évalué à 8. Dernière modification le 12 février 2015 à 20:22.

          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.

          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.

          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

          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  . Évalué à 10.

            Et network-manager n'a RIEN à voir avec systemd.

            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  . Évalué à 3.

              Et network-manager n'a RIEN à voir avec systemd.

              Ouais rien à voir sauf sur une distribution qui installe les 2 et paff le wifi.

              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  . Évalué à 6.

                se connecter à Internet sans câble.

                Network over butterfly?

            • [^] # Re: .

              Posté par  . Évalué à 10.

              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.

              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  (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  (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  . É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  . É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  . É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  . Évalué à 10.

            Je trouve sysv assez imbuvable

            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  . É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  . Évalué à 10.

      Je pense que t'as mal lu le dit commmentaire. Plutôt que te faire chier avec les chemins : systemctl set-default TARGET.target

      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 veux bidouiller moi-même mais je ne veux pas lire la moindre ligne de man

      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).

      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

      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.

      Encore un journal anti-systemd

      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  . Évalué à 10.

        Encore un journal anti-systemd

        Ce n'est pas le sens que je voulais donner. Désolé si c'est ce qui apparaît.

        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  (site web personnel) . Évalué à 10.

      Encore un journal anti-systemd

      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  . É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

    systemctl list-unit -t service
    

    Pour voir tout les services

    systemctl list-unit -t service -a 
    

    Il est aussi possible de spécifier un pattern

    systemctl list-units '*lvm*' 
    

    Pour inspecter la définition d'un service on pourra utiliser la commande cat

    systemctl cat ssh.service
    

    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  (site web personnel) . Évalué à 4.

      En parlant de services, le travail d’intégration fourni sous RHEL/Centos 7 pour la commande service est 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  . Évalué à 9.

        Et sous Debian

        # /etc/init.d/cups restart
        [ ok ] Restarting cups (via systemctl): cups.service.
        

        (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  . É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  . É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  . É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  (site web personnel) . Évalué à 4.

    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.

    Amusant, je ne me suis pas encore du tout penché sur le pourquoi du comment de systemd, mais sur mon Ubuntu actuelle :

    # systemctl list-unit-files | wc -l
    282
    
    # systemctl list-units | wc -l
    Failed to get D-Bus connection: No connection to service manager.
    0
    

    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-files et de list-units sont 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  . Évalué à 4.

      Ubuntu a DÉJÀ migré ?!

      Faut que je me mette à jour moi… :D

      Sinon sous Gentoo, les deux marchent :

      # systemctl list-unit-files | wc -l
      257
      # systemctl list-units | wc -l
      131
      
      • [^] # Re: systemctl list-unit-etc.

        Posté par  (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  . É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  . É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  (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  . Évalué à 3.

        Peut-être pour faire les choses plus en douceur?

      • [^] # Re: systemctl list-unit-etc.

        Posté par  . É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  . É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  (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  . É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  . É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  . Évalué à 1. Dernière modification le 14 février 2015 à 12:48.

        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'.

        ???? Ca sert à quoi de l'avoir à plusieurs endroits ?

        • [^] # Re: ...

          Posté par  . Évalué à 6.

          ???? Ca sert à quoi de l'avoir à plusieurs endroits ?

          A faire de la surcharge de configuration

          • [^] # Re: ...

            Posté par  . Évalué à 7.

            Dans man serviced.network

            The .network files are read from the files located in the system network directory /lib/systemd/network, the
            volatile runtime network directory /run/systemd/network and the local administration network directory
            /etc/systemd/network. All configuration files are collectively sorted and processed in lexical order,
            regardless of the directories in which they live. However, files with identical filenames replace each other.
            Files in /etc have the highest priority, files in /run take precedence over files with the same name in /lib.
            This can be used to override a system-supplied configuration file with a local file if needed; a symlink in
            /etc with the same name as a configuration file in /lib, pointing to /dev/null, disables the configuration
            file entirely.
            

            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  (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  (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  (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  . É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  . É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  . Évalué à 5.

              (si possible après avoir actualisé readahead).

              Ce qui n'a pas grand intérêt avec un SSD.

              • [^] # Re: L'argument kitu

                Posté par  . É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  . Évalué à 5.

              Si vous voulez être constructif, passez un coup de bootchart et postez le résultat (si possible après avoir actualisé readahead).

              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  . É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  . Évalué à 8. Dernière modification le 15 février 2015 à 06:26.

                  L'excuse pour ne pas continuer à le développer est quand même complêtement bidon

                  C'est vrai que c'est juste hallucinant…

                  « systemd's readahead implementation has been removed. In many circumstances it didn't give expected benefits even forrotational 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 »

                  Surtout quand ensuite tu tombes sur ce rapport de bug et que tu lis :

                  « We were actually considering to already disable readahead for jessie, so
                  people don't get used to it and are then disappointed in jessie+1. »

                  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  . Évalué à 1.

                  L'excuse pour ne pas continuer à le développer est quand même complêtement bidon

                  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.

                  si les développeurs ne continuent pas à maintenir leur produit sur des technologies que eux jugent obsolètes, il y a de quoi avoir peur.

                  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  . É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  . É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  . É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  . É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  . Évalué à 4.

                            Amusant! Cette fois ci, la complainte est qe Systemd décide de ne pas intégrer une fonctionnalité déjà existante.

                            Pas tout a fait: systemd a intégré, puis ensuite supprimé, une fonctionnalité existante.

                            Fait un petit apt-get install readahead et tu auras ton readahead comme dans le bon vieux temps.

                            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  . Évalué à 2. Dernière modification le 20 février 2015 à 17:17.

                    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.

                    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  . É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  . Évalué à 3.

                  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.

                  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  . É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  (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  . É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  . Évalué à 10.

    Ceci dit, quand je me suis mis à Unix, je n'ai jamais éprouvé le besoin de lire la doc de SysV.

    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 le skeleton pour 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  . É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  . Évalué à 2.

        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

        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 :

        This starts with the requirement of every service having to daemonize itself. This is not a trivial task, requiring 15 separate steps to do correctly. Even the system call daemon(7) is discouraged because it forgets some of the steps.

        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  . Évalué à 4.

          Sérieusement, SysV ou Upstart, c'était vachement plus cassé que systemd.

          Ç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  . Évalué à 0.

            Ç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;

            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  . Évalué à 3.

              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.

              Mais pourquoi veux-tu qu'un script se mette en daemon ?

              • [^] # Re: C'est là tout le problème

                Posté par  . Évalué à 0.

                Mais pourquoi veux-tu qu'un script se mette en daemon ?

                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  . É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  . Évalué à 4.

              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.

              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  . Évalué à 2.

              Non, ça c'est juste faux. Rien que pour faire en sorte qu'un script se mette en daemon proprement,

              On a pas la même notion de bricolage pour moi un nohup sur un script comme celui ci me convient pour bricoler

              
              FILERUN=/var/run/plopHasToRun
              while [ -f "$FILERUN" ] 
              do
                 plop
                 echo $$ >/var/run/plop.pid
                 sleep 1
              done
              
              

              tu peux même l'améliorer pour faire plus générique

              
              FILERUN=$(shift)
              while [ -f "$FILERUN" ]
              do
                 $*
                 echo $$ > /var/run/$1.pid
                 sleep 1
              done
              
              

              Si tu veux faire dans les règles de l'art, c'est plus du bricolage, mais de l'administration système

              Même pas besoin de savoir ce qu'est bash, juste de savoir ce que veulent dire les clés et valeurs.

              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  . Évalué à 1.

                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.

                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  . É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  . É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  . Évalué à -2. Dernière modification le 16 février 2015 à 12:51.

            Et pour cause, c'est pas son job. Regarde plutôt du coté de runit ou daemontools.

            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…).

            Not My Problem

            And this is about all SysV init actually does. Other problems that might be addressed by the init system are delegated to other programs.

            For example, starting processes on socket connections has to be done by inetd or xinetd. If you want to monitor a service and restart it when it fails, you have to use supervisor or circus. And so on.

            But the service script does not know about services started from those programs, so the admin is left with multiple different places to look for whether a service is running, or even what services are running at all.

            Similarly, SysV init simply expects each and every service to re-implement common functionality instead of implementing it itself once.

            This starts with the requirement of every service having to daemonize itself. This is not a trivial task, requiring 15 separate steps to do correctly. Even the system call daemon(7) is discouraged because it forgets some of the steps.

            All services that open TCP ports below 1024 are expected to start as root, open the socket, and drop user privileges by themselves. Generally, dropping user privileges and setting up a chroot has to be done by services. Logging is another aspect that every service gets to re-implement badly.

            Between the limited functionality SysV offers, and the convoluted and baroque way in which it is implemented, there has to be a better way.

            "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  . É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  (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  . É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  . É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.