Sylvain Blandel a écrit 248 commentaires

Bon, très mauvaise idée !

Ah mince.

On peut essayer autre chose : le paramètre single est interprété par systemd pour lancer la cible rescue.target (plutôt que la cible default.target). Donc : édite à la volée Grub au démarrage, mais cette fois-ci dans le mode « normal » (pas le mode « recovery »). Enlève le quiet et ajoute single après le init=/lib/systemd/systemd

Sans le quiet, tu auras plus de messages au boot.

Dès la première commande ça part mal.

Hum … J'ai le pré-sentiment que, lorsque tu démarres en choisissant le mode « de secours » de Grub, ce n'est pas systemd qui est lancé (c'est certainement SysVinit qui est lancé).

Regarde le fichier de configuration de Grub, et compare les options du mode « normal » et du mode « de secours ».

Il me semble que ça arrive quand on créé une boucle de dépendance, par exemple un service qui voudrait démarrer avant Dbus et après Dbus.

Oui, ça ressemble à une boucle entre dbus.socket et sockets.target.

Tu peux essayer ceci :

1. Démarre ton système en utilisant le mode « de secours » dans Grub.

2. Une fois ton système démarré, lance les 2 unités en question :
   systemctl start dbus.socket
   systemctl start sockets.target

3. Tape les trois commandes précédentes.

4. Pour voir les liens entre ces deux unités, tu peux taper :
   systemctl show dbus.socket | grep sockets.target
   systemctl show sockets.target | grep dbus.socket

Donne-nous le retour de ces différentes commandes.

Slackware risque de passer à systemd. Pas par amour, mais parce que ça va devenir impossible de faire autrement : lien

Le message que tu pointes date d'octobre 2013, c'était il y a 6 mois. À l'époque, le comité technique Debian n'avait pas encore rendu sa décision. Et Ubuntu n'avait pas annoncé sa migration vers systemd.

Le shell, ça permet de faire un peu plus de chose que systemd, genre c'est un outil de base pour administrer / jouer avec un unix, pas juste l'init.

Ça tombe bien, systemd est bien plus qu'un système d'initialisation. Systemd permet d'arrêter/redémarrer/mettre en veille la machine, de lancer/suivre/arrêter les services, de lister les services défaillants, de créer et gérer des fichiers temporaires, de démarrer des services selon des contraintes temporelles, de gérer les logs du système. Et il y a également d'autres fonctionnalités.

Peut-être que dans 15 ans, « être un(e) excellent(e) administrateur(trice) de système linux » signifiera « maitriser parfaitement systemd », et qu'une connaissance poussée du shell sera devenue facultative ?

Tout ça est joyeusement hackable car après tout ce n'est que du shell, tu peux paralléliser comme bon te semble, genre: "appel à script & " etc.. et tu peux gruiker/coder/modifier tout ce que tu veux, […] On se fait plaisir, on utilise des outils classiques comme vi/grep/sed/awk pour administrer la machine et c'est joyeux.

D'un système qui se hackait au script shell, […] Avant, il suffisait de trois lignes en shell.

Tu démontres que, sous SysVinit, les utilisateurs sont contraints d'apprendre le shell pour administrer leurs machines. Qu'ils sont forcés d'apprendre le fonctionnement des outils vi/grep/sed/awk/cat/less. S'ils veulent personnaliser finement leurs machines, on leur impose de savoir écrire des scripts.

Sous systemd, les utilisateurs sont contraints d'apprendre le fonctionnement de systemd pour administrer leurs machines. Ils sont forcés d'apprendre le fonctionnement de la commande systemctl. Si les utilisateurs veulent personnaliser finement leurs machines, on leur impose de savoir écrire des fichiers .service.

Tu as fait l'effort d'apprendre le shell. Après avoir passé des heures à suivre des tutoriels et à lire des pages de manuel, tu maîtrises cet outil. Tu écrits des scripts facilement et rapidement. Cela te convient très bien, tu es l'aise avec le shell.

Nos successeurs apprendront systemd. Et, une fois la période d'apprentissage passée, ils seront à l'aise avec cet outil.

mot compte triple …

Réponse !

Pour Apache, Debian utilise :
[…]

Sous RHEL :
[…]

Et bien sûr les contenus des arborescences et fichiers sont souvent différents.

Je suis étonné que, pour un même logiciel, il y ait autant de différences d'une distribution à l'autre ! À quoi cela est-il dû ?

Allez donc suivre la rédaction de celle-ci et préparez vos arguments :

Pourquoi ?

Les débats concernant systemd ont été forts nombreux, toutes les personnes intéressées par ce sujet ont eu le temps de lire, réfléchir et tester. Leurs opinions sont déjà faites. À quoi servira un énième débat sur le sujet ?

Totof2000 : comme beaucoup, tu n'aimes pas systemd. Il me semble que le temps passé à en discuter ici servirait bien mieux votre cause si, par exemple, vous vous proposiez de maintenir SysVinit sous Debian, ou bien si vous contribuiez à une alternative à systemd (par exemple : OpenRC). Ce travail aurait plus d'influence sur l'avenir que nos discussions à rallonge.

Par curiosité, c’est quoi l’intérêt de lancer Firefox avec systemd ?

Pour Firefox, euh … Je ne sais pas :o)

Firefox n'est qu'un exemple de logiciel lancé par l'utilisateur (plutôt que par root). L'intérêt des sessions utilisateurs de systemd est d'imposer des conditions et contraintes aux logiciels, même lorsqu'ils sont lancés par l'utilisateur. Malheureusement, plusieurs options intéressantes fonctionnent avec les services lancés par root, mais pas avec les services lancés par l'utilisateur :-(

Voici un service que fonctionne, même lorsqu'il est lancé par l'utilisateur :

$ cat /home/moi/.config/systemd/user/essai.service


[Unit]
Description=essai dans la session utilisateur de moi
ConditionPathExists=/tmp/machin
ConditionACPower=true

[Service]
ExecStart=/usr/bin/chmurck
Nice=14
IOSchedulingClass=idle
WorkingDirectory=/tmp/bac-a-sable
Type=simple
Environment="VAR1=word1 word2"
StandardOutput=syslog
Restart=always

Le nom de chaque option est un lien vers la section adéquate du manuel.

Je n'ai pas d'exemple en tête où ces options seraient pertinentes. Des idées ?

En faisant ifconfig, je me retrouve bien juste avec l'interface lo : loop.

La commande ifconfig ne montre que les interfaces existantes et actives. Pour avoir toutes les interfaces existantes (les actives et les inactives), il faut faire ifconfig -a

Si jamais ton interface wifi apparaît avec ifconfig -a, trouve le module du noyau qui pilote cette interface (avec la commande lspci -k). Ensuite, stoppe ce module avec la commande modprobe -rv LeModuleEnQuestion

La version 212 de systemd est sortie.

Tu peux compléter la section http://linuxfr.org/wiki/aide-edition#code pour indiquer ces autres utilisations connexes, au besoin :-)

C'est fait :o)

Pour mettre en forme le code contenu dans les unités systemd, la balise ini est pratique.

Le code suivant :

---

```ini
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u bind
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target
```

---

donnera ceci :

---

[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u bind
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

---

Quelle technique utilises-tu ?

Pour avoir Firefox démarré par ma session utilisateur de systemd, j'ai crée le fichier /home/moi/.config/systemd/user/firefox.service dont voici le contenu :

[Unit]
Description=Firefox dans ma session utilisateur

[Service]
ExecStart=/usr/bin/firefox
Type=simple

Ensuite, je me connecte graphiquement. Et en tant qu'utilisateur, je fais :

systemctl --user import-environment
systemctl --user start firefox.service

Remarque : la commande systemctl --user daemon-reload peut servir si on modifie les fichiers .service de l'utilisateur.

Simpa ! J'avais essayé de faire fonctionner xorg avec systemd il y a bien 6 mois, mais ce fut un cuisant échec.

Le contenu de cette page devrait te plaire. :-)

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