Version du 24 novembre 2021 à 10:41

Liens, références

En vrac

Une longue série sur Systemd que je n'ai pas encore lue

Un article sur le durcissement de services

https://ruderich.org/simon/notes/systemd-service-hardening

Structure générale de Systemd, présentation

Systemd est un ensemble de logiciels de base, alternative à SysVInit, le plus important étant notamment l'init (soit de tout premier process lancé par l'OS) : en effet, il fournit une gestion de services qui tourne sur le PID numéro 1 et qui lance tous les autres.

<source> ➜ ~ sudo pstree [sudo] password for justine: systemd─┬─ModemManager───2*[{ModemManager}]

       ├─NetworkManager─┬─dhclient
       │                └─2*[{NetworkManager}]
       ├─2*[VBoxClient───VBoxClient───2*[{VBoxClient}]]
       ├─VBoxClient───VBoxClient───3*[{VBoxClient}]
       ├─VBoxClient───VBoxDRMClient

[...] </source>

Son but est de parralléliser de façon aggressive pour une meilleure gestion des ressources. Il:

utilise des sockets ainsi que le système de messages D-BUS pour lancer ses services;
permet également de gérer ses services à la demande
surveille les processus utilisant des cgroups
maintient les montages et automontages
Supporte les init scripts au format SysV et LSB afin de remplacer SysV Init

Habituellement surtout connu pour la gestion des services, il contient également des utilitaires:

Un daemon gérant les logs (le journal)
Des utilitaires permettant de contrôler des configurations de base comme le hostname, la date, les locales,
De quoi pour voir la liste des utilisateurs connectés
De quoi voir la liste des conteneurs qui tournent
...les comptes système
les "runtime directories" et "runtime settings"
Un daemon pour le réseau
Un daemon pour NTP
Un daemon pour le log forwarding
Un daemon pour la résolution de nom...

Bref, plein de trucs. Voici une liste non exhaustive de ses composants :

Systemd-boot : Gestionnaire UEFI de boot similaire à Grub
systemd-firstboot : système de configuration avant le premier boot
systemd-homed : système de comptes utilisateurs humains portables
systemd-logind : gestion de sessions
systemd-networkd : gestion de configuration réseau
systemd-nspawn : conteneur de namespace léger (un "chroot on steroids" d'après le arch wiki)
systemd-resolved : résolveur dns
systemd-sysusers : Création d'utilisateurs / de groupes systèmes et ajout d'utilisateurs à des groupes lors de l'installation de paquets
systemd-timesyncd : synchronisation NTP
Journal : Centralisation des logs
Timers : Gestion de timers, alternative à cron
systemd.mount : composant chargé du montage des fs
systemd-sysvcompat : fournit la compatibilité avec les configurations type SysV
systemd-tmpfiles : Gestion des fichiers / dossiers temporaires

...et il y'en a sûrement d'autres.

Résumé des commandes

https://www.linuxtrainingacademy.com/systemd-cheat-sheet/

Informations

systemctl list-dependencies : Show a unit’s dependencies
systemctl list-sockets : List sockets and what activates
systemctl list-jobs : View active systemd jobs
systemctl list-unit-files : See unit files and their states
systemctl list-units : Show if units are loaded/active
systemctl get – default : List default target (like run level)

Editer les services ou les timers

systemctl edit [--full] service/timer : permet de réécrire la définition d'un service ou d'un timer. Avec l'option --full, prend le fichier qui serait dans /lib/systemd/system/, en fait une copie dans /etc/systemd/system/ et l'ouvre avec un éditeur de texte afin de le réécrire complètement. Sans cette option, on va simplement modifier/ajouter certaines options du service en créant un dossier /etc/systemd/system/<unit-name>.<unit-type>.d/. Exemple d'utilisation : Unattended-upgrades (section "modification des heures de lancement")

Travailler sur les services

systemctl stop service : Stop a running service
systemctl start service : Start a service
systemctl restart service : Restart a running service
systemctl reload service : Reload all config files in service
systemctl status service : See if service is running/enabled
systemctl enable service : Enable a service to start on boot
systemctl disable service : Disable service–won’t start at boot
systemctl show service : Show properties of a service (or other unit)
systemctl -H host status network : Run any systemctl command remotely

Travailler sur le système

systemctl reboot : Reboot the system (reboot.target)
systemctl poweroff : Power off the system (poweroff.target)
systemctl emergency : Put in emergency mode (emergency.target)
systemctl default : Back to default target (multi-user.target
systemctl suspend : Mettre en veille
systemctl hibernate : Mode hibernation

Travailler avec les logs

journalctl : Show all collected log messages
journalctl -u network.service : See network service messages
journalctl -f : Follow messages as they appear
journalctl -k : Show only kernel messages

Travailler avec les targets

systemctl isolate multi-user.target : Passer sur la target multi-user
systemctl set-default -f multi-user.target : Changer la target par défaut
systemctl list-unit-files | grep target : Voir les targets configurées sur le système
systemctl show -p Wants -p Requires <target> : Voir les unités regroupées dans une target

Équivalence Sysvinit vers Systemd

Sysvinit: service SERVICE_NAME start
Systemd: systemctl start SERVICE_NAME (Example: systemctl start cron.service)
Notes: Used to start a service (not reboot persistent)

Sysvinit: service SERVICE_NAME stop
Systemd: systemctl stop SERVICE_NAME
Notes: Used to stop a service (not reboot persistent)

Sysvinit: service SERVICE_NAME restart
Systemd: systemctl restart SERVICE_NAME
Notes: Used to stop and then start a service

Sysvinit: service SERVICE_NAME reload
Systemd: systemctl reload SERVICE_NAME
Notes: When supported, reloads the config file without interrupting pending operations.

Sysvinit: service SERVICE_NAME condrestart
Systemd: systemctl condrestart SERVICE_NAME
Notes: Restarts if the service is already running.

Sysvinit: service SERVICE_NAME status
Systemd: systemctl status SERVICE_NAME
Notes: Tells whether a service is currently running.

Sysvinit: chkconfig SERVICE_NAME on
Systemd: systemctl enable SERVICE_NAME
Notes: Turn the service on, for start at next boot, or other trigger.

Sysvinit: chkconfig SERVICE_NAME off
Systemd: systemctl disable SERVICE_NAME
Notes: Turn the service off for the next reboot, or any other trigger.

Sysvinit: chkconfig SERVICE_NAME
Systemd: systemctl is-enabled SERVICE_NAME
Notes: Used to check whether a service is configured to start or not in the current environment.

Sysvinit: chkconfig –list
Systemd: systemctl list-unit-files –type=service (or) ls /etc/systemd/system/*.wants/
Notes: Print a table of services that lists which runlevels each is configured on or off

Sysvinit: chkconfig –list | grep 5:on
Systemd: systemctl list-dependencies graphical.target
Notes: Print a table of services that will be started when booting into graphical mode

Sysvinit: chkconfig SERVICE_NAME –list
Systemd: ls /etc/systemd/system/*.wants/SERVICE_NAME.service
Notes: Used to list what levels this service is configured on or off

Sysvinit: chkconfig SERVICE_NAME –add
Systemd: systemctl daemon-reload
Notes: Used when you create a new service file or modify any configuration

Runlevels to Targets Cheat Sheet
Sysvinit: 0
Systemd: runlevel0.target, poweroff.target
Notes: Halt the system.

Sysvinit: 1, s, single
Systemd: runlevel1.target, rescue.target
Notes: Single user mode.

Sysvinit: 2, 4
Systemd: runlevel2.target, runlevel4.target, multi-user.target
Notes: User-defined/Site-specific runlevels. By default, identical to 3.

Sysvinit: 3
Systemd: runlevel3.target, multi-user.target
Notes: Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.

Sysvinit: 5
Systemd: runlevel5.target, graphical.target
Notes: Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.

Sysvinit: 6
Systemd: runlevel6.target, reboot.target
Notes: Reboot

Sysvinit: emergency
Systemd: emergency.target
Notes: Emergency shell

Changing runlevels:
Sysvinit: telinit 3
Systemd: systemctl isolate multi-user.target (OR systemctl isolate runlevel3.target OR telinit 3)
Notes: Change to multi-user run level.

Sysvinit: sed s/^id:.*:initdefault:/id:3:initdefault:/
Systemd: ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
Notes: Set to use multi-user runlevel on next reboot.

Création d'un service avec systemd

https://doc.ubuntu-fr.org/creer_un_service_avec_systemd

Comme Upstart, systemd utilise des fichiers de configuration correspondant aux différents services à manipuler. Il n'est (en général) plus nécessaire de créer des fichiers bash pour gérer le service, systemd s'occupe de tout (lancement, arrêt, redémarrage, status, gestion des logs, etc) Ces fichiers de configuration se trouvent dans /etc/systemd/system/ et permettent d'indiquer les conditions d'activation ou désactivation d'un service, leur propriétaire, etc.

Une fois le fichier créé:

<source lang="bash"> systemctl enable <nom du service>.service systemctl start <nom du service>.service systemctl status <nom du service>.service </source>

Types de services

Service simple : Lance un processus principal. Si le processus a besoin de canaux de communication comme des sockets, ils doivent être prêts avant l'activation du processus. Ainsi, systemd peut traiter les autres unités sans se préoccuper de la fin du lancement d'une unité de type "simple".
Service "forking" : C'est lorsqu'un processus père lance un processus fils. Le père s'arrête quand le fils est en place avec tous ses canaux de communication en place. Le processus fils continue à fonctionner en tant que le processus principal du service. systemd poursuit le traitement des autres unités une fois que le processus père se termine. Ce type de service correspond aux services UNIX traditionnels.
Oneshot : Similaire à un service simple, mais systemd attend que le processus se termine avant de continuer ses traitements. En gros, lorsque le service est lancé avec systemctl start foo, le script exécute toute sa commande et attends qu'elle retourne avant de rendre la main.

Ce type de service est typiquement utilisé comme équivalent aux commandes lancées au démarrage via les scripts d'init system V. Cela permet à systemd de remplacer ce mécanisme. De ce fait, avec systemd des nouveaux services apparaissent, alors qu'ils auraient été simplement des scripts d'init avec SysVinit.

dbus : Un service de type dbus est similaire à un service de type simple. Cependant, le processus du service doit obtenir un nom via D-Bus. systemd pourra alors traiter les autres unités.
notify : Un service de type notify est similaire à un service de type simple. Cependant, c'est le processus du service qui avertira systemd (via la fonction sd_notfy(3)) qu'il peut traiter les autres unités.

Dbus : Logiciel de communication inter-processus développé par RHEL.

Exemples de fichiers

OneShot

Exemple d'Iptables

<source lang="bash"> [Service] Type=oneshot

Signifie que quand la commande start est terminée, le processus est toujours considéré comme lancé.
Utile pour les oneshot qui lancent une commande mais n'ont pas de processus derrière.

RemainAfterExit=yes

Commande à exécuter au lancement du processus. Obligatoire.

ExecStart=/usr/libexec/iptables.init start

Commande a exécuter pour arrêter le service. Facultatif.

ExecStop=/usr/libexec/iptables.init stop </source>

Service Simple

Exemple de deluged (un client bittorent)

<source lang="bash"> [Unit]

Donne une description du service (affichée pour le status)

Description=Deluge Bittorrent Client Daemon

Indique un pré-requis au lancement du service (ici, être relié au réseau). Le service ne sera pas stoppé si on perd le réseau;
Pour cela, il faut utilise une balise Requires=

After=network-online.target

[Service] Type=simple

Propriétaire du processus

User=deluge Group=deluge UMask=007

ExecStart=/usr/bin/deluged -d

Relancer le service si il crashe

Restart=on-failure

Configures the time to wait before service is stopped forcefully.

TimeoutStopSec=300

[Install]

Dans quel target doit être actif le service (cf la section sur les targets)

WantedBy=multi-user.target </source>

Modèle de service

Il est possible d'avoir des templates de services qui lanceront des copies : par exemple : getty@.service donnera getty@tty1.service, getty@tty2.service... etc. On peut aussi avoir une instance par utilisateur, par exemple.

<source lang="bash"> [Unit] Description=Syncthing - Open Source Continuous File Synchronization for %I Documentation=man:syncthing(1) After=network.target

Spécifier les dépendances d'un service.

Wants=syncthing-inotify@.service

[Service]

%i correspond à l'argument passé au lancement du service.

User=%i ExecStart=/usr/bin/syncthing -no-browser -no-restart -logflags=0 Restart=on-failure SuccessExitStatus=3 4 RestartForceExitStatus=3 4 UMask=0002

[Install] WantedBy=multi-user.target </source>

Concernant user=%i, pour lancer les différentes instances avec les users différents:

systemctl enable syncthing@Connor.service
systemctl enable syncthing@Ripley.service
systemctl enable syncthing@Croft.service

Targets

Systemd introduit la notion de target au sein de ses unités. Une target permet de regrouper dans un seul paquet plusieurs autres unités et de retrouver la notion de runlevel de SystemV.

Runlevels

https://fr.wikipedia.org/wiki/Run_level Pour expliquer simplement la notion de runlevels, il s'agit d'un chiffre de 0 à 6 (et parfois "s") donné par sysvinit pour déterminer les fonctions activées : en gros, le niveau 6 est donné au démarrage, le niveau 0 à l'arrêt. On peut passer d'un niveau à l'autre de façon successive. L'idée est de dire que le système passe d'un état à l'autre et qu'à chaque état peut être associé un ensemble de services et autres. Par exemple, les runlevels de sysvinit sont :

0 : Arrêt
1 : Mono-utilisateur ou maintenance
2 à 5 : Fonction de l'OS
6 : Reboot

Pour les 2 à 5, on peut avoir :

2 : Multi-user sans serveur applicatif
3 : Multi-users avec serveurs applicatifs
4 ou 5 pour lancer l'environnement graphique.

Tableau de correspondance target / runlevel

<source> Runlevel Systemd Target Notes 0 runlevel0.target, poweroff.target Arrête le système 1 runlevel1.target, rescue.target Mode single user 3 runlevel3.target, multi-user.target Mode multi-utilisateur, non graphique 2, 4 runlevel2.target, runlevel4.target, multi-user.target Mode défini par l'utilisateur, identique au 3 par défaut. 5 runlevel5.target, graphical.target Mode graphique multi-utilisateur 6 runlevel6.target, reboot.target Redémarre emergency emergency.target Shell d'urgence </source>

Voir les targets

<source> systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character.

graphical.target @1min 32.691s └─multi-user.target @1min 32.691s

 └─xinetd.service @1min 32.120s +570ms
   └─network-online.target @6.872s
     └─network.target @6.864s
       └─networking.service @6.706s +157ms
         └─network-pre.target @6.695s
           └─firewalld.service @4.043s +2.651s
             └─dbus.service @4.038s
               └─basic.target @4.033s
                 └─sockets.target @4.033s
                   └─dbus.socket @4.033s
                     └─sysinit.target @4.030s
                       └─apparmor.service @3.752s +276ms
                         └─local-fs.target @3.750s
                           └─opt.mount @3.730s +19ms
                             └─systemd-fsck@dev-mapper-vg_root\x2dlv_opt.service @3.558s +169ms
                               └─local-fs-pre.target @3.556s
                                 └─multipathd.service @3.222s +333ms
                                   └─systemd-udev-settle.service @2.097s +1.124s
                                     └─systemd-udev-trigger.service @1.914s +182ms
                                       └─systemd-journald.socket @1.911s
                                         └─-.mount @1.902s
                                           └─systemd-journald.socket @1.911s
                                             └─...

</source>

Timers Systemd

https://wiki.archlinux.org/title/Systemd/Timers https://www.freedesktop.org/software/systemd/man/systemd.timer.html

Les timers sont des "unit files" (les unit files étant les fichiers décrivant par exemple les services, visibles avec la commande "systemctl list-unit-files"; je traduirais ici par "fichier unitaire" parce que je n'ai aucune foutue idée du nom en français) dont le nom se termine en .timer et qui contrôlent des fichiers .service ou des évènements. Ils peuvent être utilisés comme alternative à cron. Les timers supportent les évenènements liés au calendrier, les évènement monotones (pas compris), et peuvent être lancés de façon asynchrone.

Les fichiers unitaires pour les timers

Les timers sont définis dans des fichiers unitaires dont le nom comporte l'extension ".timer". Ils sont eux aussi des fichiers de configuration unitaires, et sont chargés au même endroit que les autres; cependant, ils contiennent une section [Timer] qui définit quand et comment ils s'activent. Les timers peuvent être de 2 types différents :

Realtime timers (ou wallclock timers) : Ils s'activent selon un calendar (un agenda, en somme), comme un cronjob : par exemple, tous les jours à midi, le 15e jour du mois à 22h, etc. Ils sont définis par l'option OnCalendar=
Monotonic timers : Ils s'activent après une durée relative à un point de départ : par exemple, 15 minutes après le boot. Ils s'arrêtent quand l'ordinateur est suspendu ou éteint. Ils sont définis par une mention "OntypeSec="; les plus courant sont OnBootSec= et OnUnitActiveSec=

La liste complète des options est dans le man de systemd.timer.

Pour chaque fichier .timer, un fichier .service correspondant existe : un foo.timer sera accompagné d'un foo.service. Le fichier .timer a pour rôle de contrôler l'activation du fichier .service (qui n'as d'ailleurs pas besoin d'une section [Install] tant que c'est le .timer qui est enabled. Le fichier .timer peut si besoin contrôler un fichier unitaire qui ne s'appelle pas comme lui en utilisant le paramètre Unit= dans la section [Timer].

Gestion des timers

Les timers peuvent être démarrés, arrêtés, activés / désactivés comme on le ferait pour un service, avec par exemple systemctl enable foo.timer.

Créer un timer

Exemple : je veux créer un timer foo.timer qui lance le service foo.service. Il est important qu'ils aient le même nom; autrement, je devrais dans mon timer utiliser l'option Unit= (voir juste au-dessus).

Créer le service /etc/systemd/system/foo.service (par exemple). Je n'ai pas fait beaucoup d'essais, mais le type OneShot semble le plus adapté, puisqu'il exécute sa commande et s'arrête : cela semble le plus utile dans l'optique de remplacer une crontab. Il existe sûrement d'autres possibilités.
Créer le timer /etc/systemd/system/foo.timer (par exemple). Voir les exemples en dessous.
Activer le timer : systemctl enable foo.timer. Sinon, il ne sera pas là au reboot !
Lancer le timer : systemctl start foo.timer. Hé oui, un timer est lancé en permanence : en fait, on peut le voir comme un daemon dont la seule utilité est de regarder l'horloge et de lancer le service quand le moment est venu.
Vérifier : systemctl list-timers. Notre timer doit s'y trouver.

Afficher les timers

On peut voir les timers qui tournent ou ceux qui sont arrêtés : <source> systemctl list-timers

Donne par exemple

NEXT LEFT LAST PASSED UNIT ACTIVATES Wed 2021-11-10 15:31:45 CET 51min left Wed 2021-11-10 14:34:04 CET 6min ago anacron.timer anacron.service Thu 2021-11-11 00:00:00 CET 9h left Wed 2021-11-10 10:30:04 CET 4h 10min ago logrotate.timer logrotate.service Thu 2021-11-11 00:00:00 CET 9h left Wed 2021-11-10 10:30:04 CET 4h 10min ago man-db.timer man-db.service Thu 2021-11-11 02:09:06 CET 11h left Wed 2021-11-10 10:30:04 CET 4h 10min ago apt-daily.timer apt-daily.service Thu 2021-11-11 06:32:59 CET 15h left Wed 2021-11-10 10:30:04 CET 4h 10min ago apt-daily-upgrade.timer apt-daily-upgrade.service Thu 2021-11-11 10:44:49 CET 20h left Wed 2021-11-10 10:44:49 CET 3h 55min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.ser

6 timers listed. Pass --all to see loaded but inactive timers, too. </source>

Exemples (tirés du wiki arch)

Monotonic

Un timer qui lancer le service foo.conf 15 mn après le boot, puis une fois par semaine tant que le système tourne

/etc/systemd/system/foo.timer <source> [Unit] Description=Run foo weekly and on boot

[Timer] OnBootSec=15min OnUnitActiveSec=1w

[Install] WantedBy=timers.target </source>

Temps réel

Un timer qui tourne tous les lundis à midi. Si je l'active et qu'il voit qu'il n'as pas pu faire son truc le lundi midi précédent parce que le système était eteint par exemple, il le fait immédiatement (option Persistent=True). <source> [Unit] Description=Run foo weekly

[Timer] OnCalendar=weekly Persistent=true

[Install] WantedBy=timers.target </source>

Format des dates pour le temps réel

OnCalendar peut utiliser des valeurs assez généralistes appellées special expressions (hourly, daily, etc...). En voici la liste et leur équivalent au format timestamp : <source>

   minutely → *-*-* *:*:00
     hourly → *-*-* *:00:00
      daily → *-*-* 00:00:00
    monthly → *-*-01 00:00:00
     weekly → Mon *-*-* 00:00:00
     yearly → *-01-01 00:00:00
  quarterly → *-01,04,07,10-01 00:00:00

semiannually → *-01,07-01 00:00:00 </source>

Autrement, l'option OnCalendar utilise les timestamps :

JourDeLaSemaine Année-Mois-Jour Heure:Minute:Seconde

On peut utiliser un astérisque pour dire que l'on veut n'importe quelle valeur (comme pour cron); deux valeurs séparées par un double point ".." indique une plage de valeurs (par exemple 10..20 englobe toutes les valeurs de 10 à 20 inclus).

La partie DayOfWeek n'est pas obligatoire, voir le troisième exemple.

On peut aussi indiquer plusieurs fois OnCalendar afin de spécifier plusieurs dates auxquelles le service doit tourner.

Exemples :

Les 4 premiers jours du mois à midi, seulement le lundi et le jeudi :

OnCalendar=Mon,Tue *-*-01..04 12:00:00

Le premier samedi du mois :

OnCalendar=Sat *-*-1..7 18:00:00

Tous les jours à 4heures :

OnCalendar=*-*-* 4:00:00

À 22h30 la semaine et 20h00 le weekend:

OnCalendar=Mon..Fri 22:30
OnCalendar=Sat,Sun 20:00

On peut analyser notre spécification temporelle afin de s'assurer qu'elle est valide et calculer son prochain déclenchement avec l'option calendar de systemd-analyze. Par exemple : <source> ➜ ~ systemd-analyze calendar "Mon,Fri *-*-* 22:00:00" Normalized form: Mon,Fri *-*-* 22:00:00

   Next elapse: Fri 2021-11-12 22:00:00 CET
      (in UTC): Fri 2021-11-12 21:00:00 UTC
      From now: 2 days left

</source>

Utiliser systemd-run avec des timers à usage unique

On peut utiliser systemd-run pour lancer une commande / un service après une certaine durée. Par exemple, pour faire un touch sur un fichier après 30 secondes:

systemd-run --on-active=30 /bin/touch /tmp/foo

On peut spécifier un fichier unitaire à lancer après une certaine durée. Ici, je lance foo.service après 12h et 30m:

systemd-run --on-active="12h 30m" --unit foo.service

Plus d'infos dans le manuel de systemd-run.

@@ Ligne 6 : / Ligne 6 : @@
 * https://opensource.com/article/20/5/manage-startup-systemd
 * https://opensource.com/article/20/7/systemd-timers
 Une longue série sur Systemd que je n'ai pas encore lue
 * http://0pointer.de/blog/projects/systemd-for-admins-1.html
@@ Ligne 18 : / Ligne 19 : @@
 * http://0pointer.de/blog/projects/instances.html
 * http://0pointer.de/blog/projects/inetd.html
+Un article sur le durcissement de services
+* https://ruderich.org/simon/notes/systemd-service-hardening
 = Structure générale de Systemd, présentation =

« Systemd » : différence entre les versions

Version du 24 novembre 2021 à 10:41

Sommaire

Liens, références

Structure générale de Systemd, présentation

Résumé des commandes

Informations

Editer les services ou les timers

Travailler sur les services

Travailler sur le système

Travailler avec les logs

Travailler avec les targets

Équivalence Sysvinit vers Systemd

Création d'un service avec systemd

Types de services

Exemples de fichiers

OneShot

Service Simple

Modèle de service

Targets

Runlevels

Tableau de correspondance target / runlevel

Voir les targets

Timers Systemd

Les fichiers unitaires pour les timers

Gestion des timers

Créer un timer

Afficher les timers

Exemples (tirés du wiki arch)

Monotonic

Temps réel

Format des dates pour le temps réel

Utiliser systemd-run avec des timers à usage unique

Menu de navigation

« Systemd » : différence entre les versions

Version du 24 novembre 2021 à 10:41

Liens, références

Structure générale de Systemd, présentation

Résumé des commandes

Informations

Editer les services ou les timers

Travailler sur les services

Travailler sur le système

Travailler avec les logs

Travailler avec les targets

Équivalence Sysvinit vers Systemd

Création d'un service avec systemd

Types de services

Exemples de fichiers

OneShot

Service Simple

Modèle de service

Targets

Runlevels

Tableau de correspondance target / runlevel

Voir les targets

Timers Systemd

Les fichiers unitaires pour les timers

Gestion des timers

Créer un timer

Afficher les timers

Exemples (tirés du wiki arch)

Monotonic

Temps réel

Format des dates pour le temps réel

Utiliser systemd-run avec des timers à usage unique

Menu de navigation

« Systemd » : différence entre les versions