<Précédent | Table des matières | Suivant>
5.4. Services de gestion
Kali utilise systemd comme son système d'initialisation, qui est non seulement responsable de la séquence de démarrage, mais agit également en permanence en tant que gestionnaire de services complet, démarrant et surveillant les services.
systemd peut être interrogé et contrôlé avec systemctl. Sans aucun argument, il exécute le unités de liste systemctl commande, qui affiche une liste des unités. Si tu cours état systemctl, la sortie affiche une vue d'ensemble hiérarchique des services en cours d'exécution. En comparant les deux sorties, vous voyez immédiatement qu'il existe plusieurs types d'unités et que les services ne sont qu'un d'entre eux.
Chaque service est représenté par un unité de service, qui est décrit par un fichier de service généralement expédié dans
/lib/systemd/system/ (ou /run/systemd/system/, ou /etc/systemd/system/ ; ils sont listés par ordre croissant d'importance, et le dernier l'emporte). Chacun est éventuellement modifié par d'autres Nom du service.service.d/*.conf dans le même ensemble de répertoires. Ces fichiers unitaires sont des fichiers texte brut dont le format est inspiré des fichiers « *.ini » bien connus de Microsoft Windows, avec clé
= Plus-value paires regroupées entre [ ] en-têtes. Ici, nous voyons un exemple de fichier de service pour /lib/systemd/system/ssh.service:
[Unité]
Description=Serveur OpenBSD Secure Shell After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Un service]
EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=processus
Restart=en cas d'échec RestartPreventExitStatus=255 Type=notifier
[Installer]
WantedBy=multi-user.target Alias=sshd.service
[Unité]
Description=Serveur OpenBSD Secure Shell After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Un service]
EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=processus
Restart=en cas d'échec RestartPreventExitStatus=255 Type=notifier
[Installer]
WantedBy=multi-user.target Alias=sshd.service
Les unités cibles sont une autre partie de la conception de systemd. Ils représentent un état souhaité que vous souhaitez atteindre en termes d'unités activées (ce qui signifie un service en cours dans le cas d'unités de service). Ils existent principalement comme un moyen de regrouper les dépendances sur d'autres unités. Lorsque le système démarre, il permet aux unités nécessaires d'atteindre le cible par défaut. (qui est un lien symbolique vers cible.graphique, et qui dépend à son tour de multi-utilisateur.cible). Ainsi, toutes les dépendances de ces cibles sont activées lors du démarrage.
De telles dépendances sont exprimées avec le Veut directive sur l'unité cible. Mais vous n'avez pas besoin de modifier l'unité cible pour ajouter de nouvelles dépendances, vous pouvez également créer un lien symbolique pointant vers le
unité dépendante dans le / etc / systemd / system /nom-cible.cible.veut/ annuaire. Et c'est exactement ce que systemctl enable foo.service Est-ce que. Lorsque vous activez un service, vous dites à systemd d'ajouter une dépendance sur les cibles répertoriées dans le Recherché par entrée du [Installer] section du fichier de l'unité de service. Inversement, Désactivation systemctl foo.service supprime le même lien symbolique et donc la dépendance.
Le manuel de formation permettre et désactiver les commandes ne changent rien à l'état actuel des services. Ils n'influencent que ce qui se passera au prochain démarrage. Si vous souhaitez exécuter le service immédiatement, vous devez exécuter début de systemctl foo.service. Inversement, vous pouvez l'arrêter avec arrêt systemctl foo.service. Vous pouvez également inspecter l'état actuel d'un service avec état systemctl foo.service, qui inclut utilement les dernières lignes du journal associé. Après avoir modifié la configuration d'un service, vous pouvez souhaiter le recharger ou le redémarrer : ces opérations se font avec recharger systemctl foo.service et redémarrage systemctl foo. un service respectivement.
# Systemctl status postgresql
● postgresql.service - SGBDR PostgreSQL
Chargé : chargé (/lib/systemd/system/postgresql.service ; désactivé ; préréglage du fournisseur :
➥ désactivée)
Actif: inactif (mort)
# ls -al /etc/systemd/system/multi-user.target.wants/postgresql.service
ls : impossible d'accéder à '/etc/systemd/system/multi-user.target.wants/postgresql.service' : non
➥ tel fichier ou répertoire
# systemctl active postgresql
[...]
# ls -al /etc/systemd/system/multi-user.target.wants/postgresql.service
lrwxrwxrwx 1 root root 38 21 avril 16:21 /etc/systemd/system/multi-user.target.wants/
➥ postgresql.service -> /lib/systemd/system/postgresql.service
# Systemctl status postgresql
● postgresql.service - SGBDR PostgreSQL
Chargé : chargé (/lib/systemd/system/postgresql.service ; activé ; préréglage du fournisseur :
➥ désactivée)
Actif: inactif (mort)
# systemctl démarre postgresql
# Systemctl status postgresql
● postgresql.service - SGBDR PostgreSQL
Chargé : chargé (/lib/systemd/system/postgresql.service ; activé ; préréglage du fournisseur :
➥ désactivée)
Actif : actif (sorti) depuis le jeu. 2016-04-21 16:22:29 EDT ; Il y a 2s Processus : 6355 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
PID principal : 6355 (code=exit, status=0/SUCCESS)
21 avril 16:22:29 kali-rolling systemd[1]: Démarrage de PostgreSQL RDBMS... 21 avril 16:22:29 kali-rolling systemd[1]: Démarrage de PostgreSQL RDBMS.