When I was a teenager adventuring through the GNU/Linux userland and all its interchangeable components (including on Gentoo!), OpenRC was awesome compared to what I was used to (SysV). Beautiful colorized output, fast startup with parallel execution of jobs... all before Upstart (RIP, though I don't miss it) and Systemd.
I'm pretty happy with Systemd these days, and in some ways I don't mind the way it has 'standardized' (read: dominated) Linux stacks. But I'm glad that people are still doing the work to keep OpenRC viable and integrating it into a full-featured, long-lived, relatively popular distro.
Gentoo was the first distro that lead to me really understanding what was going on.
So OpenRC was "normal" for me, and when the systemd debate came around I didn't think about the fact that OpenRC wasn't the norm and folks hat been using SysV init all that time.
I'm still a Gentoo user these days (although not as heavily, the laptops are running Fedora nowadays), but running systemd. The unitfile format is really great.
i was fine with systemd for a few years, even truly enjoying getting rid of hacky docker workflows in place of machined.
then i start to find out it is full of rando backdoors intended for VMs, which will run just the same on your bare metal. For example, just to list the very last one, you can inject smbios data that will be parsed to create files in your system. very convenient to drop passwords and keyfiles around a vm... unless it is the firmware on your actual bios doing the same. And we know how common persistence via bios is. sigh.
but as you mention correctly, it have crushed and dominated linux. so i guess i just waste a week or some working around those things later, as usual.
The unit and service file formats are honestly fine, it should be possible to have a second implementation. We have several varieties of SysV init already.
The unit file format is what I don't like about it. A giant spaghetti code mess where dependencies can be literally anywhere and the final imperative result is completely opaque. An init system, ultimately, does a bunch of one time actions to bring the system up; it really does just work better as an imperative script.
An init system is for all practical purposes a build system - a very complex problem where literally every sane solution is declarative. Especially when you take into account error handling (that HDD is not yet available, will you imperatively wait for it to come up and pause everything else? Do parallel work in the meantime in fking bash? Or what exactly?)
Startup is ultimately a complex problem. There is no magic, just race conditions which maybe became more apparent. LVM may or may not be used, and takes time to start up. Do you wait for it? Ditto wireless networks. And how do you handle devices being hotplugged? Setups vary widely, and can be dynamic.
How are Systemd's unit files any worse than unconstrained init scripts written in a Turing complete language with even basic stuff - like PID files - managed manually?
Because they are opaquely translated into an imperative sequence but you never get to see it.
Also who are these people who have complicated sysv scripts? I've heard this for years and never really understood it. One script per service with a stop and start command (and maybe a status if you want to get fancy) and runlevel definitions that start and stop them. It's not rocket surgery, and it's a hell or a lot easier to debug than a declarative system definition.
The reality is that it wasn't corporate scripts hidden away from the public eye. There were some nightmare van Smoorenberg rc scripts in the likes of Debian.
FreeBSD has Mewburn rc not van Smoorenberg rc and was thus inherently better in this regard until the middle of 2014 (https://unix.stackexchange.com/a/480897/5132). But even FreeBSD has some large rc scripts, particularly in the networking and the HID parts such as Bluetooth and configuring all attached keyboards; albeit that the FreeBSD style guidelines mean that they are more legible than the nightmare Debian (et al.) ones.
It may shift to a different community balance seeing how RedHat employs a lot of the main contributors to systemd and more recently are showing signs of acting in a more closed manner.
Oh I didn't realize that. Maybe similar teeth, different dragon. I'm cautious about Microsoft, but recently I'd have to say they've been a reasonable Linux community member - though if there are fewer larger balancing orgs - who knows.
> about Microsoft, but recently I'd have to say they've been a reasonable Linux community member
All it takes is to look around at what Microsoft is doing to gestures vaguely to see the writing on the wall for how Microsoft sees Linux.
Advertisements on the home screen? Advertisements on the every screen? Login darkpatterns? Configuration resets on updates? Forceful browser choices? Forced updates? UEFI shenanigans? Boot manager shenanigans?
Yup, the windows OS (as opposed to Linux) is where they have no counterbalancing reason to not pursue darker patterns. So it's a window into unchecked tendencies.
Or you know, Microsoft is a giga-company with no singular goal (besides increasing revenue). Improving and “destroying” linux may be simultaneously goals to separate areas of the same company, and due to bureaucracy I really can’t take this conteos seriously.
>but recently I'd have to say they've been a reasonable Linux community member
LOL
Its amazing how easy it is. I guess if you spend your entire history being a shitty company and then spend a couple of years pretending to be marginally less shitty then you can dupe a bunch of people.
I remember being stuck in a holiday let in the arse end of Somerset, whilst waiting for a house purchase to grind through to a conclusion. Around 2009. I got pppd to use both of our mobiles via bluetooth to get some sort of rather sad internet connection together so we could browse rather slowly and email etc.
All of that was done in /etc/conf.d/net - one file! You can also put a firewall together with it and generate routing tables and all sorts of things. I have no idea why netplan needed inventing, when net already did it all without the bloody YAML! OK - slap YAML on net. Job done.
I don't miss Miguel van S's sysvinit scripts and all the peculiarities in the various ways of doing them by distro.
I did try to write OpenRC initscripts but they are still too complicated for a simple sysadmin like me. I have used git to get an elderly Gentoo box from 2007 to 2022 - so can attest to the sheer robustness of the distro. It did take some doing.
I think that the greatest gift that Gentoo gives to its adherents is this: No matter how broken a Linux box is, provided the storage is operational, the CPU can crunch stuff and RAM is mostly functional and there are not too many holes in your files, you will repair it.
Oh and it has always had the best looking terminal in all modes, bar none, for decades.
It's probably been a while since you've last used OpenRC, and I don't know how it was back then, but these days, service scripts are really trivial to write[1]. You just need to provide the command= and command_arguments= to use, and depending on whether the daemon backgrounds itself or not, configure the pidfile location or set command_background=true. It really couldn't be easier.
Personally I just wish it had any notion of logging stdout/stderr, or a way to manage daemons as a user.
You have piqued my interest and I will spin up a VM at work and have another look at the state of the art on Gentoo.
I absolutely loved it back in the day. Every few months or so a major change would arrive and make life better. Sets - @world etc - smashing. User patching - drop a patch in a suitable directory and effectively you could fix snags yourself without having to write your own ebuild. Do your own ebuilds - again drop your override into the right directory and your personal ebuild is seamlessly part of the distro.
No doubt much more has happened in the roughly five years when I have used it in anger. Ironically enough I have two systems at work that do run Gentoo but are woefully "legacy". Today I emerged a couple of packages to fix something on one of them and it is still hanging on in there. It is quite a delicate dance on a rather crucial system. I will get rid of it eventually but one step at a time 8)
In breaking init news, I was sitting at the bar inside Guthrie's of Somerset (wet county now) the exact moment I read this comment. Tried to login for the first time in a decade to reply at the time but the mobile app doesn't have the account recovery that I could find.
Thought that was petty exciting. On this note, I think I will finally overcome my anxieties and make July the month I finally install Gentoo!
Go for it - it really is rather satisfying. Your lap will get rather warm if its a laptop! Stick to the manual and don't get too hung up on minutiae until you have to. I do recommend ~amd64 (the ~ is very significant). Although ~ means something like "beta" you tend to get much more modern software. Make sure you have another route to the internet to find out how to fix breakage because it is inevitable with Gentoo.
I leave the compiler output to fairly verbose and found it hypnotic and very satisfying to watch. I could tell what was being compiled just by the shape of the output.
The wiki and forums are superb.
You might consider running it in a VM at first to get the hang of it and make use of snapshots/checkpoints to back out failed experiments. You could turn that into a stage 4 and recover to bare metal (if you dare!)
I also remember it, first time I installed Gentoo for it, it was very nice compared to the alternatives. Also very configurable, easy, and did also have an interactive boot mode to debug a system that didn't start.
SysV isn't so much the problem; the old Debian/Redhat standard init scripts for it were the absolute mess. Slackware's implementation of SysV is something I've never had a complaint about.
That said, OpenRC also looks to be a nice system that does its job well without function creep, which is more than I can say for systemd.
Lots of domination involves democratic politics and/or expertise as well as careful deliberation. I don't think there's a logical contradiction in what you've quoted and what you've written.
I've used several Linux init systems over the years.
OpenRC is the only one I've ever liked using. Not sure why it never seemed to catch on with any of the major distros, even before Systemd made itself nigh-unavoidable.
Probably not a popular opinion in a systemd world (and being responsible for a lot of critical systems where things don't change much but absolutely have to work every day), the nice thing about sysv is all you need to know a little bit about shell commands and every day is groundhog day (i.e. not getting any calls because X has broken after touching Y). Not great for companies selling support, but great for those selling high-rel.
I agree; not so much that I've found systemd to be unreliable, so much as that it is far more opaque than even the most involved SXX/KXX SysV shell script; I can debug a shell script, but when systemd does do something unexpected, it's utterly inscrutiable.
I will take the opposite opinion. I think that systemd overall reduces the quantity, or surface area, for bugs by making many standard types of service requirements for dependencies, restarting, etc. simple configuration options.
Right but you never see what it's actually doing like you do with sysv. You have a high-level description of what you want to happen and when it messes up (invariably at 3am, invariably on a mission-critical system) you're completely in the dark about what it's trying to do. You can (and people do) mitigate this by just writing imperative startup scripts that systemd calls, but then that leaves the question of what the point is.
Managing services and dependencies and orchestrating all of that is the point. That orchestration “boilerplate” has to be correct and you can reasonably know that it is with a program made for that. If you mess up your service’s config, the problem will be local (your service won’t start), while without a declarative stance your whole system would be in an inconsistent state.
Wait, no; you're describing the exact opposite of what happens. If a sysv init script gets messed up that service fails and the system trundles on. When a unit file is wrong the whole server just sits there refusing to do anything while it waits for 30 seconds, them 90, then 120...
OpenRC is closer to systemd than sysv in that regard, though at least it logs sanely
> while it waits for 30 seconds, them 90, then 120...
That depends on how it’s configured, but that is the correct behavior under the given config. You can specify timeouts, or what depends on what and most of it is sane.
For example, what would be the logical thing to do with a server that has no internet connection? You can only wait for that.
You can debug a shellscript, but can you debug the complex orchestration of many of them with a stateful and error-prone hardware system beneath it is responsible for upbringing? It can’t even log during the early boot phase, while systemd has that solved as well.
And more importantly SysV literally consists of the shell commands that get run, which is a huge win for debugging. The more declarative systems all themselves eventually turn into a bunch of imperative exec calls, but you can't see them (runit may be the closest to keeping the visibility of sysv). And, I mean, I really love GNU shepherd but at 3am with a boss yelling at me I really just want the actual shell commands being run.
Except that you will get that 3am call every night with such a system, while systemd can actually handle failures properly with proper retry strategies, no concurrency problems, etc. And any failure will be local to a service, not the whole system state.
I mean, no? I spend a lot more time fixing init problems now than I did 15 years ago. It keeps me employed, so yay, but it's just annoying to have consistent problems I didn't previously have.
I have serious dislike for what I perceive as (unnecessary) complexity of Systemd. I made a quick analysis of different init systems when that nigh-unavoidability had not yet happened. OpenRC seemed then the most reasonable of the ones I read about (for qualities I have since forgotten), and your comment stirred this memory.
Found the ergonomics of rc-update and other commands exceptionally decent, and consistent enough that I could usually guess the correct invocation even if I hadn't used it in a while. Never saw it break or tie itself in knots (which, on Gentoo, at least as I managed my Gentoo systems, was an accomplishment). I find the config syntax non-awful. Every other init system I've tried is worse (IMO, obviously) on one or more of those fronts, and not enough-better on any others to make up for it.
Whether it is actually more complex, I don't know. I didn't claim so for actual reasons, and your comment is one of them.
I'm just a user, not a package or system maintainer, whose opinions are way more substantive than mine. Distributions have overwhelmingly chosen Systemd, so it seems obvious that it offers real benefits (including simplicity, I must assume).
As a user I just lament the missed opportunity to simplify the system and service management also from my point of view. I don't see Systemd as simpler than other init systems, just different.
Timing. When the Debian Hoo-Hah happened, OpenRC was one of the several systems evaluated, but a lot of the features, in the version that Debian had, that people were looking for weren't there yet, and it wasn't even packaged up as a stable Debian package. The OpenRC proponents commented that the features could be added and it could be packaged. But the features and packaging weren't there at the time.
(Indeed, ironically, the van Smoorenburg init+rc system actually added features a short while later that did away with much of the complaints about lengthy shell scripts full of mostly the same boilerplate. Similarly, it later became possible to drive something like s6 with OpenRC, to get proper supervision.)
> For openrc, this is a moving target. When I looked at it first during the start of this discussion, it was not even in experimental (and still is not in unstable), and documentation was hard to get. This has improved but still it is worse then the others. Also having a no-double-fork-setup for demons is something really useable, and I haven't seen any answer on that during time of writing this.
Loved OpenRC when I was still a Gentoo daily driver.
These days on I'm systemd like almost everyone else but I will never forget how advanced it felt for it's time.
It predated Upstart and systemd by several years but was already fully event-based with parallel execution etc BUT it didn't sacrifice the best parts of sysv to get there. At the end of the day you still had a bunch of relatively easily to debug shell scripts. Running Gentoo with OpenRC meant booting in a fraction of time of other distros out of the box.
I appreciate the format of systemd unit files but they result in much of the complexity, corner cases etc being baked into systemd itself reducing debugability. systemd has it's own killer features ofc like systemd-nspawn and friends.
You should try Gentoo+systemd these days. I'm running KDE Plasma on my gaming PC, and it works pretty smoothly. Wayland still has a few rare hiccups, as I'm on NVIDIA, but for the most part works without issue.
Me too. It has the best and only package management system with the required configurability for many complex but real situations that make other distros a non-option. The biggest drawback of course is if you don't update a box for awhile you have to redo from stage3 - rolling releases are a double-edged sword. In theory, portage solves this. In practice, it just gets to a certain level of ungrokkable problems and you have to pull the parachute. Currently battling with ZFS root (stage3 and portage snapshots on same filesystem) as a workaround. It's nontrivial getting that up and running again. But once I do it's probably going to be a stable workhorse for 5+ years. I'm done with Apple.
Honestly the only build system/package manager that could even compare to portage in versatility is spack. It's aimed at HPC so it's not really oriented towards desktop or even normal server packaging but it gives you what is basically the use-flags and slots systems. And bonus points for striving to get nix style reproducibility.
Zfs root on my daily driver machine is held together by... blood sacrifice .,built it's first kernel in Feb 2014 and have rescued it at least three times from catastrophic update neglect
I finally killed a fedora install 2years unupdated...I quit trying to restore it after an hour and just took my data off
That parachute even comes with a spare for some open heart surgery on a system. Migrating no-multilib -> multilib is totally doable with some careful chrooting and a rebuild from stage1.
NixOS was a fine “next step” for me from Gentoo (and arch, and probably literally every distro out there). It has an even more powerful package manager, and makes the system config a breeze, while still giving you all the control. Oh, and you can just roll back/forward to your heart’s content! Also, ZFS on root is supported by a simple flag.
When I used it (and I did use it enthusiastically for awhile) NixOS had other issues. Chiefly, large portions of real world configuration did not conform to its model. While you could in theory make anything work, I found that managing actual configuration (already enough of a challenge) with the additional backflips of straining it through the NixOS model was just not worth the time. It worked well for simple configurations that were well used, but once you strayed from that path it became increasingly tedious, while you also had the NixOS change risk added to everything else to manage over time. Final assessment at the time: relatively inappropriate for complex configuration requirements. Could be time for a revisit.
One problem is that Gerrit Pape hasn't been seen on the mailing list where xe points people to for runit support, for some years now; much to the chagrin of the people left fielding runit questions on that mailing list.
I use OpenRC to start runit on my Alpine systems, and use runit to manage everything else.
I had some trouble getting the OpenRC script "just right", and figured this was easier. The systemd people really were right about SysV init being not-so-great (which, of course, doesn't automatically mean systemd is the answer).
The overall principles and usage of runit (e.g. just keeping stdout/err attached) is significantly simpler than the whole "daemonize" dance.
Possibly the biggest hint is /etc/apk/world, the "worldfile", or the list of explicitly installed packages. It's even the same verbiage Gentoo uses (albeit a different location - Gentoo stores it somewhere under /var)
Either way, I've been watching that s6 project for a couple years now and am looking forward to when that happens. Is there any progress on that front? I hadn't heard that the replacement might not actually be s6.
Gentoo setup involves completely different downloads depending on whether you want OpenRC or systemd. It's not like there's a single installer that you run which lets you choose between the two and has OpenRC as the default choice. They're both equivalent and the installation handbook doesn't suggest either one over the other.
Of course I have no doubt that there are more Gentoo users that use OpenRC than systemd, and I wouldn't be surprised if outing yourself as a systemd user will get you flamed in tech support channels :)
I lurk the Gentoo IRC & mail (15+ years). I've never seen any systemd flames (not that they never happened). Gentoo IRC has always been helpful - even when I want to do stupid things.
I tried to setup a Gentoo system for fun last weekend. (Crazy idea of a "fun weekend," I know.) I got to selecting a profile and wondered why there was no `systemd-hardened` profile. I was googling to try and understand what the hardened profiles do and found this thread[1] which said: "My personal opinion, having read many of the threads I've referred you to is that systemd and security go together like windows and security. That is, its an oxymoron."
Maybe we have different ideas of what constitutes flaming, but to me comparing somebody's choice of operating software to the "W-word", in a linux distro support forum, is about as inflammatory as it gets. Saying that systemd is insecure-by0definition is also quite rude. This is several years old, and I'm sure things have changed in the intervening years, but as a perfectly happy systemd user I can say that thread definitely left a sour taste in my mouth, at least initially.
I don't think there is anything really stopping you from standing up a Gentoo system with OpenRC from the systemd installer or vice versa though. It seems really more like a convenience than a requirement to have both installers.
To be precise, there is a single installer image that you boot and use to create the partition layout. Then you pick a stage 3 tarball and unpack it into the root partition, and this tarball is either OpenRC-specific or systemd-specific.
Yes it is possible to change your mind and switch from one to the other after installation, but it's not straightforward.
If there was a portable implementation of namespaces that was implemented by both Linux and BSDs, then sure systemd could be made more portable. Otherwise the only reason OpenRC is more portable is that it does not isolate services in the first place (as systemd does using namespaces).
It works perfectly well with namespaces but you have to tell it to use them (it uses them for runlevels out of the box, but you need to tell the launch script if you want a process to be isolated). Though for that matter SysV does too.
It’s a system service manager, it being portable is not a requirement nor any benefit when BSD has nearly no traction in the desktop or server space other than a few cases.
> it being portable is not a requirement nor any benefit when BSD has nearly no traction in the desktop or server space other than a few cases.
Is your argument that portability is irrelevant because nothing but (systemd/)GNU/Linux matters, or that service manager in particular don't need to be portable?
gnome hard depends on systemd, so much that for it, *bsd (and any non-systemd unix-like) had to write a systemd-shim to emulate some functions of it, and/or gut some of systemd's components such as logind in to elogind
Not for a while now; accountsservice runs fine with cosolekit. I still don't understand why the broader Linux ecosystem burned the better part of a decade on the long-solved problem of "who is logged in to this TTY?", but whatever floats their boat...
It's also not a complete alternative, because it doesn't have anything for user session services like `systemd --user`. I use postmarketOS which is based on Alpine which uses OpenRC, and desktop session daemons currently have to be started by the compositor via XDG autostart files. So services start fine but they're not restarted if they crash, they have ad-hoc logging, etc.
One of the pmOS devs wrote a user session service manager [1] but pmOS doesn't use it (yet?). And Alpine as a whole is planning on moving away from OpenRC anyway.
It really seems strange to me that postmarketOS does not use systemd, given how its too main usecases (mobile use as well as server use of repurposed devices) would certainly benefit from a mature service manager. Possibly even if they had to put it on top of Alpine themselves.
pmOS has no intention of moving off of Alpine base, and systemd is still incompatible with musl (or vice versa, depending on which side you're on in the arguement :) ), and OpenRC works well enough for now.
Systemd is a complete solution to a variety of problems with system services under Linux, including user sessions, non-racy session termination, etc.
Other init systems, not so much.
There are no alternatives to systemd, kinda like there are no alternatives to Excel. Some packages solve many of the same problems, but none solve all of them as thoroughly.
The irony it's hard there. SystemD it's the only init system which gave me errors trying to shutdown a machine...
>alternatives to Excel
You are right. Both systemd and Excels are turds. Excel mangled genomics data making it unusable and forcing scientists to rename sequences in order to not clash with Excel's internal names. That's utterly crap and a severe step backwards from scientists from the 90's used to be around Unix/GNU-Linux envs where they were utterly free to name whatever thing in almost any way they wanted.
Same systemd often hang at shutdown and I cannot be bothered to understand why.
My biggest issue with systemd is the log system. It is so stupidly slow, that I don't think it is possible to make it that slow without purpose. It literally takes minutes to grep though logs on any of my machines with journalctl.
In fact it is so slow. It is faster to first eat the few minutes to extract the logs into a text file. Which I can then grep through in milliseconds.
Oh and the raw text file takes less space than the systemd log database!
I had to get an intern to basically live in the server room and look for screens saying "stop command for user 1001 waiting 30 seconds... 90 seconds..." etc. and power cycle the machine. It's ludicrous.
I mean, you (or somebody) need to write a short bash script for each service on sysv, and adding cgroup management to that isn't particularly hard. I just never understood how people find that more complex than a huge mess of unit files that transpile down to God-knows-what, but apparently people do.
The user services systemd offers are legitimately cool (though shepherd does it better), I've just never personally understood how people find it "simpler" as a system service manager.
But I still don't get it; have you ever _seen_ a complete init script? These things are hundreds of lines long if you want to account for stuff like PID management and restart capability and isolation.
And you have to do that for every service on your system. And they are not even really portable.
The irony is that a lot of the boilerplate from both, including that massive case...esac part, has been eliminatable for about 10 years. See https://unix.stackexchange.com/a/480897/5132.
These are not "recent" at all, which is part of the problem. The wiki page largely froze in 2010, several years before the init-d-script innovation; and the people maintaining the nagios script until around 2018 never even tried to make use of init-d-script.
It might well be that most of the boilerplate is a "solved problem" - then the question becomes; is this solution used at all? Let's have a look at a recent init file, from current Debian. I again just picked the first thing that I found, which was the openldap package:
This init file too is over 200 lines long. I don't know how much of this is avoidable boilerplate, but evidently the Debian package maintainers either don't know about it or they lack the resources to implement it.
Okay. Would you mind explaining how you set up dependencies between the various services if you don't use the "LSB dependency nonsense"? What does Slackware use for that?
You write the shell commands that start them in the order you want them started in and run that from your rc system. I stg I have no idea why people find this so hard.
Several dozen unit files whose dependencies need not be listed in the files themselves, you mean. Which is why it's a step backwards in terms of simplicity.
You get the dependencies just like you do with any other socket activation. Web request starts the web server, which connects to and starts the application server, which connects to and starts the data store.
> Several dozen unit files whose dependencies need not be listed in the files themselves
Where else would you expect to declare the dependencies other than the file which defines the service? That's where I would expect to find (and add) the dependencies.
> You get the dependencies just like you do with any other socket activation. Web request starts the web server, which connects to and starts the application server, which connects to and starts the data store.
The guix people wrote it a few years ago to make Gnome work better.
Personally I still think "who is logged in to this TTY?" has been a solved problem for a long time now, but apparently that wheel just had to be reinvented in the 2010s.
I'm pretty happy with Systemd these days, and in some ways I don't mind the way it has 'standardized' (read: dominated) Linux stacks. But I'm glad that people are still doing the work to keep OpenRC viable and integrating it into a full-featured, long-lived, relatively popular distro.