web-dev-qa-db-fra.com

Lorsque nous activons un service utilisant systemctl, à quel niveau d'exécution s'exécute ce service?

Autant que je sache au démarrage du système Linux, les services mentionnés dans les niveaux d'exécution (rcX.d) seraient lancés.

Si nous permettons à un service de démarrer au démarrage à l'aide de la commande systemctl, ce service sera-t-il ajouté au niveau d'exécution par défaut?

servicessystemd
3
Shrey Kanna

En fait non, ce n'est pas le cas mais vous pouvez exécuter:

systemctl show -p WantedBy service-name

pour trouver dans quelle cible il sera exécuté, par exemple:

systemctl show -p WantedBy tlp.service 
WantedBy=multi-user.target

ce qui indique que si j'active tlpname__, il sera lancé lorsque j'entrerai dans multi-user.target.

Il convient également de mentionner que les niveaux d’exécution sont obsolètes et que systemd utilise à la place la cible:

┌─────────┬───────────────────┐
│Runlevel │ Target            │
├─────────┼───────────────────┤
│0        │ poweroff.target   │
├─────────┼───────────────────┤
│1        │ rescue.target     │
├─────────┼───────────────────┤
│2, 3, 4  │ multi-user.target │
├─────────┼───────────────────┤
│5        │ graphical.target  │
├─────────┼───────────────────┤
│6        │ reboot.target     │
└─────────┴───────────────────┘
3
Ravexina

Autant que je sache au démarrage du système Linux, les services mentionnés dans les niveaux d'exécution (rcX.d) seraient démarrés.

Ce n'est plus vrai.

Le système systemd init n'utilise pas de manière native le concept de niveaux d'exécution. Au lieu de cela, il introduit un concept de "cibles" qui regroupe d’autres unités en utilisant le mécanisme des dépendances.

Ce qui était un "niveau d'exécution par défaut" devient l'unité default.target qui, lorsqu'elle est activée, peut "extraire" (activer) d'autres unités via des dépendances d'exigences.

(systemdne fournit une couche de compatibilité pour le concept d'exécution, en donnant à certaines cibles des alias avec des noms tels que runlevelX.target, qui sont ensuite utilisés par les outils tels que telinit, mais c'est à peu près cela. Dans Systemd , un service ou toute autre unité n'est pas tenu d'appartenir à l'un de ces pseudo-niveaux d'exécution.)

Activer un service (généralement), c'est créer une dépendance artificielle entre deux unités.

Ainsi, lorsque vous activez un service (ou une unité), systemd examine la section [Install] de cette unité et effectue les actions spécifiées dans celle-ci. Par exemple, examinons sshd.service sur ma machine:

# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH Daemon
Wants=sshdgenkeys.service
After=sshdgenkeys.service
After=network.target

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

# This service file runs an SSH daemon that forks for each incoming connection.
# If you prefer to spawn on-demand daemons, use sshd.socket and [email protected].

Lorsque vous écrivez systemctl enable sshd.service, systemd examine cette unité et ajoute une dépendance Wants= de multi-user.target à sshd.service conformément à la directive WantedBy=multi-user.target.

(Cette dépendance est physiquement stockée sous forme de lien symbolique de /etc/systemd/system/multi-user.target.wants à /usr/lib/systemd/system/sshd.service.)

Alors, quand vous démarrez ...

Lorsque vous démarrez, default.target est activé, ainsi que tout le reste, via les dépendances. C'est ce qu'on appelle "la transaction initiale", et c'est tout.

Votre default.target est probablement un alias de graphical.target (quel Wants=multi-user.target) ou de multi-user.target directement. Quoi qu'il en soit, multi-user.target est activé et extrait sshd.service via la dépendance mentionnée ci-dessus.

0
intelfx