Comment by razighter777
1 day ago
What practical problems do you run into with systemd?
All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic".
But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems.
People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap.
Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts.
Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.
> But there's a reason it's being adopted: it does it's job well
My problem with systemd is that it's taking over more and more and locking in. It is encouraging developers to have a hard dependency on it, and making it harder to have an alternative.
My problem is not philosophical with "it's a monolith, it's not unixy". My problem is "it's on the way to lock me in".
We like to complain about lock-in across the board. I don't see why it would be different with systemd.
I think you got it backwards. Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.
I somehow don't think your gripe is with systemd but with developers who prefer the easy route. To be honest though you get something for free. If you want it differently then you have to do it yourself.
I don't think it's backwards; it's not incompatible with what you said.
> It is just nice to know that all the tools you need for a system are there and work together.
It is indeed! Just like everybody uses WhatsApp for a reason. But because everybody uses WhatsApp, it is very difficult to get traction with an alternative. That's the lock-in part.
It is easier for developers to only care about systemd. It's often worse: many times I have seen projects that only work with Ubuntu. Of course I understand how it was easier for the developers of those projects to not learn how to "be nice" and "do it right". That does not mean I should be happy about it.
> If you want it differently then you have to do it yourself.
Or I should support alternatives, which I do. I am not saying you are not allowed to use systemd, I am just explaining why I support alternatives. Even though systemd works.
1 reply →
> Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.
That's the official story, but like most official stories, it doesn't really hold up to scrutiny.
I built an entire system from scratch with over 1,500 packages installed. Everything under the sun. Works just fine with sysvinit. Completely seamless.
If KDE/Gnome can't figure out how to fit in with the overall system design the same way thousands of other packages somehow manage to do, then their services are no longer required. Good riddance to their bloated asses. I prefer to invest my CPU cycles in better software.
Init scripts for services and such are properly handled by the distro maintainer (packager), not the developer, although it's always nice to see examples he's provided to help guide the development of my preferred version.
2 replies →
It's not a lock-in as much as making a much better product.
For example, I never liked the idea of having my programs to manually daemonize, manage logs, set up permissions and all that boring, but security-critical stuff. And with systemd, I don't have to! Program reads from stdin/stdout, maybe gets socket from socket activation, and systemd does the rest.
Is it lock-in? Only because other system suck. Like, seriously, what stopped xinetd from having rudimentary volatile "on/off" control, so I could disable misbehaving service? Or why is start-stop-daemon so _stupid_, discarding all startup error messages? And don't get me started on all the different init file dialects for each system.
Maybe if the sysvinit programmers actually cared about providing nicer services to app developers, we would never end up with systemd.
The problem with the word "sysvinit" here is it's sort of a red herring. BSD init is better, in my opinion. I don't like managing all those symlinks. Plus, sysvinit is an old 90s application and its code does have some cruft built up over the years that could be removed and simplified. I'm devising a new init for my system that's much simpler than sysvinit and much closer to BSD.
3 replies →
I wrote up some issues with service reliability here https://github.com/andrewbaxter/puteron/?tab=readme-ov-file#...
Design-wise, I think having users modify service on/off state *and* systemd itself modify those states is a terrible design, which leads to stuff turning back on when you turn it off, or things turning off despite you wanting them on, etc. (also mentioned higher up)
FWIW after making puteron I found dinit https://github.com/davmac314/dinit which has a very similar design, so presumably they hit similar issues.
Systemd usually only modifies the state if is somehow configured to do so. Socket activations, timers, depwndencies. They all tell systemd what to do and can usually be modified if needed.
Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound.
But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.
To give you concrete examples:
1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.
2. Except that you can, but only if you use the /etc/fstab compat.
3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.
4. Systemd has separate behaviors for network and local filesystems.
5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!
6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.
7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.
I can go on for a looooong time.
5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.
They're already reported. And ignored. Have you _seen_ the systemd issue backlog?
The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored.
The remote FS detection also came up multiple times, and the maintainers don't care.
17 replies →
That is one of my problems with systemd: it has way to much "magic" built in. SysVinit/OpenRC and related are easy to understand and debug: they only do what's in the scripts.
I love systemd, but you've hit on one of my biggest complaints. The mounting promises a cohesive system and instead gives you a completely broken mess, with mounts being split across .mount unit files, fstab, and worst of all, .service unit files. It's a totally incoherent mess, and that's only _after_ you figure out why nothing is working right, and build a complex mental model of every single feature that does or doesn't work in which scenario. Knowledge you only gain after screaming and tearing your hair out for a weekend. Your reward? A totally incoherent, inconsistend mess.
I hate mounts in systemd.
And don't forget automounts! They are so much fun!
[dead]