systemd

Journaux liées à cette note :

Je dois utiliser journalctl -t en non pas jounalctl -u #aide-mémoire, #mémento, #mémo

Note de type #mémo sur l'utilisation de la commande journalctl.

En travaillant sur un playground d'étude de Podman Quadlets, j'ai affiché cette sortie journalctl :

$ journalctl
Dec 02 05:43:42 stephane-coreos systemd[1]: rpm-ostreed.service: Deactivated successfully.
Dec 02 05:43:42 stephane-coreos audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=rpm-ostreed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? ad>
Dec 02 05:43:50 stephane-coreos chronyd[914]: Selected source 172.234.184.36 (2.fedora.pool.ntp.org)
Dec 02 05:44:42 stephane-coreos kernel: evm: overlay not supported
Dec 02 05:44:42 stephane-coreos podman[1308]: 2025-12-02 05:44:42.996190724 +0000 UTC m=+0.092291988 container remove 5c6247f1c702c3c36f167fd1477b69e2de254df36f987d78d01084683213a09a (image=docker.io/library/post>
Dec 02 05:44:43 stephane-coreos podman[1308]: 2025-12-02 05:44:43.051005068 +0000 UTC m=+0.147106332 volume remove b83aa9fc3fccf2b416e8c9d96cd52892e473df586cae8d37f3c009cee96e1605
Dec 02 05:44:43 stephane-coreos podman[1308]: 2025-12-02 05:44:43.051364949 +0000 UTC m=+0.147466223 system refresh
Dec 02 05:44:43 stephane-coreos systemd[1163]: Created slice session.slice - User Core Session Slice.
Dec 02 05:44:43 stephane-coreos systemd[1163]: Starting dbus-broker.service - D-Bus User Message Bus...
Dec 02 05:44:43 stephane-coreos systemd[1163]: Started dbus-broker.service - D-Bus User Message Bus.
Dec 02 05:44:43 stephane-coreos dbus-broker-launch[1323]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored
Dec 02 05:44:43 stephane-coreos dbus-broker-launch[1323]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored
Dec 02 05:44:43 stephane-coreos dbus-broker-launch[1323]: Ready
Dec 02 05:44:43 stephane-coreos systemd[1163]: Created slice user.slice - Slice /user.
Dec 02 05:44:43 stephane-coreos systemd[1163]: Started podman-1308.scope.
Dec 02 05:44:43 stephane-coreos systemd[1163]: Started podman-pause-a99918d0.scope.
Dec 02 05:44:49 stephane-coreos irqbalance[920]: Cannot change IRQ 26 affinity: Permission denied
Dec 02 05:44:49 stephane-coreos irqbalance[920]: IRQ 26 affinity is now unmanaged

Pour filtrer uniquement les entrées podman, j'ai lancé :

$ journalctl -u podman
-- No entries --

Contrairement à ce que j'attendais, cette commande n'a retourné aucun résultat.

En creusant le sujet, j'ai découvert que la 3ᵉ colonne (qui contient podman) ne correspond pas au nom de la systemd Unit qui a créé le message log, mais au champ SYSLOG_IDENTIFIER. Voici la structure des champs dans le format par défaut (short) de journalctl :

Dec 02 05:44:43 stephane-coreos podman[1308]: message text
│              │                │       │      │
│              │                │       │      └─ MESSAGE
│              │                │       └─ _PID
│              │                └─ SYSLOG_IDENTIFIER
│              └─ _HOSTNAME
└─ __REALTIME_TIMESTAMP (formaté)

Pour filtrer sur le champ SYSLOG_IDENTIFIER, il faut utiliser l'option -t :

-t, --identifier=SYSLOG_IDENTIFIER¶

    Show messages for the specified syslog identifier SYSLOG_IDENTIFIER.

    This parameter can be specified multiple times.

    Added in version 217.paramètre

stephane@stephane-coreos:~$ journalctl -t podman
Dec 02 05:44:42 stephane-coreos podman[1308]: 2025-12-02 05:44:42.996190724 +0000 UTC m=+0.092291988 container remove 5c6247f1c702c3c36f167fd1477b69e2de254df36f987d78d01084683213a09a (image=docker.io/library/postgres:18.1, name=systemd-postgresql, PODMAN_SYSTEMD_UNIT=postgresql.service)
Dec 02 05:44:43 stephane-coreos podman[1308]: 2025-12-02 05:44:43.051005068 +0000 UTC m=+0.147106332 volume remove b83aa9fc3fccf2b416e8c9d96cd52892e473df586cae8d37f3c009cee96e1605
Dec 02 05:44:43 stephane-coreos podman[1308]: 2025-12-02 05:44:43.051364949 +0000 UTC m=+0.147466223 system refresh

Le nom -t de l'option vient de l'option --tag de logger :

$ logger --help

Usage:
 logger [options] [<message>]

Enter messages into the system log.

Options:
 ...
 -t, --tag <tag>          mark every line with this tag
 ...

Mon manque de maîtrise de journalctl illustre bien ce que j'évoquais dans 2025-07-04_1614.
J'utilise Linux depuis 1999, et l'arrivée de systemd a bouleversé pas mal de choses.
Cette transition a créé de la confusion chez moi, et je n'ai jamais vraiment pris le temps d'étudier sérieusement systemd.

Convergence vers Bootc #fedora, #linux, #distribution-linux, #gnome

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Support OCI de CoreOS (image pull & updates)".

Colin Walters, le principal développeur de libostree a initié le projet bootc en mars 2021. J'ai découvert le projet bootc en début d'année et lisant des articles liés à systemd.

La vision de bootc est assez simple : rendre la création d'images de système d'exploitation aussi simple que la création d'images de conteneurs d'applications tout en utilisant les mêmes outils. Pour avoir un peu de contexte historique, je conseille l'article lwn de juin 2024 : Making containers bootable for fun and profit

Les images bootc utilisent la même technologie de stockage que les images des container classique : OCI.

D'après ce que j'ai compris, ce type d'image bootc ne porte pas nom officiellle, elles sont nommés aussi bien "bootc image", que "bootable container image" ou "bootable OCI image".

En janvier 2025, Red Hat a transféré le projet bootc à la CNCF. Le but est de permettre à toutes les distributions de l'adopter comme standard, indépendamment de Red Hat.

Parmis les distributions qui ont adopté bootc, trois retiennent mon attention :

Au moment où j'écris ces lignes, je pense migrer d'ici quelques mois ma workstation vers une distribution Desktop bootc, probablement Bluefin, qui est déjà disponible, ou Fedora Silverblue, une fois que son support bootc sera finalisé.

J'aurai donc certainement l'occasion de tester en pratique comment créer des images bootc personnalisées.

Voici diverses ressources que j'ai trouvées concernant le support bootc pour Fedora Silverblue :

Je compte aussi tester bootc et tout particulièrement Bluefin dans le cadre de mon "Projet 26 - "Expérimentation de migration de deux utilisateurs grand public vers des laptops sous Fedora"".

CoreOS de 2013 à 2018 #CoreOS, #linux, #distribution-linux

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows".

Première version de CoreOS Container Linux en 2013

La première version de CoreOS Container Linux sortie en 2013 utilisé la méthode A/B (seamless) system updates inspirée de manière transparente à Chrome OS :

Upgrading CoreOS is a bit different than the usual distros. Our update system is based on ChromeOS. The big difference is that we have two root partitions; lets call them root A and root B. Initially your system is booted into the root A partition and CoreOS begins talking to the update service to find out about new updates. If there is an update available it is downloaded and installed to root B.

source

D'après ce repository coreos/coreos-overlay, CoreOS Container Linux était basé sur les packages de Gentoo.

Première version d'Ignition en 2016

En avril 2016, l'équipe CoreOS a publié la première version de ignition, outil toujours utilisé en 2025 par Fedora CoreOS.

Ignition is a utility created to manipulate disks during the initramfs. This includes partitioning disks, formatting partitions, writing files (regular files, systemd units, etc.), and configuring users. On first boot, Ignition reads its configuration from a source of truth (remote URL, network metadata service, hypervisor bridge, etc.) and applies the configuration.

source

ignition est un système qui ressemble à cloud-init, mais qui est exécuté seulement une seule fois, lors du premier boot et est lancé en tout premier, avant même systemd.

Depuis 2019, les fichiers json ignition ne sont plus édités manuellement grâce à l'outil butane qui convertit des fichiers YAML butane en fichiers json ignition.

Voici la documentation de butane qui vous permet de voir les actions que peut effectuer ignition : https://coreos.github.io/butane/specs/.

À la différence de cloud-init, ignition fonctionne à un niveau plus bas. La spec Butane Fedora CoreOS v1.6.0 permet par exemple de configurer les partitions, le Raid, LUKS encryption…

Voici dans mon playground un exemple de son utilisation : atomic-os-playground/create-coreos-custom-iso.sh.

Note suivante : "2014-2018 approche alternative avec Atomic Project".

J'ai découvert Podman Quadlets #podman, #docker, #linux, #admin-sys, #DevOps, #JaiDécouvert

Dans ce thread du Subreddit self hosted, #JaiDécouvert Podman Quadlets, une fonctionnalité de podman.

D'après ce que j'ai compris, Podman Quadlets est un système qui permet de lancer des containers podman via systemd de manière déclarative. Techniquement, Podman Quadlets transforme des fichiers .container en fichier unit files systemd classique.

Exemple d'un fichier .container :

# ~/.config/containers/systemd/nginx.container
[Unit]
Description=Nginx web server
After=network-online.target

[Container]
Image=docker.io/library/nginx:latest
PublishPort=8080:80
Volume=/srv/www:/usr/share/nginx/html:ro,Z

[Service]
Restart=always

[Install]
WantedBy=default.target

Et pour ensuite lancer ce container :

$ systemctl --user daemon-reload
$ systemctl --user start nginx
$ systemctl --user enable nginx

J'ai aussi découvert le projet podlet, (https://github.com/containers/podlet) qui permet de générer des fichiers Podman Quadlets à partir de fichiers docker compose.

J'apprécie que podman incarne la philosophie Unix en s'intégrant nativement aux composants Linux comme systemd, plutôt que de réinventer la roue comme Docker.

bridge-utils est déprécié, je dois remplacer "brctl" par "ip link" #linux, #kernel, #network, #JaiDécouvert

En étudiant IPv6 et Linux bridge, j'ai découvert que le projet bridge-utils est déprécié. À la place, il faut utiliser iproute2.

Ce qui signifie que je ne dois plus utiliser la commande brctl, chose que j'ignorais jusqu'à ce matin.

iproute2 remplace aussi le projet net-tools. Par exemple, les commandes suivantes sont aussi dépréciées :

  • ifconfig remplacé par ip addr et ip link
  • route remplacé par ip route
  • arp remplacé par ip neigh
  • brctl remplacé par ip link
  • iptunnel remplacé par ip tunnel
  • nameif remplacé par ip link set name
  • ipmaddr remplacé par ip maddr

Au-delà des aspects techniques — iproute2 utilise Netlink plutôt que ioctl — l'expérience utilisateur me semble plus cohérente.
J'ai une préférence pour une commande unique ip accompagnée de sous-commandes plutôt que pour un ensemble de commandes disparates.
Cette logique de sous-commandes s'inscrit dans une tendance générale de l'écosystème Linux, et je pense que c'est une bonne direction.
Je pense notamment à systemctl, timedatectl, hostnamectl, localectl, loginctl, apt, etc.

Quand j'ai débuté sous Linux en 1999, j'ai été habitué à utiliser les commande ifup et ifdown qui sont en réalité des scripts bash qui appellent entre autre ifconfig.
Ces scripts ont été abandonnés par les distributions Linux qui sont passées à systemd et NetworkManager.

En simplifiant, l'équivalent des commandes suivantes avec NetworkManager :

$ ifconfig
$ ifup eth0
$ ifdown eth0

est :

$ nmcli device status
$ nmcli connection up <nom_de_connexion>
$ nmcli connection down <nom_de_connexion>

Contrairement à mon intuition initiale, NetworkManager n'est pas un simple "wrapper" de la commande ip d'iproute2.

En fait, nmcli fonctionne de manière totalement indépendante d'iproute2, il utilise l'interface Netlink comme l'illustre cet exemple de la commande nmcli device show :

nmcli device show
    ↓ (Method call via D-Bus)
org.freedesktop.NetworkManager.Device.GetProperties()
    ↓ (NetworkManager traite la requête)
nl_send_simple(sock, RTM_GETLINK, ...)
    ↓ (Socket netlink vers kernel)
Kernel: netlink_rcv() → rtnetlink_rcv()
    ↓ (Retour des données)
RTM_NEWLINK response
    ↓ (libnl parse la réponse)
NetworkManager met à jour ses structures
    ↓ (Réponse D-Bus)
nmcli formate et affiche les données

Autre différence, contrairement à iproute2, les changements effectués par NetworkManager sont automatiquement persistants et il peut réagir à des événements, tel que le branchement d'un câble réseau et la présence d'un réseau WiFi connu.

Les paramètres de configuration de NetworkManager se trouvent dans les fichiers suivants :

# Fichier principal
/etc/NetworkManager/NetworkManager.conf

# Fichiers de configuration additionnels
/etc/NetworkManager/conf.d/*.conf

# Configurations système (root)
/etc/NetworkManager/system-connections/

# Configurations utilisateur
~/.config/NetworkManager/user-connections/

Comme souvent, Ubuntu propose un outil "maison", nommé netplan qui propose un autre format de configuration. Mais je préfère utiliser nmcli qui est plus complet et a l'avantage d'être la solution mainstream supportée par toutes les distributions Linux.