Sylvain Blandel a écrit 258 commentaires

À ce sujet : Remplacer cron par systemd

Quand au compare au simple crontab -e puis ajouter une simple ligne, ça a l'air très alambiqué tout ça quand même.

Pas faux. :-)

Ceci étant, pour utiliser cron, on ne peut pas se contenter du seul fichier crontab, on doit également avoir un script qui lance le service cron. Ce script est généralement placé dans le répertoire /etc/init/ (on se contente habituellement du script écrit par le mainteneur de la distribution).

Bien entendu, on peut avoir systemd comme gestionnaire d'init et de services, et continuer à utiliser le classique cron.

systemd est 99% rétro-compatible avec les scripts, hein.

C'est exact, on peut parfaitement utiliser ses scripts SysVinit avec systemd.

Je pense que nous ne parlons pas exactement de la même chose… Je parle de : Processus Zombie.
[…]
Toi tu me parles d'un démon type apache qui démarre 20 processus fils. Et dans certains cas, si on tue le père, certains fils peuvent migré vers le nouveau père supérieur (PID1) sans être tué.
[…]
Ai-je bien compris ?

Hum … oui. Finalement, mon commentaire concernait plus les processus orphelins que les processus zombies.

Si c'est ça, systemD fait office de garde pour les bugs des démons du système. Bug qui seront encore plus difficile à repérer puisque masqué par cette fonctionnalité.

La façon dont systemd termine un service est paramétrable. D'après la documentation, le comportement que tu souhaites est possible en mettant les paramètres suivants dans le fichier .service :

KillMode=none
ExecStop=/usr/bin/CommandeChargéeDeTerminerLeService arguments

Aucun souci, sauf quand il faut tuer le processus. Oups, un zombie.

[…] dire que les processus Zombies sont une marque de mauvais système d'init me semble capilotracté.

Il n'est pas question ici de « systemd, le système d'initialisation », mais de « systemd, le gestionnaire de services ».

Lorsqu'on demande à systemd de lancer un service, le comportement par défaut est d'isoler le programme lancé ainsi que tous ses descendants dans un nouveau groupe de contrôle. De cette façon, le processus lancé et tous ses descendants sont clairement identifiables : ils sont tous dans le même groupe de contrôle.

Plus tard, lorsqu'on demande à systemd d'arrêter ce service, il zigouille tous les processus contenus dans le groupe de contrôle en question. C'est une différence importante avec le traditionnel SysVinit : lorsque systemd arrête un service, il ne se contente pas d'exécuter une commande (qui doit stopper des processus), il met à mort l'ensemble des processus contenus dans le groupe de contrôle. Autrement dit, systemd termine tous les processus que le service à engendré.

De cette façon, je ne vois pas comment il peut y avoir des processus zombie.

Remarque : la façon dont systemd arrête un service est évidemment paramétrable, voir les options ExecStop et KillMode.

À propos des timers, comment se comportent-ils lorsqu'un évènement se produit alors que le PC était éteint ?

Je viens d'essayer avec un PC en veille.

L'évènement devait se produire à 17h, mais le PC était en veille à cette heure-là. Résultat : l'évènement s'est produit immédiatement au sortir de la veille.

À ce sujet : Remplacer cron par systemd

Les sessions utilisateurs de systemd gagnent également la commande import-environment :

$ systemctl --user import-environment

systemctl gained a new "import-environment" command which uploads the caller's environment (or parts thereof) into the service manager so that it is inherited by services started by the manager. This is useful to upload variables like $DISPLAY into the user service manager. (notes de publication de systemd 209)

Je poste ce message depuis Firefox démarré par ma session utilisateur de systemd !

est-ce qu'il existe une doc claire, exhaustive et précise sur ce que fait/sait faire/peut faire systemd, sur ses différents modules et comment les utiliser ?

En général, les pages du manuel sont bien écrites. La page d'accueil de systemd recèle également de nombreux liens pertinents.

Une faute à corriger dans la dépêche :

Posons d’abord le décor : les développeurs du projet BlueZ a décidé de refaire leur interface

a → ont

si des projets comme Gnome imposent la présence de 'systemd'

Pendant des années, des tas de projets (les distributions Linux) imposaient la présence de SysVinit.

je veux juste conserver ma liberté de choisir

Les développeurs de logiciels, eux aussi, souhaitent conserver leur liberté de choisir. Un certain nombre d'entre eux choisissent de s'appuyer sur systemd pour faire fonctionner leur logiciel.

D'avoir des clients RSS mobiles.

Sur mon smartphone, l'application FeedEx News Reader me permet de suivre différents flux RSS (dont ceux de LinuxFr). Les flux peuvent être classés simplement, le thème foncé est reposant pour les yeux (il y a malheureusement un « flash blanc » lorsque l'on passe d'un message à un autre). Chaque flux récupère l'icône du site, cela permet de mieux distinguer les flux. On peut appliquer des filtres sur les flux (je n'ai pas utilisé cette fonctionnalité). Enfin, l'application ne demande pas des droits exagérés pour fonctionner.

Remarque : en ajoutant un nouveau flux, on peut cochez une case « Récupérer le texte complet ». Cette fonctionnalité rend les commentaires de LinuxFr incohérents, je préfère la décocher.

dans la configuration des forces en présence, Debian a un pouvoir phénoménal

Quelque ait été le choix de Debian, le développement de systemd aurait continué.

Avec cette décision de Canonical, le projet est tout simplement mort et enterré.

Non, ça signifie qu'Ubuntu n'utilisera plus Upstart. Et, assurément, que Canonical ne rémunérera plus personne pour développer ce logiciel.

Y aura-t-il du monde pour reprendre le développement d'Upstart ? On verra. J'imagine plutôt les opposants à systemd bougonner pendant quelques trimestres travailler dur pour maintenir le traditionnel SysVinit.

J'imagine qu'on peux obtenir un démarrage séquentiel (plutôt que parallèle) avec systemd. Comment ? En listant les différentes unités qui sont lancées au démarrage (il y en a un paquet) et en les personnalisant à coup de After :

[Unit]
…
After=unité-précédente

C'est certainement fastidieux à faire, mais ça me semble un bon exercice pour comprendre le déroulement d'un boot. Le schéma des différentes target du boot est un point de départ pertinent pour ce travail.

si le comité technique de Debian se résout à faire passer les fichiers de log system dans un format binaire […]

Les utilisateurs de systemd peuvent installer syslog et obtenir ainsi des fichiers de log au format texte (explications).

je me demande qu'est-ce qu'il y a de lourd à maintenir des scripts de démarrage de démons

D'après son site officiel, Nginx est

un serveur HTTP libre […] ainsi qu'un proxy inverse. […] il intègre également du proxy pour l'IMAP et le POP3.

Quand les mainteneurs d'un système d'exploitation packagent Nginx, ils doivent écrire un fichier adéquat : un script shell pour les distributions utilisant SysVinit, un fichier .service pour celles utilisant systemd, etc.

Comme les développeurs de Nginx sont des gens bons, ils proposent des fichiers prêts à l'emploi sur leur wiki. On y trouve des fichiers pour démarrer Nginx sous Debian, sous FreeBSD, sous Fedora, sous Ubuntu, et même sous OSX ! Mais malheureusement, rien pour OpenSUSE, ni pour Archlinux. Pendant que les packageurs de Debian et FreeBSD se contenteront d'un copié-collé, ceux d'OpenSUSE et d'Archlinux devront écrire eux-mêmes leur fichier. C'est vraiment injuste, ce monde est bien cruel.

Mais en fait, non.

OpenSUSE et Archlinux ont un point commun avec Fedora : l'utilisation de systemd. Lorsqu'on regarde le fichier pour lancer Nginx sous Fedora, on lit ceci :

Should work on Fedora, OpenSUSE, Arch Linux.

Aaah ! Finalement, les packageurs d'OpenSUSE et d'Archlinux pourront eux aussi copier-coller joyeusement. Ça va mieux.

Bref : toutes les distributions utilisant systemd peuvent partager le même fichier .service. Ainsi, les packageurs repompent comme des gorets s'inspirent du travail déjà réalisé par les autres packageurs. Le travail est mutualisé.

Pour répondre à ta question : j'ignore si l'écriture de scripts shell pour démarrer/arrêter un démon est pénible, et j'ignore si la maintenance de ces scripts est chronophage. C'est juste que les scripts shell ne sont guère efficaces pour encadrer les processus.

[…] SysV se bloquait lamentablement […] sur un truc trivial comme le réseau. Alors que j'aurais bien voulu qu'il me démarre le display manager pendant ce temps. ;-)

Ça dépend probablement des distributions, et de leurs versions. Lorsqu'Archlinux utilisait encore SysVinit, on pouvait démarrer des services en parallèle.

Merci Shuba.

On se dirige donc vers une Résolution Générale. Reste à voir comment celle-ci sera formulée.

La discussion du comité technique Debian dure maintenant depuis 3 mois. Plus de 900 mails ont été postés ! J'ai renoncé à tout lire.

Où en est le comité technique ? Une décision est-elle prise ? La communauté Debian votera-t-elle une Résolution Générale ?

l'intégration de tout dans systemd ce qui rend udev et d'autres utilitaires essentiels forcément dépendants de systemd

D'ailleurs : pour qu'udev soit intégré à systemd, il a bien fallu que les anciens mainteneurs d'udev choisissent d'abandonner leur travail, non ?

Que les mainteneurs de systemd aient copié-collé tout le code d'udev dans systemd, c'est une chose. Mais si la version originale d'udev (celle qui était « en dehors de systemd ») est morte, cela signifie que les anciens mainteneurs d'udev ont abandonné, non ?

Il reste encore une personne.

Qui ?
Le comité technique est composé de 8 membres (lien), et d'après ces 2 messages (premier, deuxième), ils se sont tous exprimés.

4-4 balle au centre

Et maintenant, que va-t-il se passer ? Le projet Debian va-t-il rester au statu quo, c'est-à-dire que SysVinit reste le seul système d'init officiellement supporté ? Se dirige-t-on vers un vote lors d'une résolution générale ?

si Debian adopte systemd, ça sera le moment où systemd entrera en production, la communauté peut le prendre en charge, non une seule entité.

L'Empire Red Hat juge que l'Étoile Noire systemd est prête pour dézinguer les Ewoks entrer en production. En effet, systemd sera utilisé par la version 7 de Red Hat Enterprise Linux (actuellement en béta). Sachant que le support de Red Hat Enterprise Linux peut s'étendre jusqu'à 13 années, j'en déduis que, quelque soit la décision de la communauté Debian, systemd va entrer en production. Et, durant de nombreuses années, des gens seront rémunérés pour assurer sa maintenance.

pas de possibilité d'avoir une seconde carte (même payante) sur le même compte (pour le/la coinjoint(e)).

D'après leur site, il est possible d'avoir gratuitement une seconde carte dans le cas d'un compte joint.

Un inconvénient des banques en ligne : comme elles n'ont pas d'agence physique, il est nécessaire, pour encaisser les chèques que tu reçois, de les envoyer à leur centre de traitement par courrier. Cela peut effrayer les personnes dont les courriers ont déjà été perdus, ou bien qui encaissent beaucoup de chèques.

/bin, /lib, /lib64 et /sbin ne sont plus que des liens symboliques.

Cela semble se généraliser : sous Archlinux également, /bin, /sbin et /usr/sbin sont des liens symboliques vers /usr/bin. De même, /lib, /lib64 et /usr/lib64 sont des liens symboliques vers /usr/lib.

j'ai toujours dit que le prochain truc que Lennart va péter, c'est les shells, c'est l'étape suivante logique. Mais comme sh, sainul, il va réinventer […] Allez, je vous donne le nom : shd :P

D'ailleurs, sur sa machine de travail, Lennart a réinventé la commande ls, et il l'utilise quotidiennement.