Sylvain Blandel a écrit 258 commentaires

Le réseau social Google+ semble rencontrer un certain succès parmi les développeurs de logiciels libres.

En août 2013, pour annoncer la maintenance étendue du noyau 3.10, Greg Kroah-Hartman avait utilisé son blog personnel (il avait ensuite repris cette annonce sur son compte Google+).

Aujourd'hui, pour annoncer la maintenance étendue du noyau 3.14, Greg n'utilise pas son blog personnel, mais uniquement son compte Google+.

De même, Lennart Poettering a annoncé le mois dernier qu'il communiquait plus souvent via son compte Google+ que via son blog :

Just a small heads-up : I don't blog as much as I used to, I nowadays update my Google+ page a lot more frequently. You might want to subscribe that if you are interested in more frequent technical updates on what we are working on.

Pour les utilisateurs d'Archlinux, le paquet « linux-lts » est déjà passé à cette nouvelle version « LongTerm Stable » du noyau (architecture i686, architecture x86_64).

Bonjour

mon dernier apt-get dist-upgrade m'a fait passer sous systemd

L'installation de systemd a-t-elle désinstallée SysVinit, ou bien as-tu systemd et SysVinit installés simultanément ?

Si les deux sont installés simultanément, tu peux choisir lequel est lancé au démarrage de ton système d'exploitation. De mémoire, le choix se fait avec l'option init=/le/bon/binaire qu'il faut ajouter à la ligne kernel de ton chargeur de démarrage (lorsque cette option n'est pas mentionnée, la valeur par défaut est init=/sbin/init).

Ainsi il suffit d'être ROOT pour arrêter ou relancer un service […] en étant simplement ROOT on peut envoyer […] créer une nouvelle unit.

J'ignore si cela peut résoudre les problèmes que tu rencontres : des utilisateurs non-root peuvent créer, lancer et stopper des unités systemd. Ce fil de discussion en parle, de même que cette page.

Red Hat Enterprise Linux est la première distro entreprise à utiliser systemd

Oui, et d'après cette page, la prochaine version majeure de SUSE Linux Enterprise (la version 12) utilisera elle aussi systemd. On trouve également des références à systemd dans les notes de publication de la (future) version 12 de SUSE Linux Enterprise Server.

Cette évolution n'est guère étonnante : openSUSE utilise systemd depuis novembre 2011.

Que va-t-il rester comme distributions n'utilisant pas systemd par défaut ?

Les distribs Linux s'éloignent de plus en plus des systèmes Unix.

Oui, systemd n'est pas prévu pour les systèmes Unix \(ö)/

OOOOh, c'est beau systemd. C'est simple, ça marche, et quand il y a un problème c'est facile à résoudre.

Le problème qui nous intéressait ici était causé par un changement de système d'init. C'est une opération grave, il ne s'agit pas d'une mise-à-jour de gedit : un élément prépondérant du système est migré d'une technologie à une autre. Cette migration technologique n'a pas, à ma connaissance, d'équivalent (on pourrait peut-être comparer cela aux migrations Gnome 2 → Gnome 3, ou KDE 3 → KDE 4). Vu l'envergure de ce bouleversement, il n'est guère étonnant qu'il y ait des problèmes (surtout que le système d'exploitation utilisé ici est une version unstable).

Puisque nous ne sommes pas habitués à la nouvelle technologie, les problèmes rencontrés nous semblent complexes. Nous perdons l'aisance que nous avions avec la vieille technologie. Faites comme les jeunes : plongez-vous dans les pages de manuel !

Ne va-t-il pas manquer quelques pattes à systemd ?

À systemd lui-même, je pense que non.
Les fichiers de systemd « brut de décoffrage » sont dans /lib/systemd/. Et les modifications réalisées par l'administrateur sont écrites dans /etc/systemd/. Bien évidemment, lorsque le système fonctionne, /etc/systemd/ est prioritaire sur /lib/systemd/.

Pour savoir s'il te manque des trucs dans /etc/systemd/, il faudrait comparer avec une installation fraîche de Debian Sid.

---

Pour rechercher les éventuels messages d'erreur, tu peux consulter le journal avec la commande :

sudo journalctl

Pour n'avoir que les messages depuis le dernier boot, c'est l'option -b. Et pour filtrer les messages importants, c'est l'option -p.

À titre personnel, j'utilise :

sudo journalctl -b -p notice


Bon, il y a du mieux :-)

redémarre en mode normal + single : Le démarrage se fait en mode rescue (?)

C'est normal.
Lorsque l'on démarre son ordinateur avec systemd, single est un raccourci de systemd.unit=rescue.target. Cela démarre le strict minimum, ainsi qu'un shell de secours. Voir ici : lien1, lien2, lien3.

Maintenant que ça fonctionne : tu devrais avoir un démarrage normal en n'utilisant pas single.

---

Je m'attendais à ce que le répertoire /etc/systemd/system/ soit recréé, mais non.

Hum … Je pense que tu devrais le recréer manuellement, même en le laissant vide pour l'instant.

---

Il a fallut sudo /etc/init.d/network-manager restart

Ça, c'est la méthode SysVinit pour démarrer des services. Si tu utilises systemd, il convient d'utiliser la méthode systemd :

1. Dans le répertoire /lib/systemd/system/ cherche le fichier .service de Network Manager (ça devrait être « NetworkManager.service »). Il s'agit d'un fichier texte, tu peux le consulter par curiosité.
2. Pour lancer Network Manager : sudo systemctl start NetworkManager.service
3. Pour automatiser le lancement de Network Manager au démarrage : sudo systemctl enable NetworkManager.service

Cette dernière commande modifiera le contenu du répertoire /etc/systemd/system/. Les modifications apparues signifient que Network Manager est une dépendance du niveau d'exécution « multi-user.target ».

Cette méthode est valable pour tous les services que tu souhaites lancer au démarrage.

---

Il est probable que tu n'aies qu'un seul terminal virtuel, accessible par Ctrl+Alt+F1, et que Ctrl+Alt+F2, Ctrl+Alt+F3, … ne donnent rien. Pour avoir plusieurs terminaux virtuels, voir cette page.

Bon, ben, pas mieux

Argh !

Tant pis, on bourrine : démarre ton système en utilisant le mode recovery de Grub (systemd ne sera pas lancé). Une fois l'ordinateur démarré, fais une copie de sauvegarde du répertoire /etc/systemd/system/, puis recherche et efface dans ce répertoire (et ses sous-répertoires) tout ce qui a trait a dbus.socket et sockets.target. Tu peux même essayer d'effacer tout le contenu de /etc/systemd/system/

Une fois ce ménage réalisé, essaie de démarrer ta machine, avec systemd cette fois-ci. Dans un premier temps, essaie avec le paramètre single (en éditant Grub à la volée).

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