It's pretty comprehensive (i.e. uses it for reload notification too), but still relatively short.
In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial
that one can explain it in one sentence: send an AF_UNIX datagram containing READY=1 to a socket whose path you find in the $NOTIFY_SOCKET env var.
But apparently turning that sentence (which appears in similar fashion in the man page) into code is not trivial, hence this new example code.
Hence, copy away, the thing is MIT licensed. And the protocol has been stable for a decade, and I am pretty sure it's going to remain stable for another decade at least.
5️⃣ Here's the 5th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
I am pretty sure all of you are well aware of the venerable "sudo" tool that is a key component of most Linux distributions since a long time. At the surface it's a tool that allows an unprivileged user to acquire privileges temporarily, from within their existing login sessions, for just one command, or maybe for a subshell.
Credit where credit is due! I'd really like to take a minute and thank Jia Tan how they helped us to finally get sd_notify() support merged into OpenSSH upstream!
I recently implemented a fun little feature for systemd: inspired by MacOS' "target disk mode", a tiny tool called systemd-storagetm, that exposes all local block devices as NVMe-TCP devices, as they pop up. The idea is that if available in your initrd you can just boot into that (instead of into your full OS), and can access your disks via NVMe-TCP (in case you wonder what that is: it's the new hot shit for exposing block devices over the network, kinda like iSCSI, NBD, …, but cool).
Here's a fun new feature we are working on in systemd: userspace-only reboot. In order to reduce grey-out times on image-based OS updates to next to nothing we are making a reboot happen where kernel stays as it is, but userspace shuts down as usual, then possibly transitions into a new rootfs, and starts up again with an initial transaction as it would on a classic system boot. During the transition selected services can pass along their fds and listening sockets, to pass "live" resources…
I just added a bunch of new entries to it (at the bottom). If you are looking for something to hack on (and have some kernel expertise, or would like to acquire it), would be more than excellent to work on those!
So we merged this → https://github.com/systemd/systemd/pull/28891 into systemd today. I like to believe that this is a major step towards closing the "TPM gap" we have on Linux toward other OSes. It can automatically generate an automatic TPM2 PCR policy from various inputs covering the PCRs that generally are hard to predict by the OS vendor, i.e. things like local firmware versions, extension cards and so on. It stores this in an NV index in the TPM. Things like LUKS can then be locked against that NV index.
It's an mkosi-built OS-in-a-single-EFI-binary whose only job is to expose all local disks via NVMe-TCP. You can write it to an USB stick, or drop it in your ESP, and if you boot it, all block devices are exposed to the network. The suggested command line to connect to this disk is shown on screen.
This makes use of the systemd-storagetm service we added for systemd v255, as well as the esp output added in mkosi v19.
We recently added a new document to the systemd website focussing on one specific facet of the service manager: the fdstore. A concept that people should really use more to facilitate "seamless" service restarts and various other things. Please have a look:
6️⃣ Here's the 6th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
In the 2nd installment of this series we have already discussed system and service credentials in systemd a bit. Quick recap: these are smallish blobs of data that can be passed into a service in a secure way, to parameterize, configure it, and in particular to pass secrets to it (passwords, PINs, private keys, …).
1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd.
ssh is widely established as the mechanism for controlling Linux systems remotely, both interactively and with automated tools. It not only provides means for secure authentication and communication for a tty/shell, but also does this for file transfers (sftp), and IPC communication (D-Bus or Varlink).
Here's another little feature we scheduled for the next systemd release. Everyone knows SSH well, and it's great to connect to hosts remotely, and even do file transfer. It's probably the single most relevant way to talk to some host for administration and various other tasks. It's a bit fragile though: it requires networking, and that even if we talk to a local VM or full OS container. But precisely networking is one of the things you might want to administer via SSH, hence you have a cyclic…
Here's a fun little thing we commited to systemd the other day: the concept of .v/ directories. What do we mean by that? Many of systemd's commands that take big resource files that are often versioned (e.g. a disk image file you could pass to sysemd-nspawn's --image= switch) now learnt a magic trick if you pass a path whose last component has the suffix ".v" and is a directory. If so, the tool will iterate through the dir's contents, do a version sort and automatically pick the newest version.
1️⃣5️⃣ Here's the 15th installment of posts highlighting key new features of the upcoming v256 release of systemd.
systemd integrates with many components of the OS. Due to this it links against various external libraries. Generic distributions – which typically enable all features a package provides – usually have to deal with relatively large dependency trees in cases like this.
A while back we started to turn many of the library dependencies of systemd from regular ELF dependencies (which you can explore with tools like lddtree or readelf -d … | grep NEEDED) into dlopen() deps, in order to minimize the dep footprint of systemd. The primary reason for this was to make it easier to build small disk images without optional components, in particular for the purpose of initrds or container deployments. Recently, another reason for doing this came into focus:
It's a very simple approach. All it does is insert an ELF "note" into generated binaries that declare these deps. This information can then be consumed by package managers, initrd generators and other tools.
1️⃣0️⃣ Here's the 10th installment of posts highlighting key new features of the upcoming v256 release of systemd.
You might be aware of systemd-sysext: a component of systemd that can overlay immutable disk images (DDIs) on top of /usr/, to extend it in a secure, and again, immutable fashion. It has a companion tool systemd-confext that does the same over /etc/.