Hacker News new | past | comments | ask | show | jobs | submit login

> I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems.

It's been the same situation for me, too.

Every time I get stuck dealing with a new systemd-related problem and search online for solutions, the huge number of bug reports, mailing list posts, forum posts, IRC logs, and other communications I incidentally see describing my problem and/or other troubles involving systemd remind me that I'm not alone. Many other people are consistently having a wide variety of problems with it, too, and this has now been going on for years and years.

Systemd has driven me to move systemd-using Linux systems I end up responsible for over to FreeBSD or OpenBSD whenever possible. Their init systems aren't perfect, but they almost never cause me problems. In the very rare cases when they aren't working for some reason, at least those systems are simple enough that I can usually debug the issue on my own, without having to search for help online.




Can you describe one of your problems? I've had very smooth sailing with systemd and I like not having to play games with pid files and pgrep like I had to in the 90s.


I can't speak for VancouverMan, but my experience has been similar. A few examples of the problems I have with systemd:

System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted.

Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope -p "Delegate=yes" <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable.

At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back.

There are more examples, but I'm tired of re-living them and don't really want to write a book.


> Systemd has driven me to move systemd-using Linux systems I end up responsible for over to FreeBSD or OpenBSD whenever possible.

Nice that you privately do it privately. In Enterprise environment however is different, and systemd played an important role in having Linux reaching that level.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: