Sylvain Blandel a écrit 258 commentaires

Le bug est présent chez moi (Archlinux 64 bits, noyau 4.7.5, systemd 231-1).

La boucle suivante rend mon système « instable » :
while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done
Ce bug fonctionne même lorsque cette commande est lancée par un simple utilisateur ; et le système reste instable lorsqu'on est sorti de cette boucle avec un Ctrl+C

Pour redémarrer, la commande systemctl reboot ne fonctionnait pas, je m'en suis sorti avec systemctl reboot --force --force (attention, cela correspond à un redémarrage brutal).

Merci d'avoir compris que mon commentaire était un troll :-)
Effectivement, il ne contenait aucune argumentation pertinente. Et j'avais pris soin d'attendre vendredi pour le poster :-D

On constate avec tristesse que Slackware refuse encore systemd, en 2016 !

En s'obstinant à utiliser l'archaïque SysVinit, les développeurs de Slackware condamnent leur distribution à une fossilisation certaine. Cette décision est regrettable et incompréhensible ; tout le monde reconnaît aujourd’hui la supériorité technique et de la polyvalence de systemd.

J'espère que les développeurs de Slackware comprendront rapidement leur erreur, et qu'ils reviendront à la raison.

Et si tu démontes manuellement les systèmes de fichiers, puis que tu redémarres avec kexec ? Le message d'erreur au redémarrage persiste-t-il ?

Comment savoir que ça vient bien d'un timeout ? Je ne vois rien dans les logs avec journalctl ?

Tu peux afficher l'état de chaque unité avec systemctl :
systemctl --all

Tu peux filtrer les unités affichées selon leur état. Quelques exemples :
systemctl --all --state=failed
systemctl --all --state=not-found

---

L'outil journalctl affiche les logs. Pour n'afficher que les logs depuis le dernier démarrage :
journalctl -b

Pour filtrer les logs selon leur criticité, c'est le paramètre -p Par exemple :
journalctl -p warning

Lorsque tu as repéré l'unité déconnante, tu peux afficher uniquement les logs de cette unité, avec le paramètre -u :
journalctl -u machin.service

Toutes ces options sont cumulables.

couper le conteur

Toi, tu nous racontes des histoires :-)

Ça va être particulièrement difficile, nous ne sommes pas dans une année bissextile, et Annie Girardot a déjà photocopié du sable. Éventuellement, si Demis Roussos plume une girafe … mais tarte aux pommes.

Canonical semble ralentir le développement d'Upstart. En effet, la dernière version d'Upstart est sortie il y a 7 mois déjà (le 4 septembre 2014). Et sur la liste de discussion upstart-devel, il n'y a eu aucun mail pendant 48 jours consécutifs (entre le 19 février et le 7 avril 2015).

Cela paraît logique, vu la décision de ne plus utiliser Upstart pour les prochaines versions d'Ubuntu.

waitproctofinish(){ while pgrep -f $1 > /dev/null ; do sleep 1 ; done }

Merci, c'est bien pratique ! Je ne connaissais pas pgrep :-)

Combien de temps après le lancement de la commande shutdown est ce que des programmes peuvent effectuer des operations?

Bonjour.

Tu peux faire des tests avec la commande sleep. La commande sleep 5m attend 5 minutes avant de rendre la main. Lance cette commande, puis lance la commande shutdown. Tu verras si l'ordinateur attend 5 minutes (ou moins) pour s'arrêter.

---

Il est également possible de programmer un shutdown pour plus tard :

• Pour éteindre l'ordinateur dans 205 minutes : shutdown -h +205
• Pour redémarrer l'ordinateur à 19h23 : shutdown -r 19:23

Pour en savoir plus : man shutdown

---

Enfin, pour être certain que le shutdown s'exécute APRÈS ta commande qui prend du temps, tu peux mettre les deux commandes sur une même ligne, séparées par un point-virgule :

$ première-commande ; shutdown -h +0

La commande shutdown ne s'exécutera que lorsque la première-commande sera terminée.

La réponse donnée sur l'autre site n'est finalement que l'application d'un conseil donné ici : modifier manuellement le fichier grub.cfg pour y ajouter une entrée de démarrage.

Quelques remarques cependant :

Il est possible que vous n'utilisiez pas msdos mais sda (plus rare me semble-t-il)

Il me semble que ce sont deux thématiques différentes : « msdos » est un schéma de partitionnement du disque dur, l'autre schéma possible est « gpt ». L'utilisation de « sd× » ou de « hd× » pour désigner les disques durs est fonction du systèmes d'exploitation. Je suis très étonné de voir la vieille notation « hd× » pour un système qui utilise Grub2 (qui doit donc être récent).

les lignes insmod part_msdos et set root='hdo,msdos6' seront donc à modifier en utilisant le mot "sda"

Les utilisateurs d'un disque dur partitionné suivant le schéma « gpt » utiliseront insmod part_gpt ainsi que set root='hd0,gpt6'

Euh … set root='hdo,msdos6' … hdo ??? La lettre « o » ??? Sainte Merde ! Il y a combien de disques durs dans ta machine ?

La ligne insmod btrfs peut spécifier un autre système de fichiers (ext2 par exemple).

La liste des modules disponibles est dans le répertoire /boot/grub/ Ce sont les fichiers en .mod. On peut en mettre beaucoup plus que nécessaire :

    insmod btrfs
    insmod ext2
    insmod fat
    insmod zfs
    insmod reiserfs

On peut même mettre les deux schémas de partitionnement, ça ne pose pas de problème :

    insmod part_gpt
    insmod part_msdos

il me semble que grub vient avec une commande update-grub

Il me semble que la commande update-grub est un script qui ne contient qu'une seule ligne, et que cette ligne est :

grub2-mkconfig -o /boot/grub/grub.cfg


si les outils automatiques ne fonctionnent pas tu peux aussi editer le fichier de config à la main pour copier/coller l'existant et changer le nom du noyau qui est appelé

Entièrement vrai. De très nombreux tutoriels déconseillent d'éditer manuellement le fichier /boot/grub/grub.cfg … c'est pourtant ce que je fais régulièrement. Après avoir fait une copie de sauvegarde du fichier grub.cfg initial, je bricole ce fichier.

Il est préférable de faire des copies de sauvegarde de ton grub.cfg lorsque tu le modifies. En effet, selon les distributions, une mise-à-jour de grub ou du noyau peut générer un nouveau grub.cfg et écraser tes paramétrages personnels.

Remarque : chez moi, le fichier grub.cfg n'est pas dans le répertoire /boot/grub2/ mais dans /boot/grub/ J'imagine que cela dépend des distributions.

Des prédictions pour l'année 2015 ? Des recommandations de sujets pour l'écriture de dépêches collaboratives ?

Un sujet pour 2015 : quel avenir pour Devuan (le fork de Debian sans systemd) ?

• devuan.org
• Journal du 19 octobre 2014 : Un fork de Debian à cause de systemd ?
• Journal du 29 novembre 2014 : Devuan forks Debian : un choc, ou c'était inévitable ?

En février 2014, Debian a adopté systemd comme système d'initialisation par défaut sur les architectures basées sur le noyau Linux. Cette décision fut prise après de trèèèèès longs débats.

9 mois plus tard, des discussions portent sur le support simultané de plusieurs systèmes d'init. En effet, une Résolution Générale est actuellement votée par les contributeurs du projet Debian, le vote se clôture dans une semaine (le 19 novembre 2014).

Bonjour.

J'ai l'extinction du PC qui se fait immédiatement contre 1 ou 2 secondes avant. J'aimerais donc savoir si c'est normal ou s'il y a un problème. Comme je peux savoir si l'extinction s'est faite comme il faut ?

En regardant les logs avec l'outil journalctl -b

La commande journalctl -b 0 fournit tous les logs de l'utilisation actuelle de l'ordinateur (du dernier démarrage jusqu'à maintenant).
La commande journalctl -b -1 fournit tous les logs de l'avant-dernière utilisation de l'ordinateur (du démarrage jusqu'à l'arrêt).
La commande journalctl -b -2 fournit tous les logs de l'avant-avant-dernière utilisation de l'ordinateur (du démarrage jusqu'à l'arrêt)
La commande journalctl -b -3 fournit tous les logs de l'avant-avant-avant-dernière … Bref, je pense que tu as compris :o)

Jette également un coup d'œil sur la commande journalctl --list-boots

Plus d'infos sur ce lien (voir également la page de manuel).

au démarrage il me sort "start a job for /dev/… (25 s / 1 m 30s)" …
(et oui ça a bien duré 1 m 30 sec. Aucune explication de ce qu'est ce truc qui ressemble plus à un timer qu'à autre chose).

Effectivement, c'est un timer. Une unité ne démarre pas, et lorsque la durée TimeoutStartSec est écoulée, systemd considère cette unité comme défaillante (voir également DefaultTimeoutStartSec). Ces durées sont, par défaut, de 90 secondes, cela correspond à ton cas.

Pour diagnostiquer ce qui empêche ta machine de démarrer, tu peux utiliser journalctl avec les options suivantes :

• -p pour filtrer les logs selon leurs criticités,
• -b pour filtrer les logs par démarrage.

Une fois que tu as identifié l'unité défaillante, tu peux filtrer les logs pour n'avoir que ceux de cette unité, avec journalctl -u machin.unité

Ces différentes options de journalctl sont cumulables.

Salut.
Tu devrais pouvoir contrôler la rotation de tes ventilateurs avec les outils lm_sensors et fancontrol.

Ensuite, le fait aussi que personne ne s'intéresse à upstart […]

Sur la liste de discussions upstart-devel, il n'y a eu qu'un seul mail posté entre le 18 septembre 2014 et aujourd'hui (20 octobre 2014). Un seul mail en un mois …

Canonical a décidé de s'appuyer sur systemd pour les prochaines versions d'Ubuntu. Pendant combien de temps cette entreprise investira-t-elle des moyens dans le développement d'Upstart ?

J'ai buté sur le même problème : on peut démarrer un service avec un timer, mais peut-on arrêter un service avec un timer ? Il semblerait que non.

Je m'en suis sorti en créant un second timer, qui lançait un service incompatible avec le premier service.

---

Création d'un timer pour lancer le service steam-cmd.service :

$ cat /etc/systemd/system/steam-cmd.timer


[Unit]
Description=Timer pour lancer steam-cmd.service

[Timer]
OnCalendar=*-*-* 20:00:00
AccuracySec=1s

[Install]
WantedBy=multi-user.target

Ce timer lancera steam-cmd.service à 20h.

---

Création du service stop-steam-cmd.service, incompatible avec steam-cmd.service :

$ cat /etc/systemd/system/stop-steam-cmd.service


[Unit]
Conflicts=steam-cmd.service
Description=stop-steam-cmd.service est en conflit avec steam-cmd.service

[Service]
ExecStart=/usr/bin/echo "Activation de stop-steam-cmd.service"
Type=oneshot

Le lancement de stop-steam-cmd.service va arrêter (« Conflicts ») steam-cmd.service.

---

Création d'un timer pour lancer le service stop-steam-cmd.service :

$ cat /etc/systemd/system/stop-steam-cmd.timer


[Unit]
Description=Timer pour lancer le service stop-team-cmd.service

[Timer]
OnCalendar=*-*-* 02:00:00
AccuracySec=1s

[Install]
WantedBy=multi-user.target 

Ce timer lancera stop-steam-cmd.service à 2h.

---

On valide nos modifications :

$ systemctl daemon-reload

Il ne reste qu'à lancer nos deux timers :

$ systemctl start steam-cmd.timer stop-steam-cmd.timer

et à automatiser leur lancement au démarrage de l'ordinateur :

$ systemctl enable steam-cmd.timer stop-steam-cmd.timer


---

Ça fait beaucoup de choses pour automatiser le lancement et l'extinction d'un service :-) Pour cet exemple, cron est peut-être plus pertinent que les timers de systemd !

Tu peux même intégrer ces options directement dans ton service systemd : Nice et IOSchedulingClass.

Voici un exemple.

Si aucune disposition ne te convient, tu peux construire une disposition adaptée à tes besoins spécifiques. Comment ? En modifiant une disposition de clavier existante. Le programme adéquat s'appelle xmodmap.

Je pars d'une disposition bépo, et voici le fichier /home/toto/.xmodmap.conf qui contient mes modifications :

! Caractère # accessible directement avec AltGr+D :
keycode  31 = d D NoSymbol NoSymbol numbersign numbersign

! Smiley sous les touches C, T, S et N :
keycode 43 = c C NoSymbol NoSymbol copyright U0001F60D
keycode 44 = t T NoSymbol NoSymbol U0001F61E U0001F610
keycode 45 = s S NoSymbol NoSymbol U0001F60A U0001F604
keycode 47 = n N NoSymbol NoSymbol U2661 U2665

! Le séparateur décimal est la virgule (au lieu du point) :
keycode 91 = KP_Delete comma NoSymbol NoSymbol period U202F period

! Espace insécable avec Maj+Espace et AltGr+Maj+Espace :
keycode  65 = space U202F NoSymbol NoSymbol underscore U202F

Pour appliquer les modifications, on tape la commande xmodmap /home/toto/.xmodmap.conf
Plus d'infos sur xmodmap.

J'aurais tellement apprendre dans une dépêche sur wayland que :

Hum … « J'aurais tellement aimé apprendre » plutôt ?

Il y a bien ces schémas des targets qui pourront intéresser quelques lecteurs, mais qui ne répondent pas à ta demande.

Pourrais-tu développer? Je ne comprends pas ce que tu veux dire. Aurais-tu un exemple? Si j'ai compris, un répertoire possède une fonction logique unique avec systemd?

Pré-requis : les fichiers .service fournis par le gestionnaire de paquets sont dans le répertoire /lib/systemd/system/. Les personnalisations réalisées par l'administrateur sont dans le répertoire /etc/systemd/system/

Utiliser des répertoires pour ajouter des dépendances à un service.

Tu souhaites que machin.service dépende de truc.service (c'est-à-dire que le lancement de machin.service lance automatiquement truc.service). Pour se faire, tu as deux méthodes :

La première méthode est de recopier le fichier machin.service dans le répertoire /etc/systemd/system/

$ cp  -a  /lib/systemd/system/machin.service  /etc/systemd/system/

puis d'éditer la copie. Tu ajoutes une ligne « Wants » :

…
[Unit]
Wants=truc.service
…

Cette méthode présente malheureusement un inconvénient : si ton gestionnaire de paquets met à jour le fichier machin.service (dans /lib/systemd/system/), c'est toujours l'ancienne version du fichier (que tu as recopiée dans /etc/systemd/system/) que tu utiliseras.

Pour résoudre ce problème, on utilise une seconde méthode, basée sur les répertoires. On crée un répertoire /etc/systemd/system/machin.service.wants/, et on y met un lien symbolique truc.service qui pointe vers truc.service. Ça donne ceci :

$ ls -l /etc/systemd/system/machin.service.wants/
truc.service -> /lib/systemd/system/truc.service

De cette façon, le lancement de machin.service implique le lancement de truc.service.

---

Utiliser des répertoires pour ajouter des options à un service (sans écraser les options déjà présentes)

Tu souhaites ajouter 3 options au service bidule. Crée le répertoire /etc/systemd/system/bidule.service.d/. Dans ce répertoire, tu crées un fichier perso.conf qui contiendra les 3 options en question :

[Unit]
Description=Service bidule, avec mes personnalisations

[Service]
ExecStartPost=/usr/bin/beep -l100 -r2 
TTYVTDisallocate=no
TimeoutStopSec=30

Ces options se superposeront à celles contenues dans le fichier bidule.service (qui est dans le répertoire /lib/systemd/system/).

---

Pour conclure : remarquez qu'il est possible d'utiliser les fichiers de personnalisation pour créer des dépendances entre services. Pour le service zouzou.service, ça donnerait ceci :

$ cat /etc/systemd/system/zouzou.service.d/perso.conf

[Unit]
Wants=biscotte.service tartine.service
After=biscotte.service
Before=tartine.service

Dans ce cas, le lancement de zouzou.service implique le lancement de biscotte.service et tartine.service. De plus, zouzou.service est lancé après biscotte.service et avant tartine.service.

Systemd permet également de réutiliser les scripts SysVinit existants, voir ce tutoriel : Utiliser un script SysVinit avec systemd.

Si on doit déployer systemd, cela permet de parer au plus pressé : faire fonctionner le système. Plus tard, on peut prendre le temps de remplacer les scripts SysVinit par des fichiers .service qui utiliseront les nombreuses options que propose systemd (premier lien, second lien, troisième lien).