SystemD est un outil de gestion système utilisé pour rationaliser les tâches d'administration système et améliorer l'efficacité. Son principal avantage réside dans sa capacité à améliorer les performances et la réactivité du système, ainsi qu'à améliorer la sécurité en analysant automatiquement les vulnérabilités et en les corrigeant.
De plus, SystemD peut aider à organiser les ressources système plus efficacement, permettant aux programmes de s'exécuter plus rapidement et plus facilement. Dans l'ensemble, si vous recherchez un outil de gestion de système efficace qui vous aidera à tirer le meilleur parti de votre système, alors SystemD est la solution idéale. Dans cet article, vous apprendrez tout ce que vous devez savoir sur SystemD.
À quoi sert SystemD ?
SystemD est un outil de gestion de système qui peut être utilisé pour une variété de tâches, de la gestion des ressources et des processus système à l'optimisation des performances du système sur les systèmes Linux. Il est largement utilisé dans de nombreuses industries différentes, des soins de santé à la fabrication, en raison de ses capacités puissantes et de ses fonctionnalités avancées.
Que vous utilisiez de grands serveurs ou des postes de travail plus petits, SystemD offre une gamme d'avantages qui peuvent vous aider à améliorer l'efficacité et la productivité du système. Certaines des fonctionnalités clés incluent la hiérarchisation des processus, la journalisation des événements système et les contrôles d'allocation des ressources système. Donc, si votre organisation recherche un outil de gestion de système fiable qui peut aider à améliorer l'efficacité et les performances de tous les systèmes, alors SystemD vaut vraiment la peine d'être envisagé.
Pourquoi les gens n'aiment-ils pas SystemD ?
Alors que de nombreux utilisateurs trouvent que SystemD est un outil de gestion de système inestimable, certains ne l'aiment pas pour diverses raisons. Certains critiques affirment qu'il est trop complexe et difficile à utiliser, en particulier pour ceux qui ne sont pas familiers avec les tâches d'administration système. D'autres affirment que cela peut avoir un impact négatif sur les performances du système, entraînant des temps de démarrage plus lents et une utilisation accrue des ressources.
Malgré ces préoccupations, SystemD reste l'un des outils de gestion de système les plus largement utilisés sur le marché aujourd'hui et continuera probablement de l'être à l'avenir. Si vous recherchez un outil de gestion de système efficace qui peut aider à améliorer la productivité de tous les systèmes de votre organisation, alors SystemD vaut vraiment la peine d'être considéré.
Pourquoi SystemD est-il controversé ?
SystemD est un outil de gestion de système très controversé, en grande partie en raison du débat en cours sur son efficacité et sa convivialité. Certains utilisateurs affirment que cela peut avoir un impact négatif sur les performances du système, tandis que d'autres affirment qu'il offre un certain nombre d'avantages importants, tels qu'une sécurité améliorée du système et une allocation plus efficace des ressources système.
La complexité et la convivialité de SystemD suscitent également des inquiétudes, de nombreux utilisateurs citant sa courbe d'apprentissage abrupte et son interface déroutante comme principaux points de critique. Malgré ces préoccupations, SystemD reste l'un des outils de gestion de système les plus largement utilisés sur le marché aujourd'hui et devrait continuer à l'être à l'avenir. Si vous êtes à la recherche d'un outil de gestion de système puissant qui peut aider à améliorer les performances et l'efficacité du système sur tous les systèmes, alors SystemD peut être la solution idéale pour vous.
Qu'est-ce que SystemD contre init ?
SystemD et init sont des outils de gestion de système qui sont souvent comparés en raison de leurs fonctions similaires et de leurs caractéristiques qui se chevauchent. Bien que les deux outils de gestion système puissent être utilisés pour diverses tâches d'administration système, telles que la hiérarchisation des processus, la journalisation des événements système et les contrôles d'allocation des ressources système, il existe certaines différences essentielles entre eux.
Alors que init se concentre sur les processus de démarrage et d'arrêt du système, par exemple, SystemD offre une gamme plus large de fonctionnalités de gestion du système. De plus, de nombreux utilisateurs trouvent que SystemD est plus convivial et intuitif qu'init, ce qui en fait un choix populaire parmi les administrateurs système et les professionnels de l'informatique. Dans l'ensemble, si vous recherchez une solution de gestion de système efficace qui peut aider à améliorer les performances et l'efficacité du système sur tous les systèmes, alors SystemD peut être le choix idéal pour vous.
Dois-je utiliser Grub ou SystemD ?
Il n'y a pas de réponse définitive à cette question, car Grub et SystemD ont leurs propres avantages et inconvénients. D'une part, Grub est un outil de gestion de système léger qui offre des fonctions simples et rationalisées pour le démarrage et l'arrêt du système.
D'autre part, SystemD offre une gamme plus large de capacités et de fonctionnalités de gestion de système, ce qui en fait un outil de gestion de système plus puissant et polyvalent. En fin de compte, que vous choisissiez d'utiliser Grub ou SystemD dépendra de vos besoins et préférences spécifiques en tant qu'administrateur système ou professionnel de l'informatique. Cependant, si vous recherchez une solution de gestion de système efficace qui peut aider à améliorer les performances et l'efficacité du système sur tous les systèmes, alors SystemD est probablement le meilleur choix.
Comment utiliser SystemD
Ensuite, nous couvrirons quelques façons d'utiliser SystemD sur les systèmes Linux. Ce ne sont là que quelques exemples que vous pouvez essayer vous-même. Il faut un certain temps pour s'habituer à la syntaxe, mais une fois que vous l'avez maîtrisée, SystemD devient un outil puissant.
SystemD - Init
Il s'agit du premier processus démarré par le noyau et obtient le process id 1 . Il gère le processus de démarrage des tâches telles que la création de sockets, la configuration du matériel, le montage de disques, etc.
SystemD fonctionne avec des unités de différents types. A côté du service lui-même, il existe aussi :
- minuterie
- monter
- réseau
- prises
- partitions
- appareils
De plus, vous pouvez gérer d'autres processus avec SystemD :
- démarrer
- arrêter
- redémarrer
- tuer
Fichiers d'unité
Il existe différents chemins pour les fichiers d'unité existants :
| Chemin | Infos |
|---|---|
| /usr/lib/systemd/system | fichiers SystemD prédéfinis (ne pas modifier) |
| /etc/systemd/system | Emplacement des fichiers d'unité personnalisés |
| /run/systemd/system | Pour les fichiers pertinents pour l'exécution |
Informations importantes sur les chemins : SystemD préférera toujours /etc/ à /usr/lib/ . C'est pourquoi nous y plaçons des fichiers d'unité personnalisés.
Vous pouvez visiter le fichier unité d'un service spécifique en visitant le chemin ou avec la commande :
systemctl cat <service>
Code language: Bash (bash)Par exemple, OpenVPN :
[email protected]:~$ systemctl cat openvpn
# /lib/systemd/system/openvpn.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)Comme nous pouvons le voir dans le fichier d'unité, définissez quel chemin est utilisé , le fichier PID , et plus d'options . Ce dont nous parlerons plus en détail ci-dessous. Nous pouvons afficher toutes les propriétés disponibles avec les options qui peuvent être définies dans le fichier unité du service en utilisant la commande :
systemctl show <service>
Code language: Bash (bash)Par exemple, ici encore, voici les premières lignes de la sortie d'OpenVPN :
[email protected]:~$ systemctl show openvpn
Type=oneshot
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=infinity
TimeoutStopUSec=1min 30s
TimeoutAbortUSec=1min 30s
TimeoutStartFailureMode=terminate
TimeoutStopFailureMode=terminate
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestamp=n/a
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=yes
GuessMainPID=yes
MainPID=0
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
ReloadResult=success
CleanResult=success
UID=[not set]
GID=[not set]
NRestarts=0
OOMPolicy=stop
ExecMainStartTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainStartTimestampMonotonic=9823235
ExecMainExitTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainExitTimestampMonotonic=9824084
ExecMainPID=1164
ExecMainCode=1
ExecMainStatus=0v
Code language: Bash (bash)Si nous voulons maintenant éditer le fichier unité du service, nous lançons la commande :
systemctl edit – full <service>
Code language: Bash (bash)
Lorsque nous exécutons la commande sans le full option, nous aurons un fichier vierge. Nous avons la possibilité de créer une copie du fichier source, que nous pouvons modifier.
Comme exemple d'option possible, imaginons que nous voulons qu'OpenVPN soit toujours en cours d'exécution. Même lorsque le processus est arrêté ou tué, nous voulons qu'il redémarre tout seul.
Nous ouvrons l'éditeur et ajoutons l'option spécifique :
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Restart=yes
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)Après cela, nous devons recharger le fichier de configuration :
systemctl reload <service>
Code language: Bash (bash)Et enfin, redémarrez le service :
systemctl restart <service>
Code language: Bash (bash)Avec cette commande, SystemD essaiera de recharger le service. Si cela ne fonctionne pas, il redémarrera le service :
systemctl reload-or-restart <service>
Code language: HTML, XML (xml)Dans les commandes ci-dessus, nous avons appris à contrôler manuellement les services. SystemD vous permet également d'activer ou de désactiver en permanence des services afin qu'ils démarrent automatiquement en cas de besoin ou qu'ils ne soient pas disponibles du tout. Le tableau suivant affiche les commandes disponibles :
| Commande | Fonction |
|---|---|
| activer | Active un service |
| désactiver | Désactive un service |
| is-enable | Vérifier si un service est activé |
| réactiver | désactive un service puis le réactive |
| masque | Si vous souhaitez désactiver complètement un service, masquez-le - Soyez prudent |
| démasquer | démasque un service |
Exemple d'utilisation :
systemctl enable <service>
Code language: Bash (bash)Cibles
Ce sont différents états dans lesquels le système peut démarrer.
SystemD ajoute un nouveau concept pour les niveaux d'exécution bien connus. Cependant, l'ancien principe est conservé. Seuls les niveaux d'exécution portent des noms au lieu de numéros :
| Cible | Effet |
|---|---|
| arrêter.cible | Arrêter le système |
| poweroff.target | Arrête physiquement le système (mise hors tension) |
| rescue.target | Mode mono-utilisateur |
| cible.multi-utilisateur | Mode multi-utilisateur |
| cible.graphique | Mode multi-utilisateur avec interface graphique |
| reboot.target | Redémarre le système |
Vous pouvez basculer vers une autre cible en utilisant la commande suivante :
systemctl isolate example.target
Code language: Bash (bash)Redémarrez le système :
systemctl reboot
Code language: Bash (bash)Met le système en veille profonde et interrompt tous les processus en cours :
systemctl hybrid-sleep
Code language: Bash (bash)Éteint le système avec un message diffusé à tous les utilisateurs connectés :
systemctl shutdown
Vous pouvez modifier cela en utilisant les paramètres :
systemctl shutdown -r now
Code language: Bash (bash)Cela redémarrerait le système (-r) et contournerait le message de diffusion, et redémarrerait directement. Il existe de nombreux paramètres différents pour utiliser cette commande. Vous pouvez les consulter sur la page de manuel.
Vous pouvez afficher la cible actuelle sur laquelle le système démarre avec la commande suivante :
systemctl get-default
Code language: Bash (bash)De plus, vous pouvez modifier la cible :
systemctl set-default example.target
Code language: Bash (bash)Les différents niveaux d'exécution peuvent également être consultés ici :
ls -la /usr/lib/systemd/system |grep runle*
Code language: Bash (bash)[email protected]:~$ ls -la /usr/lib/systemd/system |grep runle*
lrwxrwxrwx 1 root root 15 Apr 18 22:12 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel1.target -> rescue.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel1.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel2.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel2.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel3.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel3.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel4.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel4.target.wants
lrwxrwxrwx 1 root root 16 Apr 18 22:12 runlevel5.target -> graphical.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel5.target.wants
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel6.target -> reboot.target
-rw-r--r – 1 root root 803 Apr 18 22:12 systemd-update-utmp-runlevel.service
Code language: plaintext (plaintext)Groupes de contrôle
SystemD organise les tâches en groupes de contrôle. Ceci est utilisé pour le contrôle des ressources sous Linux, et cela permet aux ressources disponibles d'être limitées , priorisé , compté, et isolé .
Les commandes suivantes sont donc très utiles pour analyser et optimiser les performances du système :
systemd-analyze
Code language: Bash (bash)Cette commande peut être utilisée pour déterminer les performances de démarrage.
[email protected]:~$ systemd-analyze
Startup finished in 12.712s (firmware) + 328ms (loader) + 8.240s (kernel) + 6.634s (userspace) = 27.916s
graphical.target reached after 6.631s in userspace
Code language: plaintext (plaintext)Comme nous pouvons le voir, nous obtenons une ventilation des délais de démarrage de chaque tâche.
Avec la commande supplémentaire blame nous obtenons une liste très détaillée du temps nécessaire à chaque processus pour démarrer :
systemd-analyze blame
Sortie :
[email protected]:~$ systemd-analyze blame
5.573s NetworkManager-wait-online.service
3.244s plymouth-quit-wait.service
2.285s fwupd.service
467ms logrotate.service
392ms lm-sensors.service
385ms accounts-daemon.service
362ms snapd.service
290ms systemd-resolved.service
279ms networkd-dispatcher.service
247ms networking.service
213ms dev-nvme0n1p3.device
182ms apparmor.service
178ms ModemManager.service
174ms systemd-journal-flush.service
168ms udisks2.service
161ms NetworkManager.service
152ms com.system76.Scheduler.service
128ms apport.service
127ms e2scrub_reap.service
116ms rsyslog.service
115ms smartmontools.service
114ms wpa_supplicant.service
105ms [email protected]
100ms gpu-manager.service
....
Code language: plaintext (plaintext)Si nous voulons voir tous les groupes de contrôle, nous pouvons utiliser :
systemd-cgls
Code language: Bash (bash)ou
systemctl status
Code language: Bash (bash)Nous obtiendrons une sortie arborescente avec toutes les informations nécessaires :
[email protected]:~$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│ ├─[email protected]
│ │ ├─session.slice
│ │ │ ├─dbus-broker.service
│ │ │ │ ├─3119 /usr/bin/dbus-broker-launch – scope user
│ │ │ │ └─3120 dbus-broker – log 4 – controller 10 – machine-id 04d8535513777afc7bb291c362dd90a7 – max-bytes 100000000000000 – max-fds 25000000000000 – max-matches 50000000>
│ │ │ ├─xdg-document-portal.service
│ │ │ │ ├─3761 /usr/libexec/xdg-document-portal
│ │ │ │ └─3773 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal – /run/user/1000/doc
│ │ │ ├─xdg-desktop-portal.service
│ │ │ │ └─3753 /usr/libexec/xdg-desktop-portal
│ │ │ ├─pipewire-pulse.service
│ │ │ │ └─3112 /usr/bin/pipewire-pulse
│ │ │ ├─wireplumber.service
│ │ │ │ └─3111 /usr/bin/wireplumber
│ │ │ ├─plasma-xdg-desktop-portal-kde.service
│ │ │ │ └─3861 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
│ │ │ └─pipewire.service
│ │ │ └─3106 /usr/bin/pipewire
│ │ ├─background.slice
│ │ │ ├─plasma-kactivitymanagerd.service
│ │ │ │ └─3546 /usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd
│ │ │ ├─plasma-kscreen.service
│ │ │ │ └─3610 /usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher
│ │ │ ├─plasma-baloorunner.service
│ │ │ │ └─5633 /usr/lib/x86_64-linux-gnu/libexec/baloorunner
│ │ │ ├─plasma-kglobalaccel.service
│ │ │ │ └─3452 /usr/bin/kglobalaccel5
│ │ │ └─tracker-miner-fs-3.service
│ │ │ └─3148 /usr/libexec/tracker-miner-fs-3
│ │ ├─app.slice
│ │ │ ├─app-\\x2fusr\\x2fbin\\x2fkorgac-d27ecb9065d646918a10df1c4fa798fe.scope
│ │ │ │ └─3599 /usr/bin/korgac -session 10dfe2702d000165869202400000083140007_1663442587_18526
│ │ │ ├─gvfs-goa-volume-monitor.service
│ │ │ │ └─3171 /usr/libexec/gvfs-goa-volume-monitor
│ │ │ ├─app-dbus\\x2d:1.2\\x2dorg.gnome.OnlineAccounts.slice
│ │ │ │ └─dbus-:[email protected]
│ │ │ │ └─3174 /usr/libexec/goa-daemon
│ │ │ ├─xdg-permission-store.service
│ │ │ │ └─3765 /usr/libexec/xdg-permission-store
│ │ │ ├─com.system76.SystemUpdater.Local.service
Code language: plaintext (plaintext)
Avec le systemd-cgtop commande, nous obtenons une liste de tous les groupes de contrôle triés par l'utilisation actuelle des ressources :
systemd-cgtop
Code language: Bash (bash)Maintenant, pourquoi est-ce important pour nous ? Nous pouvons désormais analyser l'utilisation des ressources des processus individuels et, si nécessaire, ajuster la priorité du processus ou modifier la limite des ressources.
La page de manuel nous offre de nombreuses possibilités pour gérer cela :
man systemd.resource-control
Code language: Bash (bash)Par exemple - si nous voulons définir la limite de mémoire d'un service spécifique, nous pouvons utiliser :
systemctl set property example.service MemoryLimit=1G
Code language: Bash (bash)Journalisation - JournalD
JournalD enregistre tous les événements dans la RAM du système. Cela sera effacé avec un redémarrage du système.
Vous pouvez utiliser JournalD avec la commande suivante :
journalctl
Code language: Bash (bash)Nous pouvons affiner davantage la sortie en ajoutant des filtres, par exemple, avec une heure spécifique :
journalctl – since yesterday
Code language: Bash (bash)Nous pouvons l'affiner encore plus en spécifiant une période de temps exacte de à :
journalctl – since "date" – until "date"
Code language: Bash (bash)Une autre façon de filtrer consiste à suivre des services spécifiques :
journalctl -u example
Code language: Bash (bash)Nous pouvons également suivre un service spécifique et filtrer uniquement celui-ci :
journalctl -fu example
Code language: Bash (bash)Nous pourrions également filtrer uniquement les événements du noyau :
journalctl -k
Code language: Bash (bash)Résumé
SystemD est un solide successeur du démon d'initialisation System V classique et fournit à l'administrateur de nombreuses informations et outils utiles qui accélèrent le travail et le flux de travail quotidiens. Si vous souhaitez en savoir plus sur d'autres sujets Linux approfondis, assurez-vous de visiter le blog de Max Wilke.
- SystemD est un outil de gestion système qui peut être utilisé pour des tâches telles que la gestion des ressources système et processus , optimisation des performances du système , et amélioration de la sécurité .
- SystemD offre un certain nombre d'avantages qui peuvent aider les entreprises à améliorer leur efficacité et leur productivité , y compris la priorisation des processus , journalisation des événements système , et contrôles d'allocation des ressources .
- Bien que SystemD soit largement utilisé par de nombreuses industries différentes en raison de ses puissantes fonctionnalités, certains utilisateurs ne l'aiment pas car il est complexe ou difficile à utiliser . De plus, certains critiques affirment que cela peut avoir un impact négatif sur les performances du système .
- Malgré ces préoccupations, SystemD reste l'un des outils de gestion de systèmes les plus populaires sur le marché aujourd'hui.