systemd v259 Released
35 comments
·December 18, 2025sovietmudkipz
madjam002
Definitely don't recommend going down this path if you're not already familiar with Nix, but if you are, a strategy that I find works really well is to package your software with Nix, then you can run it easily via systemd but also create super lightweight containers using nix-snapshotter[0] so you don't have to "build" container images if you still want the flexibility of containers. You can then run the containers on Docker or Kubernetes without having to build heavy images.
rbjorklin
You sound like you've explored at least a few options in this space. Have you looked at https://agones.dev/ ?
sovietmudkipz
Yes! It’s a great project. I’m super happy they have a coherent local development story. I kinda abandoned using it though when I said “keeeep it simple” and stopped using containers/k8s. I think I needed to journey through understanding why multiplayer game services like Agones/gamelift/photon were set up like they were. I read through Multiplayer Game Programming: Architecting Networked Games by Joshua Glazer and Sanjay Madhav really helped (not to mention allowed me to better understand GDC talks over multiplayer topics much better).
This all probably speaks to my odd prioritization: I want to understand and use. I’ve had to step back and realize part of the fun I have in pursuing these projects is the research.
dijit
This is sort of how I designed Accelbytes managed gameserver system (previously called: Armada).
You provide us a docker image, and we unpack it, turn it into a VM image and run as many instances as you want side-by-side with CPU affinity and NUMA awareness. Obviating the docker network stack for latency/throughput reasons - since you can
They had tried nomad, agones and raw k8s before that.
sovietmudkipz
Checking out the website now. Looks enticing. Would a user of accelbyte multiplayer services still be in the business of knowing about underlying VMs? I caught some copy on the website that led me to question.
As a hobbyist part of me wants the VM abstracted completely (which may not be realistic). I want to say “here’s my game server process, it needs this much cpu/mem/network per unit, and I need 100 processes” and not really care about the underlying VM(s), at least until later. The closest thing I’ve found to this is AWS fargate.
Also holy smokes if you were a part of the team that architected this solution I’d love to pick your brain.
colechristensen
> (target 80% resource utilization, funny things happen after that — things I don’t quite understand).
The closer you get to 100% resource utilization the more regular your workload has to become. If you can queue requests and latency isn't a problem, no problem, but then you have a batch process and not a live one (obviously not for games).
The reason is because live work doesn't come in regular beats, it comes in clusters that scale in a fractal way. If your long term mean is one request per second what actually happens is you get five requests in one second, three seconds with one request each, one second with two requests, and five seconds with 0 requests (you get my point). "fractal burstiness"
You have to have free resources to handle the spikes at all scales.
Also very many systems suffer from the processing time for a single request increasing as overall system loads increase. "queuing latency blowup"
So what happens? You get a spike, get behind, and never ever catch up.
https://en.wikipedia.org/wiki/Network_congestion#Congestive_...
esseph
If you use podman quadlets, you get containers and systemd together as a first class citizen, in a config that is easily portable to kubernetes if you need more complex features.
sovietmudkipz
O.O this may be the feature that gets me into podman over docker.
baggy_trough
Did you try systemd's containers (nspawn)?
anotherhue
systemd-networkd now implements a resolve hook for its internal DHCP
server, so that the hostnames tracked in DHCP leases can be resolved
locally. This is now enabled by default for the DHCP server running
on the host side of local systemd-nspawn or systemd-vmspawn networks.
nix0n
> Support for System V service scripts is deprecated and will be removed in v260
All the services you forgot you were running for ten whole years, will fail to launch someday soon.
noosphr
Every release of redhat software makes me happy I switched to openbsd for my human scale computers.
sebazzz
For me it is quite a list.
However, it is not easy figuring out which of those script are actually a SysVInit script and which simply wrap systemd.
bonzini
As I wrote in another comment, just check out /run/systemd/system. You'll find the wrapper units that systemd creates for your sysvinit scripts.
throw0101d
Nextgrid
Who needs to read mail when you can even make it receive mail!
Make an `smtp.socket`, which calls `smtp.service`, which receives the mail and prints it on standard output, which goes to a custom journald namespace (thanks `LogNamespace=mail` in the unit) so you can read your mail with `journalctl --namespace=mail`.
A4ET8a8uTh0_v2
Despite being philosophically opposed to it, I can't deny that it is as common as it, because of how easy it seems to make the initial setup. By comparison, when I recently tried void linux, it simply requires ( maybe even demands ) more of its user.
Mikhail_K
[flagged]
orangeboats
Can we put a stop to this weird obsession with attacking Pottering under _every_ systemd-related thread?
Fine, we get it, you don't like him. Or you don't like systemd. Whichever it is, comments like yours often provide zero substance to the discussion.
nicolaslem
Maybe I have been here too long but I can guess exactly the content of each thread about systemd/Gnome/Wayland/Firefox before opening the link.
sam_lowry_
I agree emotionally, but OTOH we should not forget about the incentives of people and the history of projects.
beanjuiceII
the project is largely successful though, supporting linux has been way more pain when we have to do it for non systemd systems.. but i guess good news is we just charge customers more for their niche setups
McDyver
I agree with your 2nd statement, but people should bring up things that should be discussed.
Otherwise, at some point, one of the 10000 [0] won't know there are alternatives and different ways of doing things.
fleroviumna
[dead]
nottorp
What has it taken over this time?
Hobbyist game dev here with random systemd thoughts. I’ve recently started to lean on systemd more as my ‘local game server process manager’ process. At first I thought I’d have to write this up myself as a whole slew of custom code, but then I realized the linux distros I use have systemd. That + cgroups and profiling my game server’s performance lets me pack an OS with as many game servers dynamically (target 80% resource utilization, funny things happen after that — things I don’t quite understand).
In this way I’m able to set up AWS EC2 instances or digital ocean droplets, a bunch of game servers spin up and report back their existence to a backend game services API. So far it’s working but this part of my project is still in development.
I used to target containerizing my apps, which adds complexity, but often in AWS I have to care about VMs as resources anyways (e.g. AWS gamelift requires me to spin up VMs, same with AWS EKS). I’m still going back and forth between containerizing and using systemd; having a local stack easily spun up via docker compose is nice, but with systemd what I write locally is basically what runs in prod environment, and there’s less waiting for container builds and such.
I share all of this in case there’s a gray beard wizard out there who can offer opinions. I have a tendency to explore and research (it’s fuuun!) so I’m not sure if I’m on a “this is cool and a great idea” path or on a “nobody does this because <reasons>” path.