Mastodon Stories for systemd v259

https://fed.brid.gy/r/https://0pointer.net/blog/mastodon-stories-for-systemd-v259.html

Right on time to coincide with the end of the year I finished my #systemd259 series of posts. And I now also prepped a blog story linking to every single one of them here:

https://0pointer.net/blog/mastodon-stories-for-systemd-v259.html

Make sure to stay tuned for the #systemd260 series, most likely starting already in a few weeks!

Also, happy new year! 🎇

2️⃣5️⃣ Here's the 25th and last post highlighting key new features of the recently released v259 release of systemd. #systemd259 #systemd

systemd-networkd has a small internal DHCP server, so that it's easy to hand out IP leases to local networks, for example for use in virtual networks (veth tunnel pairs, for example), or for small LANs. With systemd v259 the server gained a new feature, you can now configure with EmitDomain=/Domain= whether and which DNS domain to announce for client use.

2️⃣4️⃣ Here's the 24th post highlighting key new features of the recently released v259 release of systemd. #systemd259 #systemd

systemd-resolved's configuration is a bit more complex (and dynamic!) than the venerable /etc/resolv.conf file. It by default has an understanding of per-interface query servers and domain routing and a lot more. So far this data could be queried via "resolvectl status", but accessing it via IPC has been quite involved: as the information shown is distributed on multiple…

2️⃣3️⃣ Here's the 23rd post highlighting key new features of the recently released v259 release of systemd. #systemd259 #systemd

As you probably know sysemd-udevd processes notification events received from the kernel ("uevents") with a set of rules that match properties, set properties and execute code. Debugging these can be a bit annoying, since – of course – these notifications are typically result of hardware events, and hence attempts to correctly reproduce any issues in a controlled…

2️⃣2️⃣ Here's the 22nd post highlighting key new features of the recently released v259 release of systemd. #systemd259 #systemd

In v258 systemd-nspawn gained support for running unpriviled containers from directories owned by the "foreign" UID range. To get container images owned by that you had to manually chown() the images (recursively), for example via systemd-dissect --shift. And while the systemd-nspawn invocation is not privileged, that re-chown()-ing definitely has requires privileges.

2️⃣1️⃣ Here's the 21st post highlighting key new features of the recently released v259 release of systemd. #systemd259 #systemd

In episode 16 we already talked about systemd-firstboot, systemd's little configuration console tool that can run on first boot and ask the user for a few simple basic questions regarding keymap or locale or such.

With v259 it received a small facelift of a kind. First of all, we'll now turn off concurrent log output from the kernel and from PID 1…

2️⃣0️⃣ Here's the 20th post highlighting key new features of the recently released v259 release of systemd. #systemd259 #systemd

systemd's unit ordering dependencies implement a directed graph, which is supposed to be acyclic, i.e. contain no cycles, so that it's always clear which units to activate before which other units.

But given that units are typically written by humans, the graph quite often actually does have cycles, and if that happens systemd has to break them somehow, …

1️⃣9️⃣ Here's the 19th post highlighting key new features of the recently released v259 release of systemd. #systemd259 #systemd

Each systemd service has various ExecXYZ= stanzas that control what command to execute on which operation. Most importantly, there's of course ExecStart= which configures the command to run for actually starting the service. Then there's ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, ExecStopPost=.

And with systemd v259 there's one more knob like this:

1️⃣8️⃣ Here's the 18th post highlighting key new features of the recently released v259 release of systemd. #systemd259 #systemd

As you certainly are aware the Linux kernel allocates one block device node for each disk it has drivers for, plus one device node for each partition on it. For that it contains partition table parsers for a number of partition table formats.

Whenever a partition table changes on disk the block devices the kernel maintains as in-memory objects need to be brought back…