<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Systemd on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/systemd/</link><description>Recent content in Systemd on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/systemd/index.xml" rel="self" type="application/rss+xml"/><item><title>cgroups (Control Groups) v2</title><link>https://lesitedefrancois.be/en/security/cgroups/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/cgroups/</guid><description>&lt;p&gt;&lt;strong&gt;Control Groups (cgroups)&lt;/strong&gt; is a Linux kernel mechanism, introduced in 2.6.24 (2008), that organises processes into a hierarchy of named groups and uses &lt;strong&gt;controllers&lt;/strong&gt; to account for and limit each group&amp;rsquo;s consumption of CPU time, memory, I/O bandwidth, and process count. Every container runtime in existence — Docker, containerd, CRI-O, Podman — uses cgroups to enforce the resource limits declared in a container spec (&lt;code&gt;--memory&lt;/code&gt;, &lt;code&gt;--cpus&lt;/code&gt;, &lt;code&gt;requests.memory&lt;/code&gt;, &lt;code&gt;limits.cpu&lt;/code&gt;). Every systemd service on a modern Linux system runs in its own cgroup slice. Without cgroups, a container or service could consume all available memory, CPU, or file descriptors, starving other workloads on the same host. The current production version is &lt;strong&gt;cgroups v2&lt;/strong&gt; (also written cgroupv2, unified hierarchy), stable since kernel 4.5 and the default on all major distributions since RHEL 9, Ubuntu 21.10, and Fedora 31.&lt;/p&gt;</description></item><item><title>firewalld</title><link>https://lesitedefrancois.be/en/security/firewalld/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/firewalld/</guid><description>&lt;p&gt;&lt;strong&gt;firewalld&lt;/strong&gt; is the firewall management daemon on RHEL, CentOS Stream, Fedora, SUSE, and their derivatives, providing a higher-level policy model and a runtime-safe management API on top of &lt;strong&gt;nftables&lt;/strong&gt; (RHEL 8+ / Fedora 32+) or iptables (older systems). Its defining feature is &lt;strong&gt;runtime versus permanent configuration&lt;/strong&gt;: firewall rule changes can be applied immediately to the running system without restarting the service or dropping existing connections (&lt;code&gt;--runtime&lt;/code&gt;, the default), and separately persisted to disk so they survive reboots (&lt;code&gt;--permanent&lt;/code&gt;). This two-phase model solves the operational problem that raw nftables or iptables rule changes traditionally required either accepting a momentary policy gap during reload or building custom transaction logic. The daemon exposes its API over &lt;strong&gt;D-Bus&lt;/strong&gt;, allowing NetworkManager, libvirt, Podman, and other system components to request firewall policy changes programmatically — when a VM is started in libvirt or a container port is published in Podman, the respective tool calls firewalld over D-Bus to open the required port rather than directly manipulating nftables rules.&lt;/p&gt;</description></item><item><title>initramfs (initial RAM filesystem)</title><link>https://lesitedefrancois.be/en/security/initramfs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/initramfs/</guid><description>&lt;p&gt;&lt;strong&gt;initramfs (initial RAM filesystem)&lt;/strong&gt; is the temporary root filesystem the Linux kernel mounts immediately after loading itself and before switching to the machine’s real root. The bootloader — &lt;strong&gt;GRUB&lt;/strong&gt;, &lt;strong&gt;systemd-boot&lt;/strong&gt;, or firmware loading a &lt;strong&gt;UKI&lt;/strong&gt; — passes a compressed &lt;strong&gt;cpio&lt;/strong&gt; image (historically called an &lt;em&gt;initrd&lt;/em&gt;, though modern Linux always unpacks it as an initramfs into &lt;strong&gt;tmpfs&lt;/strong&gt;, not a separate ramdisk block device). The kernel extracts this archive into an in-memory tree, executes &lt;code&gt;/init&lt;/code&gt; as pid 1, and that early userspace environment is responsible for everything the bare kernel cannot yet do: loading storage and filesystem kernel modules, bringing up networking, discovering and unlocking &lt;strong&gt;LUKS&lt;/strong&gt; volumes, activating &lt;strong&gt;LVM&lt;/strong&gt; or multipath devices, mounting the true root partition, and finally calling &lt;code&gt;switch_root&lt;/code&gt; (or &lt;code&gt;pivot_root&lt;/code&gt;) to hand control to the installed system’s init — typically &lt;strong&gt;systemd&lt;/strong&gt; on current distributions. If the initramfs fails, the boot stops before userspace on the real root ever starts; if it succeeds, it is discarded and its memory reclaimed once the pivot completes.&lt;/p&gt;</description></item><item><title>UKI (Unified Kernel Image)</title><link>https://lesitedefrancois.be/en/security/uki/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/uki/</guid><description>&lt;p&gt;A &lt;strong&gt;Unified Kernel Image (UKI)&lt;/strong&gt; is a single EFI executable that packages together the Linux kernel, the initramfs (initrd), the kernel command line, and optionally other resources like a splash screen or system credentials. Instead of relying on a bootloader to assemble these components at runtime, a UKI bundles them statically into one signed binary.&lt;/p&gt;</description></item></channel></rss>