On Thu, 2026-06-18 at 18:43 +0200, Alexander Kanavin via lists.openembedded.org wrote: > Hello all, > > I've been working on a systemd version update from 259 to 260, and one > of the new issues is that systemd-systemctl-native no longer runs on > RHEL 8 derivatives. A closer look shows that: > > [akanavin@rocky8-vk-1 260.2]$ > ./image/home/akanavin/build/tmp/work/x86_64-linux/systemd-systemctl-native/260.2/recipe-sysroot-native/usr/bin/systemctl > Failed to acquire PID reference on ourselves: Function not implemented > > And indeed, RHEL 8 ships kernel 4.18, while the needed function > pidfd_open was added in 5.3.
I don't think systemctl-native should be executing processes and therefore shouldn't need this functionality to do the limited set of things we need it to do. The above sounds a bit like a sanity test that the functionality is present. Perhaps we could either just disable it for our native tool, or possibly move it to later when it really needs it? > On the other hand, this leaves the question of what to do with > rhel/centos/rocky/alma 8. That distro was released in May 2019, was > transitioned to extended support in May 2024, and will cease to be > supported in May 2029. I'm not sure who, and why is asking for Yocto > Project to support RHEL for the full ten years, but now there's a > choice: drop RHEL 8 from the supported list and CI testing, or get > stuck on systemd 259. Theoretically we could also go back to our > custom re-implementation of systemctl, but I would really rather not. Corporate IT environments like to use old known setups like RHEL 8 derivatives and don't change often. While it is in supported lifetime, it is hard for us to remove it. This requirement is therefore fairly important to some of our member companies. Personally, I wish it were different but it is what it is. > A related, lesser issue is that systemd has glibc requirements too, > version 260 raised that from 2.31 to 2.34, and indeed Debian 11 is no > longer able to build systemd-systemctl-native. I believe this is > easier to mitigate, through buildtools and uninative, which together > insulate native pieces from host glibc pretty well. Yes, this is the first time we've had a hard kernel requirement which is quite a different thing to work around... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2406): https://lists.openembedded.org/g/openembedded-architecture/message/2406 Mute This Topic: https://lists.openembedded.org/mt/119870359/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
