Verwaltet von:
#systemd
15 Beiträge15 Beteiligte2 Beiträge heute
systemd 259 will increase system requirements
While systemd 258 RC3 was released with the last-minute fixes, the development team is planning to increase the system requirements for the upcoming systemd 259 version. This is to reduce the maintenance burden that old versions of dependencies may cause and to allow time for more meaningful changes.
Initially, the following dependencies will be needed for the upcoming systemd v259 init system:
- Linux kernel >= 5.10
- recommended >= 5.14
- glibc >= 2.34
- libxcrypt >= 4.4.0 (libcrypt by glibc will be no longer supported)
- util-linux >= 2.37
- elfutils >= 0.177
- openssl >= 3.0.0
- cryptsetup >= 2.4.0
- libfido2 >= 1.5.0
- libseccomp >= 2.4.0
- python >= 3.9.0
All Linux distros that provide at least the above dependencies will be able to take advantage of the new features and the improvements that systemd 259 will bring in the coming months.
Meanwhile, the above dependencies are not going to be needed for systemd 258, which will be released soon.
Just one more RC bro, I swear bro just one more will fix it https://github.com/systemd/systemd/releases/tag/v258-rc3
GitHubRelease systemd v258~rc3 · systemd/systemdCHANGES WITH 258 in spe:
Incompatible changes:
* Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) has been
removed. cgroup v2 ('unified' hierarchy) will always be mounted
d...
Save the date! We'll have another edition of #BoilingTheOcean in Berlin on October 3-5, right after All Systems Go. More details to follow 
Today I realized that a lot of people don't seem to know about #systemd drop-in files. Stuff you can drop in /etc/systemd/system/<service>.service.d/whatever.conf, and they'll be merged into the service.
You can use this to create common abstractions, and rather than editing random service files shipped by upstream, or your distribution, you can just symlink a common abstraction to a drop-in, and voila.
This is mighty useful if you want to lock things down further, and don't want to repeat yourself N+1 times.
Antwortete im Thread
Antwortete R.L. Dane 
@rl_dane the systemd crowd is also working on replacing the #FHS with their idea of how a GNU/Linux filesysten should look like 
according to LWN.
They’re good at appropriating general-sounding names (first freedesktop.org now "Linux #UAPI group") for themselves to be able to say (from the systemd side) that "an independent standards group" (staffed with their people) is doing the change.
"But it’s not just people from #systemd but also from […], Debian, […]" they say. Yes, strictly speaking the systemd maintainers in Debian, who are responsible for lots and lots of breakage on users’ systems hy forcing through their stuff, are "people from Debian".
Oh, and they also have a token subgroup where someone not from the systemd/gnome/fdo crowd is working on somethi g totally unrelated to be able to say they’re not an sd/g/fdo-only ship, even if both in practice and for this specific project fully they are.
I've just published version 25.7.1 of 'kpfleming.systemd_networkd', my collection of Ansible roles for managing systemd-networkd configuration. New in this release are a half-dozen 'advanced' features in the 'network' role, along with a new 'bridge' role. Most of these changes originated from my recent project to switch to DHCPv6-PD on my home network, and also eliminate the standalone DHCPv4 servers I was using.
If you're an Ansible user and use systemd-networkd on your managed machines, take a look! Here's an example of a moderately-complex configuration:
https://github.com/kpfleming/ansible-systemd-networkd#examples
I've got more complex ones if you're really interested 
#Ansible #systemd #networking #systemd-networkd
GitHubGitHub - kpfleming/ansible-systemd-networkd: A collection of Ansible roles for managing the configuration of systemd-networkd.A collection of Ansible roles for managing the configuration of systemd-networkd. - kpfleming/ansible-systemd-networkd
it is called "systemd", not "SystemD", not "systemD", and defintively not "system-D"!
Recording for my #froscon talk on shipping #kubernetes as a #systemd #sysext and painless in-place updates on #Flatcar #Linux is now available: https://media.ccc.de/v/froscon2025-3330-immutable_turtles_all_the_way_down#t=25
Hardening Systemd Services
Dear #BSD / #Anti_SystemD peeps,
Please make friends with #Linux-only, #Systemd fans.
#X114EVR peeps, please make friends with #Wayland fans.
The only way the community at large moves forward is to keep conflict within the domain of friendship. That way we can hold our differences, and learn to synthesize the disagreements.
And please, please don't assume that someone is your ally just because they agree with you on one technical point. I don't have a problem with X11 being maintained until the end of time, I just don't want it to be led by someone with really horrible/destructive politics.
It's not #CancelCulture, it's mercy. I would like to see a destructive ideology "canceled," but people are never my enemy.
Edit: minor re-phrasing of last paragraph
Ask UbuntuSystemd killing ExecStop oneshot script nearly instantly after executing itMy eventual goal is to have nodes in my Microk8s homelab self-cordon themselves ahead of shutdowns/reboots especially in the case of unattended upgrades.
/etc/systemd/system/pre-reboot-drain.servic...
Fortgeführter Thread
I was hoping to see that sort of functionality directly in #GNOMESoftware when applying system updates that don't touch the kernel, but it seems some piece of the puzzle is missing here (maybe a hybrid of #systemd's "soft-reboot" and #DNF's "system-upgrade"): https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2427
GitLabSupport systemd userspace soft reboots (instead of only full cold boots) when applying distro package updates other than the kernel (#2427) · Issues · GNOME / gnome-software · GitLab Historical context / problem statement Currently, GNOME Software forces users to do a full reboot to apply any package updates other...
The "systemctl soft-reboot" #systemd command is so cool 
https://www.freedesktop.org/software/systemd/man/latest/systemd-soft-reboot.service.html
Finally a clean way to rapidly re-start everything other than the #Linux kernel… for me, it is extremely useful to be able to do that after applying desktop & graphics stack updates, and to be able to log back in within 10 seconds.
Throwing the idea out here: it would be very nice if someone figured out a way to write a #GNOMEShell extension to provide "Soft reboot" as an alternative to cold reboot!
www.freedesktop.orgsystemd-soft-reboot.service
Antwortete im Thread
@pid_eins til
Thanks, also
Once you create a container, #Podman can automatically generate a #systemd service file to start and stop that container. Starting the service creates (or replaces) the container, and stopping the service removes the container. So that already takes care of my "manage each original flag" problem.
But the cherry on top if that if you tag your containers with io.containers.autoupdate, then once a day on a timer or on-demand when you podman auto-update, it will check for a new image and if there is one it will recreate the container for you with the new image.
https://blog.yaakov.online/replacing-kubernetes-with-systemd/
Yaakov's Blog · Replacing Kubernetes with systemd
Mehr von 
Yaakov
Holy hell, the #systemd documentation is a giant rat's nest.
Someone needs to come up with a user-friendly program for creating .service files.
I can't handle having to mentally overlay several man pages in order to get the full picture.
Also, I hate hate hate that it uses a conversational style for describing things that should be bulleted lists, forcing me to parse several words into each paragraph to find the actual option name being described.
What a goddamned mess.