OpenRC is a dependency-based init system for Unix-like systems
wiki.gentoo.org
wiki.gentoo.org
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.
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.
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.
Do you have some links to share?
Now working on a replacement to systemd-tmpfiled for OpenRC.
Run these sysvinit, OpenRC and maintain systemd as well at this shop.
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.
??
Mount filesystem, start networking, start networking daemons, update crappy gtk stuff, run rc.local.
What is so complex ?
It was run in the middle of rc, not at the end; as pointed out in the OpenBSD manual.
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.
Into correct imperative sequence. That’s the whole point of declarative things.
You can’t feasibly write it correctly otherwise. You are writing programming languages over assembly for largely this same reason.
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.
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?
As proven by OEM distributions on by gone netbooks, and Android flavours, OEMs will always do what they do best.
In what concerns Windows, unfortunately it appears only Azure, Office and XBox matter now.
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 do think they had commercial aspirations work systemd, but more about "being the company that invented..." Than a direct cash cow.
This is in contrast to the play canonical makes with snaps that has 30% app store tax written all over it.
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.
Cheers: Uberlord.
[EDIT] Took me a while: https://web.archive.org/web/20211120235128/https://roy.marpl...
Personally I just wish it had any notion of logging stdout/stderr, or a way to manage daemons as a user.
[1]: https://github.com/OpenRC/openrc/blob/master/service-script-...
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)
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!)
Cheers from Yeovil.
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.
Through being voted on/carefully chosen based on merit.
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.
OpenRC is closer to systemd than sysv in that regard, though at least it logs sanely
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.
So, a question: why did/do you like using it?
With OpenRC you have unconstained init scrips written in a Turing-complete language.
How exactly is Systemd more complex?
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.
(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.)
See https://lists.debian.org/debian-ctte/2013/12/msg00234.html and https://lists.debian.org/debian-ctte/2014/01/msg00067.html and https://lists.debian.org/debian-ctte/2014/01/msg00358.html and others. To quote Andreas Barth in 2014, months into the discussion, for starters:
> 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.
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.
I finally killed a fedora install 2years unupdated...I quit trying to restore it after an hour and just took my data off
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.
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 :)
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.
[1]: https://forums.gentoo.org/viewtopic-t-1029642-start-0.html
Yes it is possible to change your mind and switch from one to the other after installation, but it's not straightforward.
In the Gentoo kernel make menuconfig there are options for Systemd vs OpenRC - not entirely sure what they do.
To bad that is now out of fashion. If the BSD software was not portable Linux would not have gotten off the ground.
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?
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.
i am working on a implementation of that for openrc for a while now, it's been working nicely so far: https://github.com/OpenRC/openrc/pull/573
I'm not totally sure whether openrc will merge this or not, but I would definitely like to see this be added.
edit: They actually seem to have replied to you while I was writing the original comment.
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.
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've seen a lot of dangling sessions with systemd actually although I'm not sure what the root cause is.
Hint: man systemd.service, look for TimeoutStopSec.
With systemd, this comes out of the box.
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.
Here's one of the first I stumbled upon.
https://github.com/NagiosEnterprises/nagioscore/blob/master/...
It's 288 lines long; the LSB dependency nonsense is 8 lines of that.
Then I looked up one for Postgres;
https://wiki.postgresql.org/wiki/Lsb_conforming_init_script
This one is a whooping 356 lines long, LSB is again about 10 lines long, depending whether you count the header or not.
I don't think the "LSB dependency" argument holds water.
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.
https://packages.debian.org/bookworm/amd64/slapd/download
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.
How'd you do that?
I don't see how this is supposed to be more comprehensible or even "simpler" than a 12 lines unit file.
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.
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.
Fair enough!
We had a nail and all we needed was a hammer, instead we got a hydraulic press.
I know alpine has the inventor of s6 working on a service manager based on that and I have higher hopes for it.
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.