The original blog post with external links.
FreeBSD’s init was very intriguing to me. It’s written ingenuously and well documented. And it was really fun to learn the ins and outs of it. I just kept getting questions about it that I had to find answers for. Most of them were in the handbook and man pages. During the course of getting familiar with FreeBSD init, it helped make me familiar with many other aspects of FreeBSD. That’s how FreeBSD and I became friends.
Very happy with void linux and runit.
There are more choices than systemd and bsd init. When not using void, I just install runit and use it for my custom services.
edit: Posted that on my phone, some elaboration: Runit gives me everything I want. Fast parallel init, very simple init scripts (it’s just bash, but they’re usually around 3 lines), and easy service management. Services are enabled by creating symlinks, like symlinking sites-available to site-enabled in nginx.
The scripts are usually something like:
exec 2>&1 binary
And a second script starts the logger:
exec svlogd /var/log/myservice
Thats pretty much it. Runit will keep the process running, and your process just needs to log to stdout/err and svlogd will handle logging and rotation and all that.
I like that I feel like I understand pretty much the whole system and that its both easier to use and easier to understand than BSD init. I believe the whole system is something like 7k lines of code.
I have to use runit at work at scale, and it’s…awful. There are a myriad of error cases that it handles incredibly poorly, and the scaffolding that we’ve had to set up to ensure that logging happens, or that runsvdir doesn’t loose track of its controlled processes. Managing dependencies is frankly impossible, especially with no concept of dependencies, and the hokey fake runlevel support it has.
And don’t get me started on how you debug runit issues. Logging to the process title is not logging. This makes debugging really difficult, especially at any large site. runit only works well enough for us because our configuration management tool props it up and recovers from most failure scenarios.
But what if its code base got the same development effort but with a better direction?
Or there’d be a similar simple solution getting it?
I have to say, on the whole I feel systemd is better for Linux than it is worse for Linux. I mean to say Linux is better off with it than without it.
With that said, though, I can whole heartedly understand why people don’t like it and I must admit I too have decided to leave Linux for BSD, but not because of systemd.
Out of curiosity, why do you think systemd is better for linux?
For me it solves nothing about linux, but about the linux distribution space. Too many distros had way too shitty of init systems (openrc as mentioned in the blog here had MANY MANY more bugs opened against it than systemd), and made no solid efforts to make big changes because they are a distro, generally not a pile of C programmers. systemd has made it such that many distros now look & feel the same to me, which is very simplifying mentally. My workarounds for what make things crappy are easy to implement when I know I just need to run systemctl and add a few service drop-ins to /etc/systemd/system.
Is systemd the best init? Nope, I hate most of it, and I really hate the lack of portability. We should write open source assuming that linux might go away, not such that linux must live forever. Note: I also dislike docker for similar reasons. Linux or die is a philosophy from a time when the UNIX market was mostly proprietary. Now it’s an obscenity thrown in the face of projects whose portability is largely responsible for the success of Linux.
Why should a Linux low level user land tool be portable? The various things in a BSD userland are certainly tied to BSD.
Why should a linux tool not be portable? Saying you don’t have time, or “patches welcome” is fine. But these projects that openly say they intend to reject patches to make them portable are offensive in the highest sense.
/sbin/init is not some “low level user land tool” that other systems don’t need, and the features they export all rely on unix processes and maybe some chroot / jail magic. The rest is depressingly the same, that’s why something could be implemented entirely in bash, which is praised in this article.
There is no technical reason for systemd to be linux only when an IPC and cgroups are some of the least unique parts of linux! If you can run a modern web browser (i.e. not a hypervisor, but something as big) then the compatibility code is possible to write.
For the same reasons he lays out in his article actually. Linux finally has some consistency across distributions. I think that was something Linux was sorely missing and one of the major points BSDers had over Linux.