systemd pour les administrateurs, parties 3, 4 et 5

55
1
oct.
2014
Technologie

On vous parle depuis longtemps de systemd. On vous dit que c’est très bien. De nombreuses distributions l’ont adopté (dont Fedora, openSUSE, Mageia, Frugalware et ArchLinux), vont l’adopter (Debian, Ubuntu) ou vous permettent de l’utiliser de manière optionnelle (Gentoo par exemple). Mais savez‐vous l’utiliser ?

Voici la suite d'une série d’articles didactiques pour apprendre à utiliser systemd et vous permettre de mieux l’appréhender et de comprendre les avantages qu’il apporte par rapport aux systèmes précédents.

Les informations ci‐dessous sont tirées, traduites et adaptées du blog de Lennart Poettering et sont accessibles dans la langue de Shakespeare aux adresses ci‐dessous :

Sommaire

Partie 3: Convertir un script d'init SysV en fichier de service systemd ?

Traditionnellement, les services Unix et Linux (les démons) sont démarrés par des scripts d'init SysV. Il s'agit de scripts pour le shell Bourne qui résident généralement dans un répertoire tel que /etc/rc.d/init.d/ et qui, lorsqu'ils sont appelés avec un des quelques arguments standards (verbes) tels que start, stop ou restart, respectivement démarrent, arrêtent ou relancent le service en question. Pour le démarrage, cela implique généralement d'invoquer le binaire du démon qui forke un processus en tâche de fond (plus précisément, qui devient un démon). Les scripts shell ont tendance à être lents, assez lourds à lire, très verbeux et fragiles. Bien qu'ils soient immensément flexibles (après tout, ce n'est jamais que du code), certaines choses sont difficiles à réaliser avec des scripts shell, comme mettre en ordre une exécution en parallèle, superviser correctement des processus ou encore simplement configurer les contextes d'exécution dans leurs moindres détails.

Systemd fournit des éléments de compatibilité avec ces scripts shell mais, en raison des points négatifs invoqués précédemment, il est recommandé d'installer des fichiers de service systemd pour l'ensemble des démons installés.

De plus, en contraste avec les scripts d'init SysV qui ont besoin d'être adaptés à la distribution, les fichiers de service systemd sont compatibles avec n'importe quelle distribution exécutant systemd (ce qui arrive de plus en plus fréquemment ces derniers temps…).

Dans ce qui suit, vous trouverez un guide succinct sur comment convertir un script d'init SysV en un fichier de service natif systemd. Dans l'idéal, les projets en amont devraient distribuer et installer des fichiers de service dans leur archives tar. Si vous avez converti avec succès un script SysV en suivant les recommandations, il serait de bon ton de soumettre un patch au projet amont. La préparation d'un tel patch sera discutée lors d'une prochaine session et il suffit de vous informer que la page de manuel de daemon(7), distribuée avec systemd contient de nombreuses informations utiles sur ce sujet.

Plongeons-nous dedans

À titre d’exemple, nous allons convertir le script d'init du démon ABRT en fichier de service systemd. ABRT est un composant standard de toute installation de Fedora et il s'agit d'un acronyme pour Automatic Bug Reporting Tool, ce qui décrit bien mieux ce dont il s'agit, à savoir, un service pour collecter les dumps de crash. Le fichier de script SysV est disponible ici.

La première étape à suivre pour convertir un tel script consiste simplement à le lire (!) et à récupérer l'information essentielle distillée tout au long de ce script volumineux. Dans la majorité des cas, le script est formé d'un ensemble de code qui est assez similaire dans tous les scripts d'init et il est généralement copié-collé d'un script à l'autre. Extrayons maintenant l'information essentielle du script ci-dessus:

  • Une chaîne de caractère qui décrit le service: "Daemon to detect crashing apps". Les commentaires de l'en-tête du script présentent plusieurs chaînes de description, certaines décrivant davantage le script d'init réalisant le démarrage du service que le service en lui-même. Les services systemd ont également besoin d'une description et ils devraient décrire le service et non le fichier de service.
  • L'en-tête LSB1 contient les informations de dépendance. Grâce à son architecture basée sur l'activation par socket, systemd n'a généralement pas besoin (ou un tout petit peu) de définir manuellement les dépendances. (Pour plus d'informations sur l’activation par socket lisez l'article originel du blog.) Dans ce cas, la dépendance vis-à-vis de $syslog (qui indique que arbtd a besoin d'un démon syslog) est la seule information d'intérêt. Même si l'en-tête indique une autre dépendance ($local_fs), celle-ci est redondante dans systemd car les services normaux systemd sont toujours démarrés lorsque tous les systèmes de fichiers locaux sont disponibles.
  • L'en-tête LSB suggère que ce service doit être démarré dans les runlevels 3 (multi-utilisateur) et 5 (graphique).
  • Le binaire du démon est /usr/sbin/abrtd.

Et c'est déjà tout ! Le reste de ce script de 115 lignes est simplement du code générique ou redondant: du code qui gère la synchronisation et l'ordonnancement du démarrage (du code qui gère les fichiers de lock) ou qui génère des messages d'état (le code qui appelle echo), ou simplement qui analyse les arguments (le gros bloc du case).

À partir de l'information extraite ci-dessus, nous pouvons maintenant écrire notre fichier de service systemd:

[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target

Un peu d'explications du contenu de ce fichier

La section [Unit]

Elle contient de l'information générique sur le service. Systemd gère des services systèmes mais également des périphériques, des points de montage, des timers, et d'autres composants du système. Le terme générique pour tous ces objets dans systemd est une unité (Unit). La section [Unit] stocke l'information qui s'applique non seulement aux services mais également à tous les autres types d'unité systemd. Dans notre cas, nous ajoutons les paramètres d'unité suivants: nous ajoutons une chaîne de caractère de description et nous configurons que le démon doit être lancé après Syslog2, de la même manière à ce qui est indiqué dans l'en-tête LSB du script d'init originel. Pour gérer cette dépendance à Syslog, nous créons une dépendance de type After= sur l'unité systemd nommée syslog.target. Cette dernière est une unité particulière et elle représente le nom standard pour l'implémentation de syslog dans systemd. Pour plus d'informations sur ces noms standardisés, consultez la page de manuel systemd.special(7). Notez qu'une dépendance du type After= représente seulement une suggestion d'ordre de démarrage; elle ne se traduit pas par le démarrage de syslog lorsque abrtd démarre. C'est exactement ce que nous voulons puisque abrtd fonctionne correctement, même lorsque syslog n'est pas disponible. Néanmoins, si les deux sont démarrés (c'est généralement le cas), alors l'ordre dans lequel ils sont lancés est contrôlé avec cette dépendance.

La section [Service]

Elle s'occupe de l'information sur le service en lui-même. Elle contient tous les paramètres qui s'appliquent uniquement à des services et non aux autres types d'unité systemd (points de montage, périphériques, timers, …). Deux paramètres sont utilisés ici: ExecStart= qui stocke le chemin vers le binaire pour l'exécuter lorsque le service doit être démarré. Avec Type=, on configure la manière dont le service notifie le système d'init qu'il a terminé son démarrage. Étant donné que les démons traditionnels Unix le font en émettant un code de retour au processus parent après avoir forké et initialisé un démon en tâche de fond, nous utilisons le type forking ici. Cela indique à systemd d'attendre jusqu'à ce que le binaire de démarrage envoie un code retour et de gérer les processus qui tournent toujours après ceux du démon.

La dernière section est [Install]

Elle stocke l'information sur comment devrait être l'installation suggérée, c’est-à-dire, dans quelles circonstances et par quels déclencheurs le service devrait être démarré. Dans notre cas, nous indiquons simplement que le service doit être démarré lorsque l'Unit multi-user.target est activée. Il s'agit également d'une Unit spéciale qui prend globalement le rôle du Runlevel 32 de SysV. Le paramètre WantedBy= a peu d'effet sur le fonctionnement courant du démon. Il est uniquement lu par la commande systemctl enable qui est le moyen recommandé d'installer un service dans systemd. Cette commande s'assure simplement que notre service est automatiquement activé dès que l'Unit multi-user.target est requise, ce qui est le cas lors des séquences de boot normales3.

Et c'est tout ! Nous avons maintenant un fichier de service systemd fonctionnel et simple. Pour le tester, il faut le copier dans /etc/systemd/system/abrtd.service et lancer systemctl daemon-reload. Cela permettra à systemd de prendre en compte notre fichier et dès cet instant, nous pouvons démarrer ce service en lançant: systemctl start abrtd.service. Nous pouvons en vérifier l'état grâce à systemctl status abrtd.service. Et nous pouvons arrêter le service via systemctl stop abrtd.service. Finalement, nous pouvons l'installer de manière à ce qu'il soit activé par défaut lors des prochains boots avec la commande systemctl enable abrtd.service.

Le fichier de service ci-dessus, bien que suffisant et représentant une traduction globale du script d'init SysV, peut encore être amélioré. En voici une petite mise à jour:

[Unit]
Description=ABRT Automated Bug Reporting Tool
After=syslog.target

[Service]
Type=dbus
BusName=com.redhat.abrt
ExecStart=/usr/sbin/abrtd -d -s

[Install]
WantedBy=multi-user.target

Voyons ce qui a changé. Deux choses: nous avons amélioré la description et, plus important, nous avons changé le type de service à dbus et configuré le nom D-Bus du service. Pourquoi avoir fait cela ? Comme déjà évoqué précédemment, les services classiques SysV deviennent des démons après le démarrage ce qui implique généralement un double fork et le fait de se détacher de tout terminal. Bien que cette approche soit utile et nécessaire lorsque les démons sont lancés par un script, elle est non nécessaire (et lente) ainsi que contre-productive lorsqu'un système efficace de gestion des processus tel que systemd est employé. La raison à cela est que le processus du démon qui a forké n'a généralement plus de lien avec le processus démarré par systemd (la procédure de transformation en démon consiste à supprimer ce lien), ce qui rend difficile pour systemd de distinguer, après le fork, dans les processus appartenant au service, lequel est le processus principal et quels sont les processus auxiliaires. Cette information est pourtant cruciale pour disposer d'une gestion de processus aux petits oignons, c’est-à-dire pour superviser un processus, le relancer automatiquement lors des arrêts anormaux, collecter l'information de crash et les codes de sortie. Pour que systemd puisse facilement repérer quel est le processus principal, nous avons changé le type de service à dbus. La syntaxe de ce type de service est faite pour tous les services qui prennent un nom sur le bus système D-Bus comme dernière étape de leur initialisation 4. ABRT est un de ces services. Avec ce paramètre, systemd lancera le processus ABRT qui ne forkera plus (configuré via les options -d -s du démon) et systemd considérera le service comme complètement démarré dès que com.redhat.abrt apparaîtra sur le bus. Ainsi, le processus lancé par systemd sera le processus principal du démon et systemd dispose d'un moyen fiable pour vérifier si le démon est complètement démarré; systemd pourra le superviser plus facilement.

Et c'est tout ce qu'il y a besoin de faire. Nous avons un simple fichier de service systemd qui fournit plus d'information dans 10 lignes que le script SysV originel en 115 lignes. Dès maintenant, il reste encore une grande marge d'amélioration en utilisant plus de fonctionnalités de systemd. Par exemple, nous pourrions configurer Restart=restart-always pour indiquer à systemd de relancer automatiquement le service lorsque celui-ci échoue. Ou encore, nous pourrions utiliser OOMScoreAdjust=-500 pour demander au noyau de laisser ce processus lorsque OOM killer est employé. Ou bien, nous pourrions utiliser CPUSchedulingPolicy=idle pour s'assurer qu'abrtd traite les traces de crash en tâche de fond uniquement, en autorisant le noyau à donner sa préférence à tout ce qui fonctionne et qui a besoin de temps CPU.

Pour plus d'informations sur les options de configuration mentionnées ci-dessus, consultez les pages de manuel respectives systemd.unit(5), systemd.service(5), systemd.exec(5). Ou bien, consultez toutes les pages de manuel systemd.

Bien sûr, tous les scripts SysV ne se convertissent pas aussi facilement que celui que nous avons étudié. Néanmoins une grande majorité devrait pouvoir l'être.

C'est tout pour aujourd'hui, à bientôt pour la prochaine session de cette série.

Partie 4: Tuer des services

Tuer un service, c'est simple non ? Ou pas ?

Bien entendu, tant que votre démon est constitué d'un seul processus, c'est généralement vrai. Vous tapez killall rsyslogd et le démon syslog n'est plus. Néanmoins, c'est un peu sale de faire ainsi étant donné que cela tuera tous les démons qui s'appellent ainsi, incluant ceux qu'un utilisateur malchanceux aurait nommé ainsi par accident. Une version plus correcte aurait été de lire le fichier .pid, c'est-à-dire kill $(cat /var/run/syslogd.pid). Cela nous avance un peu mais néanmoins est-ce vraiment ce que nous souhaitons ?

Dans la majorité des cas en fait, cela ne se passera pas ainsi. Considérons des services tels qu'Apache, crond ou atd qui, dans leur fonctionnement courant, engendrent des processus fils. Généralement, il s'agit de processus fils configurables par l'utilisateur tels que des tâches cron ou at ou encore des scripts CGI, y compris des serveurs d'application complets. Si vous tuez le processus principal Apache/crond/atd cela pourra ou non tuer l'ensemble des processus fils également et c'est à chacun de ces processus de savoir s'ils veulent continuer à tourner ou s'ils doivent s'arrêter. Dans la pratique, cela signifie que mettre fin à Apache pourrait très bien laisser ces scripts CGI fonctionner, réaffectés comme enfants du processus init, ce qui est difficile à tracer.

Systemd vient à la rescousse: avec systemctl kill, vous pouvez facilement envoyer un signal à tous les processus d'un service. Par exemple:

# systemctl kill crond.service

Cela assurera que SIGTERM est envoyé à tous les processus du service crond, pas uniquement au processus principal. Bien entendu, vous pouvez également envoyer un signal différent si vous le souhaitez. Par exemple, si vous êtes mal luné, vous aurez peut-être envie d'envoyer SIGKILL de cette manière:

# systemctl kill -s SIGKILL crond.service

Et voilà, le service sera complètement stoppé brutalement, peu importe combien de fois il a été forké ou qu'il essaye d'échapper à la supervision par un fork double ou par un bombardement de forks.

Parfois, vous avez juste besoin d'envoyer un signal spécifique au processus principal d'un service, par exemple parce que vous voulez déclencher un rechargement du service par le signal SIGHUP. A la place de retrouver le fichier de PID, voici un moyen plus simple d'y parvenir:

# systemctl kill -s HUP --kill-who=main crond.service

Encore une fois, qu'y-a-t-il de nouveau et de fantaisiste dans la manière de tuer des processus avec systemd ? Eh bien, pour la première fois sous Linux, nous pouvons le faire proprement. Les précédentes solutions dépendaient toutes de la bonne coopération des démons pour qu'ils arrêtent tous les processus qu'ils avaient engendrés lorsqu'ils devaient se terminer. Néanmoins si vous voulez employer SIGTERM ou SIGKILL, vous le faites parce qu'ils ne coopèrent pas correctement avec vous.

Qu'est-ce-que ça a à voir avec systemctl stop ? kill envoie directement un signal à chacun des processus situés dans le groupe; stop, pour sa part, utilise le moyen officiellement configuré pour arrêter le service, c'est-à-dire qu'il lance la commande configurée avec ExecStop= dans le fichier de service. En général, stop devrait être suffisant. kill reste la méthode forte à utiliser dans les cas ou vous ne voulez pas utiliser la commande shutdown d'un service ou bien lorsque le service est complètement en carafe.

(C'est à vous bien entendu d'indiquer ou non les noms de signaux avec le préfixe SIG avec ou sans l'option -s. Les deux fonctionnent.)

C'est assez surprenant d'être parvenu jusqu'ici sous Linux sans disposer d'un moyen efficace de tuer des services. Systemd permet pour la première fois de le faire proprement.

Partie 5: Trois niveaux de "Off"

Dans systemd, il y a trois niveaux pour arrêter un service (ou d'autres unités). Voyons voir quels sont-ils:

Arrêter un service

Cela termine simplement l'instance du service qui fonctionne et cela ne fait que ça. Si pour d'autres raisons d'activation (telles que le lancement manuel, l'activation par socket, par le bus, par le boot du système ou par un interrupteur machine) le service est demandé après cet arrêt, il sera à nouveau lancé. Arrêter un service est donc une opération simple, temporaire et superficielle. Voici un exemple avec le service NTP:

$ systemctl stop ntpd.service

C'est globalement équivalent à la commande traditionnelle disponible sur la plupart des systèmes basés sur SysV:

$ service ntpd stop

Dans les faits, sur Fedora 15, si vous exécutez cette dernière commande, elle sera convertie de manière transparente en la première.

Désactiver un service

Cela détache le service de ses déclencheurs. Cela signifie que, selon votre service, il ne sera plus activé au démarrage de la machine, par socket, par bus ou par un interrupteur machine (ou tout autre déclencheur qui s'y applique). Néanmoins, vous pouvez quand même le lancer manuellement si vous le désirez. S'il y a déjà une instance du service démarrée, désactiver un service ne l'arrêtera pas. Voici un exemple de comment désactiver un service:

$ systemctl disable ntpd.service

Sur les systèmes traditionnels Fedora, c'est globalement l'équivalent de la commande qui suit:

$ chkconfig ntpd off

Ici également, sur Fedora 15, la commande précédente sera convertie de manière transparente en la première, si nécessaire.

Bien souvent, vous souhaitez combiner arrêt et désactivation du service, de manière à supprimer l'instance courante et faire en sorte que le service ne soit pas relancé (sauf par action manuelle):

$ systemctl disable ntpd.service
$ systemctl stop ntpd.service

Les commandes précédentes sont lancées par exemple lors de la désinstallation du paquet d'un service systemd sur Fedora.

Désactiver un service est un changement permanent; tant que vous ne le réactivez pas, ce changement sera conservé même après le redémarrage de la machine.

Masquer un service.

C'est comme le désactiver mais en plus fort. Cela fait en sorte d'être sûr que le service ne sera plus jamais démarré automatiquement mais assure également qu'un service ne puisse plus être démarré manuellement. C'est une fonctionnalité cachée dans systemd puisqu'elle n'est pas utilisé couramment et qu'elle peut être mal interprétée par un utilisateur. Néanmoins, voilà comment vous devriez procéder:

$ ln -s /dev/null /etc/systemd/system/ntpd.service
$ systemctl daemon-reload

En créant un lien symbolique d'un fichier de service vers /dev/null, vous indiquez à systemd de ne jamais démarrer le service en question et vous bloquez complètement son exécution. Les fichiers d'unité stockés dans /etc/systemd.system remplacent ceux qui sont situés dans /lib/systemd/system qui portent le même nom. Le premier répertoire relève de l'administrateur système, le second relève du responsable de paquet. En installant un lien symbolique dans /etc/systemd/system/ntpd.service, vous pouvez être sûr que systemd ne lira jamais le fichier de service situé dans /lib/systemd/system/ntpd.service.

Systemd reconnaîtra les unités liées vers /dev/null et les indiquera comme étant masquées. Si vous essayez de lancer de tels services manuellement (via systemctl start par exemple), cela se terminera par une erreur.

Un mécanisme similaire n'existe pas (officiellement) pour les systèmes SysV. Néanmoins, il existe quelques trucs officieux comme éditer le script d'init et en indiquant un exit 0 au début ou bien encore en enlevant le bit exécutable. Néanmoins ces solutions présentent différents inconvénients comme le fait qu'elles interfèrent avec ce que le responsable de paquet a prévu.

Masquer un service est un changement permanent, un peu comme désactiver un service.

Maintenant que nous savons comment gérer l'arrêt de services sur ces trois niveaux, il reste encore une question: commet les réactiver. Eh bien, c'est assez similaire. Utilisez systemctl start pour revenir en arrière de la commande systemctl stop. Utilisez systemctl enable pour revenir en arrière de la commande systemctl disable et utilisez rm pour supprimer les liens symboliques.

C'est tout pour aujourd'hui, Merci de votre attention !

Notes de bas de page

Note du rédacteur: ce serait bien que l'ensemble des traductions relatives à systemd du blog de Lennart Poettering puissent être traduites sur LinuxFr.org (sauf peut-être celles sur journald qui est un composant optionnel de systemd). Cela permettrait de rendre plus accessible et démystifier un peu ce composant système devenu maintenant quasi-incontournable ainsi que d'apporter quelques articles techniques (pas forcément de haut niveau) sur LinuxFr.org.


  1. L'en-tête LSB des scripts d'init est une convention qui permet d'inclure des métadonnées sur le service dans des blocs de commentaires des scripts d'init SysV. Elle est définie dans la Linux Standard Base. L'objectif était de standardiser les scripts d'init parmi les différentes distributions. Bien que la majorité des distributions ont adopté ce schéma, la gestion des en-têtes varie beaucoup d'une distribution à l'autre et dans les faits, il est souvent nécessaire d'adapter chaque script d'init pour chacune des distributions. La spécification LSB sur ce point n'a jamais atteint la promesse qu'elle s'était fixée au départ. 

  2. Au moins de la manière utilisée pour sa définition dans Fedora. 

  3. Veuillez noter que dans systemd, le boot graphique (graphical.target qui prend le rôle du RunLevel 5 de SysV) est un sur-ensemble de la séquence de boot dédiée au mode console seule (multi-user.target, c’est-à-dire le RunLevel 3). Cela signifie que rattacher un service dans cette dernière le rattachera également à la première séquence de boot (`graphical.target). 

  4. En fait, la majorité des services de l'installation par défaut de Fedora utilisent maintenant un nom sur le bus après démarrage. 

  • # Doc à jour ?

    Posté par . Évalué à 7. Dernière modification le 01/10/14 à 10:33.

    C'est très sympa de traduire les articles de l'auteur de systemd. Malheureusement, je trouve qu'ils sont souvent un peu datés maintenant.

    Exemple perso : j'ai un serveur Debian où je tente d'avoir les versions récentes de systemd (ie je prends les paquets dans experimental dès qu'ils sortent). Je n'utilise pas network-manager (trop de config manuelle avec des bridges, vlan, hostapd, …).

    Initialement, j'avais désactivé network-manager avec un "exit 0" dans le script. Le passage à systemd m'a fait perdre cette modif sans m'en avertir. Une fois le bug trouvé (hostapd ne fonctionnait pas à cause de network-manager. En outre, arrêter manuellement network-manager n'a pas suffit : il désactivait l'interface wifi et rfkill a été nécessaire pour le réactiver).

    Pour rendre cette modif permanente, j'ai utilisé la commande
    systemctl disable network-manager
    Ça a bien marché jusqu'à la mise à jour de network-manager qui a relancé le démon, ce qui a désactivé hostapd :-(

    Je viens de tenter d'utiliser
    systemctl mask network-manager
    J'ai trouvé cette astuce dans un article sur le web. On verra à la prochaine mise à jour de network-manager si ça marche vraiment. Mais ça me gène de voir de nouveaux articles d'administration de systemd qui ne parlent pas de cette commande…

    • [^] # Re: Doc à jour ?

      Posté par . Évalué à 10.

      Ça a bien marché jusqu'à la mise à jour de network-manager qui a relancé le démon, ce qui a désactivé hostapd :-(

      Ça me paraît plus être un problème de packaging qui ne devrait pas réactiver un service désactivé.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Doc à jour ?

        Posté par (page perso) . Évalué à 6.

        Sale manie chez Debian de toujours tout vouloir démarrer. Bordel, ils pourraient pas laisser ça à Ubuntu… ben si, c’est plus simple pour l’utilisateur "lambda".

        Love – bépo

        • [^] # Re: Doc à jour ?

          Posté par . Évalué à 7.

          Ça n'est pas le problème. Le problème c'est qu'il revient silencieusement sur ta configuration.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Doc à jour ?

            Posté par . Évalué à 1.

            C'est un peu lié : à l'installation/upgrade du paquet :
            - le démon est activé
            - le démon est lancé

            Faire un seul des deux serait bizarre (dans un cas, le démon ne serait pas lancé, mais le serait au prochain boot ; dans l'autre il serait lancé, mais ne serait pas relancé au prochain boot). Mais personnellement, je préfère qu'il ne fasse aucun des deux.

            À l'époque, sur debian, la solution pour désactiver un service de façon permanente était de trouver un /etc/default/ qui contenait une variable qui était lu par le script init. Si la variable était sur « disabled » par exemple, le script init ne lançait pas le démon, même s'il était actif.
            Je ne sais pas si c'est toujours le cas sur les debian récentes mais pré-systemd. Ni comment ça se passe avec systemd…

            • [^] # Re: Doc à jour ?

              Posté par . Évalué à 9.

              À l'époque, sur debian, la solution pour désactiver un service de façon permanente était de trouver un /etc/default/ qui contenait une variable qui était lu par le script init. Si la variable était sur « disabled » par exemple, le script init ne lançait pas le démon, même s'il était actif.

              Et t'a pas l'impression que ça ressemble sacrément à la désactivation de systemd ? Ce que je dis c'est que quand tu fais un systemctl disable machin.service apt ne devrait pas revenir dessus sans t'en parler. Tout comme il ne reset pas les variables du fichier /etc/default.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Doc à jour ?

              Posté par . Évalué à 3.

              Faire un seul des deux serait bizarre (dans un cas, le démon ne serait pas lancé, mais le serait au prochain boot ; dans l'autre il serait lancé, mais ne serait pas relancé au prochain boot).

              Je viens de comprendre, il faut pas qu'apt soit considérer comme un lanceur manuel, mais comme un déclencheur (ou alors qu'il vérifie si le service est désactiver avant de le lancer au pire). Je ne sais pas comment c'est faisable.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Doc à jour ?

              Posté par . Évalué à 4.

              À l'époque, sur debian, la solution pour désactiver un service de façon permanente était de trouver un /etc/default/ qui contenait une variable qui était lu par le script init. Si la variable était sur « disabled » par exemple, le script init ne lançait pas le démon, même s'il était actif.

              Ça marche pour certains mais c'est pourri : le script est tout de même lancé pour finalement ne rien faire. C'est une non-optimisation.

              Si on devait attendre Debian pour accélérer les temps de boot…

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Doc à jour ?

            Posté par (page perso) . Évalué à -1. Dernière modification le 01/10/14 à 17:26.

            Tu chipotes très cher. Qu’il y revienne silencieusement ou non, le fait est qu’il va démarrer quelque chose sans te demander ton avis, quoi qu’il arrive.

            Love – bépo

            • [^] # Re: Doc à jour ?

              Posté par . Évalué à 7.

              Ça c'est un débat vieux comme Debian. Je m'en fou. Si vraiment vous avez envi de vous taper un trip relisez les quantités de troll qu'on peut trouver sur linuxfr, les maillings lists, les forums voir les archives IRC.

              Je ne parle pas de changer le comportement de Debian, mais de garder la fonctionnalité qu'il y avait jusqu'à la Squeeze à savoir, tu met la bonne variable à "disable" dans /etc/defaults et ça disable le service de façon permanente. Pour continuer à garder (et je parle bien de garder, pas de faire évoluer quoi que ce soit), il ne faudrait pas qu'apt remette en cause un "systemctl disable ...".

              Le fait qu'il lance les services directement, n'est pas lié à systemd et n'est pas nouveau. C'est peut être un problème, mais ce n'est pas un bug, mais la politique du projet.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Je vois qu’on a plus besoin de moi :P

    Posté par (page perso) . Évalué à 10.

    C’est moi qui ai lancé et traduit (en partie) les premiers articles de la série, et je suis content de voir que des gens ont suivit pour traduire la suite. De plus, je trouve que ces trois articles sont plus intéressants que les précédents.

    Néanmoins, je suis étonné de ne pas l’avoir vu dans l’espace de rédaction! Du coup j’ai quelques remarques:

    • Pourquoi ne pas avoir traduit Unit en unité comme il est fait régulièrement dans les dépêches et commentaires sur systemd?
    • Plusieurs fois dans l’article systemd est écrit avec une majuscule alors qu’il ne devrait pas.
    • Un titre se nomme «Plongeons-nous dedans.», je ne sais pas si c’est fait exprès mais je trouve ça assez étrange un point dans un titre.
    • «symobliques»: je pense que c’est «symboliques». :)

    Pour finir, je dirais qu’il faut faire attention aux traductions trop littérales mais c’est toujours difficile…

    Écrit en Bépo selon l’orthographe de 1990

  • # pour masquer un service

    Posté par . Évalué à 5.

    systemctl mask "service". (il existe aussi unmask)

    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Intérêt sur un serveur ?

    Posté par (page perso) . Évalué à -10.

    J'ai besoin d'être rassuré, là. N'y aurait-il que moi pour penser que systemd n'a quasiment aucun intérêt sur un serveur ? Sauf le fait de tout complexifier ?

    Ca me rappelle quand j'ai tenté de clusteriser mon NFS avec une bascule (SAN) du /var/lib/nfs. La galère avec systemd (sources dans mon bouquin) !

    • [^] # Re: Intérêt sur un serveur ?

      Posté par . Évalué à 4.

      Oui, il n'y a que toi.

      Va lire la série "systemd for administrators" (à ce jour, il y a 19 chapitres), et reviens.

      7th Myth: systemd is only for desktops.

      That is certainly not true. With systemd we try to cover pretty much the same range as Linux itself does. While we care for desktop uses, we also care pretty much the same way for server uses, and embedded uses as well. You can bet that Red Hat wouldn't make it a core piece of RHEL7 if it wasn't the best option for managing services on servers.

      People from numerous companies work on systemd. Car manufactureres build it into cars, Red Hat uses it for a server operating system, and GNOME uses many of its interfaces for improving the desktop. You find it in toys, in space telescopes, and in wind turbines.

      Most features I most recently worked on are probably relevant primarily on servers, such as container support, resource management or the security features. We cover desktop systems pretty well already, and there are number of companies doing systemd development for embedded, some even offer consulting services in it.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Intérêt sur un serveur ?

      Posté par . Évalué à 10.

      systemd n'a quasiment aucun intérêt sur un serveur ? Sauf le fait de tout complexifier ?

      Hahaha, comme si SysV était tout simple :-)

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Intérêt sur un serveur ?

      Posté par (page perso) . Évalué à 8.

      J'utilise systemd sur mon routeur, un Bubba 3 avec une archlinux arm customisée. Systemd y était par défaut.

      Ce qui m'a plu jusqu'ici, et qui me ferait choisir systemd pour un futur serveur:
      - Lancer un service en chroot est facile (fait avec Nginx)
      - Fichiers de service relativement* simple à écrire (*: passée la phase d'apprentissage)
      - Monitoring de l'état du système, avec un listing des services actifs plus propre que ps
      - Possibilité de préparer le système pour restreindre les accès d'un service (ex: /tmp privée, restriction d'accès aux répertoires, préparation d'un espace dans /run, …)
      - Meilleure récupération des logs et du stdout/stderr notamment lors du démarrage (bien que je ne sois vraiment pas copain avec journalctl, je suis encore paumé dans les options)

      Au final, je trouve systemd plus simple et plus complet.

      -- Blabla supplémentaire --

      Le Bubba 3 est livré d'origine avec une Debian un peu trafiquée qui utilisait des scripts d'init "habituels" (je n'ose pas parler de SysV init car je ne suis pas sûr). À l'époque de la Debian, j'avais voulu ajouter un service de terminal par web (anyterm). Et entre la configuration d'Apache et l'architecture pas claire des scripts d'inits (peut être à cause de la différence avec Arch) j'avais préféré lancer le service à la main quand je redémarrais le serveur au risque de l'oublier. Face à ça, lancer Nginx en chroot en quelques lignes de config, on se dit "cool".

      Pareil pour le lancement d'un service Flask avec Gunicorn. J'ai mis un peu de temps à avoir une config stable à cause du fichier de PID qui n'avait pas les droits d'accès au dossier jusqu'à ce que je tombe sur l'option RuntimeDirectory (très mal documentée). Il y avait aussi le problème qu'en forkant, Gunicorn n'héritait pas du contexte pour stdout/stderr et je perdais des logs (corrigé par une option dans Gunicorn).

      Au moment de Shellshock, j'ai trouvé pratique de pouvoir avoir un œil sur tous les services en cours, y compris les programmes lancés par l'(les) utilisateur(s) (admin en l'occurence).

      Sur mon routeur, il y a une petite LED. Avec un petit script Python et DBus, ça me permet de changer la couleur de la LED selon que le système est sain ou qu'un service est mort. Pratique.

      Dans les moins, il y a la configuration à la main qui est quasi-impossible si systemd n'est pas accessible, par exemple pour configurer une carte SD qui doit avoir une configuration réseau particulière dès le démarrage et sans autre accès console (cf. RaspberryPi et autre Cubietrucks), et la configuration explosée dans plein de fichiers avec des syntaxes différentes (hostname.conf, vconsole.conf, …)

      Et aussi ce qui m'a fait détester systemd pendant longtemps : je suis pas du tout fan des commandes systemctl et journalctl qui sont AMHA trop longues à taper et trop confuses (pourquoi systemctl help ça ne marche pas alors qu'on doit taper systemctl status et pourquoi journalctl sans option commence au début du journal, genre il y a deux ans, et pas aux entrées les plus récentes ?)

    • [^] # Re: Intérêt sur un serveur ?

      Posté par (page perso) . Évalué à 6.

      N'y aurait-il que moi pour penser que systemd n'a quasiment aucun intérêt sur un serveur ?

      Un peu ennuyant ce comique de répétition.

      • [^] # Re: Intérêt sur un serveur ?

        Posté par . Évalué à 10.

        T'es sur linuxfr ! Le seul site où jamais ton clavier ne se blo

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Intérêt sur un serveur ?

        Posté par . Évalué à -2. Dernière modification le 01/10/14 à 15:12.

        Il semblerait que plus d'une linuxien espèrent la bronsonisation de systemd

        • [^] # Re: Intérêt sur un serveur ?

          Posté par (page perso) . Évalué à -1. Dernière modification le 01/10/14 à 15:20.

          Ah… Le retour de la résistance au changement…
          Ca n'a pas mis bien longtemps avant d'arriver.
          Pas "plus d'un", es-tu capable de dire combien en pourcent? Si ils sont nombreux, pourquoi donc aucune distribution majeur ne décide de leur faire plaisir rien que pour leurs beaux yeux?
          Bref, plus d'un, je n'en doute pas, par contre assez pour construire une alternative viable, j'ai comme un doute. Juste des râleurs qui se cacheront de honte dans 10 ans, et auront trouvé un autre bouc-émissaire pour leur plaisir de se plaindre de l'évolution technologique.

          PS : le bronsoniser, oui, mais le remplacer par quoi? Un truc qui soit adapté au monde d'aujourd'hui, hein, pas les trucs qui sont fait la raison du changement vers systemd…

          • [^] # Re: Intérêt sur un serveur ?

            Posté par . Évalué à 4.

            Je crois que soit il se fout de systemd soit il est pour, il juste sorti un comique de répétition ancestral de linuxfr.

            T'as pas beaucoup d'humour aujourd'hui.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Intérêt sur un serveur ?

              Posté par (page perso) . Évalué à 2. Dernière modification le 01/10/14 à 15:24.

              Non, de souvenir sur ses commentaires, le pire est que c'est un comique de répétion sérieux. Du coup je répète aussi.

              Mais la blague n'est sans doute pas bien passée. Après, pas évident avec les comiques de répétition sérieux.

              • [^] # Re: Intérêt sur un serveur ?

                Posté par . Évalué à 3.

                Après relecture je comprends, mais c'est vraiment subtile.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Intérêt sur un serveur ?

                Posté par . Évalué à 2.

                Tu dois me confondre avec un autre, je viens de vérifier dans mon tableau de bord et je n'ai pas retrouvé le moindre commentaire de ma part sur systemd.

                • [^] # Re: Intérêt sur un serveur ?

                  Posté par . Évalué à 4.

                  Il a répondu avec sa batteries d'argents classique en considérant les troll systemd comme un running gag dont il fait parti.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Intérêt sur un serveur ?

              Posté par . Évalué à 4.

              +1 pour cette interprétation.
              Ma Debian Jessie est passé à systemd sans que je m'en rende compte, c'est vous dire si systemd ou autre ça me touche.

          • [^] # Re: Intérêt sur un serveur ?

            Posté par . Évalué à 4.

            […] le bronsoniser, oui, mais le remplacer par quoi?

            OpenRC?

            Bon, d'accord.

            -->[]

      • [^] # Re: Intérêt sur un serveur ?

        Posté par (page perso) . Évalué à 9.

        Un peu ennuyant ce comique de répétition.

        De toutes façons un serveur, ça tourne sous BSD, non?

      • [^] # Re: Intérêt sur un serveur ?

        Posté par (page perso) . Évalué à 1.

        Enfin un qui m'a compris :-)

  • # Lennard Poettering...

    Posté par . Évalué à 7.

    … car c'est un vrai démon.

    -->[]

  • # service

    Posté par (page perso) . Évalué à 3.

    Voici un exemple avec le service NTP:

    $ systemctl stop ntpd.service

    C'est globalement équivalent à la commande traditionnelle disponible sur la plupart des systèmes basés sur SysV:

    $ service ntpd stop

    Dans les faits, sur Fedora 15, si vous exécutez cette dernière commande, elle sera convertie de manière transparente

    Ce n'est pas tout à fait ça. La commande traditionnelle avec SysV rc est /etc/init.d/ntpd stop. Pour d'autres gestionnaires de services, la commande est différence, notamment pour systemd systemctl stop ntpd.service. Il me semble que la commande service a été introduite pour permette de lancer, d'arrêter et de relancer des services indépendamment du gestionnaire de service, en prenant en charge SysV rc et upstart, puis OpenRC et systemd. Même avec systemd, il est donc utile d'utiliser de préférence cette commande, puisqu'elle fonctionnera même si vous vous retrouvez sur une machine qui utilise par exemple SysV rc.

    • [^] # Re: service

      Posté par . Évalué à 5.

      Je ne connais pas l'historique entre service, le lancement direct de script et invocke-rc.d. Mais AMHA, il est vivement déconseillé de lancer directement le script à cause des effets bords possibles si le script ne nettoie pas son environnement (indépendamment de shellshock).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # CPUSchedulingPolicy

    Posté par (page perso) . Évalué à 1.

    Ou bien, nous pourrions utiliser CPUSchedulingPolicy=idle pour s'assurer que les processus abrtd crashent en tâche de fond uniquement, en autorisant le noyau à donner sa préférence à tout ce qui fonctionne et qui a besoin de temps CPU.

    Je pense qu'un s/crashent/tournent/ (ou une réécriture) s'impose.

    D'après ma lecture de la VO, il s'agit plutôt de « s'assurer qu'ABRT traite les traces de crash en tâche de fond uniquement ».

    Debian Consultant @ DEBAMAX

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.