26 ms·
I'm a maintainer of runC and long-term contributor to Docker. From my perspective, systemd has been nothing but a huge pain from a development perspective. Not
by cyphar 10y ago
I'm a maintainer of runC and long-term contributor to Docker. From my perspective, systemd has been nothing but a huge pain from a development perspective. Not because of the UX (which is okay, there's lots of odd stuff there too) but because systemd sets up the system in a way that is ridiculously frustrating for people using low-level kernel primitives directly.
If you want to use cgroups and don't want systemd to start messing around with your setup, then you have to go through systemd (which is bad, but it gets worse when you find out that systemd doesn't support all cgroups). Also, systemd has ridiculous defaults. I wrote the pids cgroup code in the kernel, and was surprised when systemd set the default limit for all system services to be 512 tasks and 4096 for all user tasks. Then there's the binary logging format which is such a brain-dead idea, that I'm not even sure how someone actually went through the process of writing the code without ever considering that it was a bad idea.
That's just one example of the things that annoy me with systemd. Things mostly work with it, but if you actually want to do something, using it is such a pain. If systemd had stayed as what was promised (a replacement for init scripts) and hadn't gone beyond that (managing your bootloader, binary logging, abusing cgroups and changing the kernel plans for what cgroupv2 should look like, messing around with coredumps, misusing /dev/kmem to actually spam people who are trying to debug kernel issues, an-almost-but-not-quite reimplementation of ntpd, etc).
If they didn't have such strong views that they were entitled to be the owners of my system, it might actually have turned out as a good project. Too bad that the management of the project has decided that they should "rewrite all the things, but badly".
- elcritch 10y agoI concur as a user of Docker. Trying to get a legacy application running on Docker went smoothly. That is until I tried to start a simple rpcbind service and discovered that during my time away from software development and linux that systemd had taken over plain old kludgy (but hackable!) sysV init scripts. Trying to get a dead simple service running took hours because systemd segfaults instead of gracefully handling and reporting errors. In this case, cgroups wasn't mounted, though why a system init system has a hard requirement on a relatively new kernel feature set not needed in this situation, I can't fathom. Eventually I found a shim for cgroups, but seriously it was a pain. I lost half a night's sleep due to shoddy system level programming you mention from systemd. I'm currently highly eager for FreeBSD 11.0 to reach code freeze. It has a new Docker / linux64 layer and _no_ systemd.
- cyphar 10y ago> I'm currently highly eager for FreeBSD 11.0 to reach code freeze. It has a new Docker / linux64 layer and _no_ systemd. For what it's worth, if you find a distro that doesn't have systemd you can run Docker and runC on it -- both use the underlying kernel primitives themselves and aren't wrappers for systemd scripts.
- elcritch 10y agoTrue, that's also a good point. Alas, many of the non-systemd Linux distros have pretty small communities. Do you have any preferred distro's for this?
- JdeBP 10y agoYou should have commented at https://news.ycombinator.com/item?id=11675129 https://news.ycombinator.com/item?id=11675129 . (-: Here, however, your audience has launchd, and has had for over a decade, running on top of Mach IPC; and BSD APIs such as kevent() for tracking forking processes.