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>https://wiki.archlinux.org/title/Systemd/Journal

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.

Journal

Systemd a son propre système de récupération des logs, appellé le *journal* (en français dans le texte). Il n'est donc pas nécessaire de faire tourner un daemon de syslog supplémentaire !

Sources

Emplacement des journaux

Le journal est stocké de façon persistante sous la forme de binaires dans le dossier /var/log/journal, qui fait partie du package systemd (quand il est configuré avec Storage=auto). Si il est effacé, systemd ne le refera pas - et les journaux ne seront plus persistants. Si le service systemd-journald est redémarré et que le journal est configuré avec Stprage=persistent, le dossier sera recréé.

Classification des entrées de journal

Le journal classifie les entrées selon deux tableaux, priority et facility (ce qui correspond à la RFC 5424).

Priority

Correspond au niveau d'alerte.

Value	Severity	Keyword	Description	Examples
0	Emergency	emerg	System is unusable	Severe Kernel BUG, systemd dumped core. This level should not be used by applications.
1	Alert	alert	Should be corrected immediately	kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc\|.
2	Critical	crit	Critical conditions	systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core Failure in the system primary application, like X11.
3	Error	err	Error conditions	kernel: usb 1-3: 3:1: cannot get freq at ep 0x84, Failed unmounting /var. \|libvirtd[1720]: internal error: Failed to initialize a valid firewall backend
4	Warning	warning	May indicate that an error will occur if action is not taken.	A non-root file system has only 1GB free. (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
5	Notice	notice	Events that are unusual, but not error conditions.	systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway, \|gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged
6	Informational	info	Normal operational messages that require no action.	lvm[585]: 7 logical volume(s) in volume group "archvg" now active
7	Debug	debug	Information useful to developers for debugging the application.	kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen"

Facility

Sert à indiquer le type de programme dont provient le message.

Facility code	Keyword	Description	Info
0	kern	Kernel messages
1	user	User-level messages
2	mail	Mail system	Archaic POSIX still supported and sometimes used (for more Modèle:Man)
3	daemon	System daemons	All daemons, including systemd and its subsystems
4	auth	Security/authorization messages	Also watch for different facility 10
5	syslog	Messages generated internally by syslogd	For syslogd implementations (not used by systemd, see facility 3)
6	lpr	Line printer subsystem (archaic subsystem)
7	news	Network news subsystem (archaic subsystem)
8	uucp	UUCP subsystem (archaic subsystem)
9		Clock daemon	systemd-timesyncd
10	authpriv	Security/authorization messages	Also watch for different facility 4
11	ftp	FTP daemon
12	-	NTP subsystem
13	-	Log audit
14	-	Log alert
15	cron	Scheduling daemon
16	local0	Local use 0 (local0)
17	local1	Local use 1 (local1)
18	local2	Local use 2 (local2)
19	local3	Local use 3 (local3)
20	local4	Local use 4 (local4)
21	local5	Local use 5 (local5)
22	local6	Local use 6 (local6)
23	local7	Local use 7 (local7)

Les plus utiles à surveiller sont : 0, 1, 3, 4, 9, 10, 15.

Afficher le journal et filtrer sa sortie

La commande de base de consultation du journal est:

journalctl

Suivre un service (une unit)

journalctl -u mon service

Suivre les message générés par un exécutable

journalctl /usr/lib/systemd/systemd

Suivre les mesage par PID

journalctl _PID=1

Affichage temps réel

journalctl -f

Filtrer depuis le boot actuel / précédent, voir la liste des boots

journalctl -b

Si je veux voir depuis le boot précédent:

journalctl -b -1

-2 m'emmènera au boot d'encore avant, etc.

Je peux voir la liste des boots enregistrés:

journalctl --list-boots

Afficher des explications du catalogue

Le journal inclue un système de catalogue (explications), qui permet d'améliorer la sortie du journal en ajoutant plus d'explications.

On peut voir les entrées de catalogue existant sur le système:

journalctl --list-catalog

Et voir notre journal avec les entrées expliquées quand c'est dispo

journactl -x

Gestion du temps

Depuis une date:

journalctl --since="2012-10-30 18:17:16"

Depuis un temps:

journalctl --since "20 min ago"

Voir le dmesg

journalctl -k

Filtrer par niveau d'alerte

On peut choisir une range de niveau d'alerte:

journalctl -p err..alert

On peut aussi utiliser des nombres:

journalctl -p 3..1

Avec un seul nombre, on choisit cette priorité et les priorités plus élevées. Par exemple:

journalctl -p 3

affichera les messages de niveau erreur ou plus élevé.

Filtrer par facility (filtrer par source)

Pour filtrer sur ma facility 10 (qui est l'équivalent d'un auth.log), par exemple:

journalctl SYSLOG_FACILITY=10

Formater la sortie

Par défaut, le journal utilise less comme pager (soit, comme gestionnaire d'affichage).

Ne pas couper les lignes / Afficher sur la sortie standard

Pour une longue ligne, le journal va la tronquer et il faudra se balader avec les flèches gauche / droite. Ce n'est pas génial; le plus simple pour s'en débarasser consiste à utiliser l'option --no-pager pour afficher sur la sortie standard.

journalctl --no-pager

Choisir un format de sortie

L'option -o permet de choisir un tas de formats d'affichage, dont la liste est disponible dans le man de journalctl:

short
is the default and generates an output that is mostly
identical to the formatting of classic syslog files,
showing one line per journal entry.

short-full
is very similar, but shows timestamps in the format the
--since= and --until= options accept. Unlike the
timestamp information shown in short output mode this
mode includes weekday, year and timezone information in
the output, and is locale-independent.

short-iso
is very similar, but shows ISO 8601 wallclock timestamps.

short-iso-precise
as for short-iso but includes full microsecond precision.

short-precise
is very similar, but shows classic syslog timestamps with
full microsecond precision.

short-monotonic
is very similar, but shows monotonic timestamps instead
of wallclock timestamps.

short-unix
is very similar, but shows seconds passed since January
1st 1970 UTC instead of wallclock timestamps ("UNIX
time"). The time is shown with microsecond accuracy.

verbose
shows the full-structured entry items with all fields.

export
serializes the journal into a binary (but mostly
text-based) stream suitable for backups and network
transfer (see Journal Export Format[1] for more
information). To import the binary stream back into
native journald format use systemd-journal-remote(8).

json
formats entries as JSON objects, separated by newline
characters (see Journal JSON Format[2] for more
information). Field values are generally encoded as JSON
strings, with three exceptions:

1. Fields larger than 4096 bytes are encoded as null
   values. (This may be turned off by passing --all, but
   be aware that this may allocate overly long JSON
   objects.)

2. Journal entries permit non-unique fields within the
   same log entry. JSON does not allow non-unique fields
   within objects. Due to this, if a non-unique field is
   encountered a JSON array is used as field value,
   listing all field values as elements.

3. Fields containing non-printable or non-UTF8 bytes are
   encoded as arrays containing the raw bytes
   individually formatted as unsigned numbers.

Note that this encoding is reversible (with the exception
of the size limit).

json-pretty
formats entries as JSON data structures, but formats them
in multiple lines in order to make them more readable by
humans.

json-sse
formats entries as JSON data structures, but wraps them
in a format suitable for Server-Sent Events[3].

json-seq
formats entries as JSON data structures, but prefixes
them with an ASCII Record Separator character (0x1E) and
suffixes them with an ASCII Line Feed character (0x0A),
in accordance with JavaScript Object Notation (JSON) Text
Sequences[4] ("application/json-seq").

cat
generates a very terse output, only showing the actual
message of each journal entry with no metadata, not even
a timestamp. If combined with the --output-fields= option
will output the listed fields for each log record,
instead of the message.

with-unit
similar to short-full, but prefixes the unit and user
unit names instead of the traditional syslog identifier.
Useful when using templated instances, as it will include
the arguments in the unit names.

Pour un affichage en json lisible par exemple:

journalctl -o json-pretty

Configuration du journal

Le fichier de configuration du journal se situe dans /etc/systemd/journal. Le service a redémarrer est systemd-journald.

Le manuel est détaillé :

man journald.conf

Gestion de la persistence

Le journal est nettoyé (en anglais "vacuumed", soit littéralement "passé l'aspirateur") régulièrement en fonction de la configuration. Les journaux nettoyés ne sont plus disponibles !

Option "Storage"

Dans le fichier de conf du journal, une option important est "Storage". Celle-ci détermine la persistence et peut prendre les valeurs:

volatile : gardé en mémoire seulement, dans /run/log/journal
persistent : gardé sur disque, dans /var/log/journal
auto : comme persistent, si /var/log/journal existe
none : on ne garde rien.

Taille maximum

Par défaut, le système ne conserve pas les journaux de façon illimitée : un journal non-volatile aura une taille limite à 10% de son filesystem, dans une limite de 4 Go. On peut confirmer ces valeurs avec:

journalctl -b -u systemd-journald

Cette valeur maximum peut être modifiée dans le fichier de conf:

SystemMaxUse=50M

...ou dans un snippet à part, par exemple dans

/etc/systemd/journald.conf.d/00-journal-size.conf

avec

[Journal]
SystemMaxUse=50M

On peut configurer la quantité d'espace qui doit rester dispo après rotation:

SystemKeepFree=

On peut configurer la taille maximum d'un fichier de journal avec

SystemMaxFileSize

Rotation des journaux

On peut faire tourner les journaux à la main, par exemple pour effacer tout ce qui a plus de 2 jours:

journalctl --vacuum-time=2d

Ou retenir les 500 derniers Mo de journal:

journalctl --vacuum-size=500M

On peut voir l'espace disque utilisé par le journal:

journalctl --disk-usage

Namespace

On peut aussi limiter la taille pour une unité, par exemple sshd, avec le système de namespaces. Il faut modifier le fichier d'unit et ajouter:

LogNamespace=ssh

dans la section [Service]. Ensuite, on créée /etc/systemd/journald@ssh.conf en copiant /etc/systemd/journald.conf; puis on l'édite et on lui donne un SystemMaxUse. Après ça, il suffit de redémarrer le service (sshd en l'occurence).

On peut voir le journal d'un namespace de la façon suivante:

journalctl --namespace ssh

Un exemple de configuration pour de la production

#/etc/systemd/journald.conf
[Journal]
Compress=yes 
ForwardToConsole=no 
ForwardToSyslog=no
MaxRetentionSec=1year 
RateLimitBurst=10000 
RateLimitIntervalSec=30s
Storage=persistent 
SyncIntervalSec=1s 
SystemMaxUse=8g 
SystemKeepFree=20% 
SystemMaxFileSize=10M

Compress : les logs sont compressés avant d'être stockés.
ForwardtoConsole, ForwardtoSyslog : ici, on ne forwarde pas les messages (ni à une console, ni à un syslog). On les garde !
MaxRetentionSec : Ici, on garde un an maximum de journaux. Le mot "Sec" est un peu malvenu, parce qu'on peut donner des valeurs en : "year", "month", "week", "day", "h", " m".
RateLimitBurst et IntervalSec (valeurs par défaut ici) : si le log reçoit plus de 10000 messages en 30 secondes, il les droppe.
Storage=Persistent : on garde les journaux sur le disque.
SyncIntervalSec: Le journal attend la durée donnée avant de synchroniser son journal sur disque pour les entrées de message dont le niveau d'alerte est de ERR ou moins. Les autre sont synchronisées immédiatement.
SystemMaxUse : À 8 Go, les journaux sont effacés.
SystemKeepFree : Si le FS a moins de 20% de libre, le journal fera de la place.
SystemMaxFileSize : taille maximum d'un journal individuel.

Forward vers un serveur syslog

Il est possible de forwarder le journal vers un daemon syslog. Il suffit de le configurer avec l'option:

ForwardToSyslog=yes

En configurant le syslog, il est alors possible de renvoyer les messages sur un serveur de syslog. Cela peut être intéressant de garder cette conf en conjonction avec Storage=none, par exemple, pour externaliser tous les logs.

Systemd