Why not use runit? Do you guys use runit?

recklessswing · 2026-06-08 07:30:00

Runit seems fine. I like it. Do you use it on your PC or home servers with Devuan?

Altoid · 2026-06-08 09:25:55

Hello:

recklessswing wrote:

Runit seems fine.

Sure ...
Would not be in the repositories if that were not so.

Sysvinit also seems fine.
Being the default init package in Devuan since my first installation (jesse), it has always been what my systems used.
Other pre-systemd distributions I went through also had it as the default, again with no issues.

I never saw/noticed/came across any problem found to be related to sysvinit.

I cannot see a use case for any other init package.
ie: works as expected out of the box with no issues.

Best,

A.

Camtaf · 2026-06-08 10:47:27

Ditto, been using sysV for many years without any problems, so see no reason to change...

Altoid · 2026-06-08 11:42:19

Hello:

Camtaf wrote:

... sysV for many years without any problems, so see no reason to change.

Indeed.

Like I wrote elsewhere:

Choosing anything other than the default Devuan [ext4] filesystem implies that you are absolutely sure that you have a use case that really justifies your doing so, a second implication being that you are sufficiently versed in the options being considered.
This (quite obviously) also applies to choosing any init package other than the default Devuan [sysvinit], something of a trend in the last few years.
From where I see it, keeping the default options is a basic part of the KISS principle.
ie: if it works as advertised / needed, is adequately supported and has not given you any grief, use the default.
In my case as a 100% Linux user for the last 14 years (the last 8 or so with Devuan), I have never (ever) had any isssues with [sysvinit] or [ext4].

Of course, 'choice' is a good thing to have.
For when it is needed and you absolutely know why you need it.

Not just for the sake of it.

Best,

A.

blackhole · 2026-06-08 17:14:25

I have never needed to use runit or any other alternatives such as OpenRC. Technically both look pretty well designed to me, but the need has never arisen. At home I have always stuck to sysvinit or BSD init. At work I have had to use systemd and write unit files for anything running as a daemon. (would be nice to use one of those there, but it's not worth the trouble).

Personally I think the increased adoption of runit and OpenRC was driven by systemd's anti sysvinit propaganda. Some willingly swallowed this with the added "...but systemd is not the answer" clause. Others utilised it as a means of distancing themselves from the critique being directed at sysvinit in order to undermine it and establish systemd as the de facto standard. Those people who jumped ship and dumped on sysvinit did a lot of the damage in my opinion - they did the devil's work, by word for word repeating sysvinit's supposed deficiencies. Apparently vindicating the systemd cabal in the process.

The harsh reality is that if you're just a desktop user, and not a server admin, you may see no benefits from something like runit, where the main focus is service supervision, except for perhaps slightly faster boot times.

Altoid · 2026-06-08 18:24:22

Hello:

@blackhole: agree on all, good analysis.
Seems we are more or less on the same page.

blackhole wrote:

... if you're just a desktop user ...
... except for perhaps slightly faster boot times.

Yes, perhaps is the right word.

And even then, just how much faster?
5 to 10s (!) less boot time?

Every morning, I switch on my box and go see if my moka pot has finished brewing my coffee.
I'm ready to log in when I sit down, mug in hand.

Best,

A.

Last edited by Altoid (2026-06-08 21:55:24)

blackhole · 2026-06-08 18:54:22

One of the "selling points" often parrotted by systemd fanbois was boot times. I was often told how fast it boots up, and I usually responded with words to the effect that actually it shuts down very quickly. You would gain more from just switching from a hard disk to an SSD if you cared that much about boot time.

All the talk of service supervision and boot times is just a "race to the bottom" against systemd. Stability, simplicity,code correctness, robustness and reliability are worth pursuing. Boot performance and a functionality to babysit and restart equally unreliable crap is not.

Last edited by blackhole (2026-06-08 18:59:27)

Altoid · 2026-06-08 21:57:35

Hello:

blackhole wrote:

Stability, simplicity,code correctness, robustness and reliability ...

Could not have said it better.
+10

Best,

A.

blackhole · 2026-06-09 07:50:41

Service supervision is "real world" crap which enterprise demands. There's a reason why BSD projects don't include it in the base system - the philosophy was always "write your programs correctly, so that they don't crash". Unfortunately people code up stuff that is "good enough". This is because Big Tech don't pay people to sit around fixing bugs or refactoring code.

As an example, enterprise also demands "LTS" Linux kernels - predictable failure - which are no benefit at all to the typical desktop user, which are buggy and only include back ported security parches. You could be fighting with and working around a wifi or display driver problem, for example, that was fixed in the next kernel release, but your distribution of choice went down the "LTS" route - using a kernel intended for the likes of Red Hat. There is "choice" many will say, but unfortunately a good proprtion are quite simply unaware or misinformed.

Last edited by blackhole (2026-06-09 08:05:00)

coder-hase · 2026-06-09 20:44:53

Puh, there's so much to say to this that I do not know where to start.

Stability, simplicity,code correctness, robustness and reliability are worth pursuing.

SysV init is a lot but robust and reliable? No, sorry. It works if rc-scripts play according to the rules of SysV. If they fail (of cause, they are simply not allowed to fail, right? ) the service does not work - bad and no other init system solves that - but the user or admin is the last who learns that because there's no service supervision. The service might also start and fail later for any reason and again, no one takes notice. The logs will not even show an error code.

Service supervision is "real world" crap which enterprise demands. There's a reason why BSD projects don't include it in the base system - the philosophy was always "write your programs correctly, so that they don't crash".

Service supervision is just a modern requirement. I mean, come on, should the system really not try to fix a terminated service by restarting it? Should always an admin be there? What are normal users supposed to do? I also guess there's a reason why BSD is not the chosen Unix for the majority of servers or desktops. And sorry, but from here the mentioned philosophy sound so much like "Trust me bro, I'm a programmer and know what I do". No way.

The harsh reality is that if you're just a desktop user, and not a server admin, you may see no benefits from something like runit, where the main focus is service supervision ...

I fully agree to this. But the other half of that "harsh reality" is that SysV init is something for hobbyist.

Is SysV stable? Yes - which is part of the problem. It's simple: times, expectations and requirements have change since SysV was invented or later introduced to Linux in the mid 90s. It was then a big step forward but it failed to meet evolveing expectations. There is a reason why there were / are so many alternatives to SysV exists. They were no invented for fun but for real reasons.

Simplicity? I don't know. But when you look into one of the init-scripts you see that all scripts source /lib/lsb/init-functions. Doesn't that "feel" wrong? Shouldn't this environment not be provided by some "master" process which runs all the time, very much like pid1 (with or without supervision)? For me, that's a clear sign of bad design. Not bad for the mid 90s but really not good enough for 201x or later.

A problem I remember was (is it still?) that if a service was not configured to automatically start ("START=no" in the defaults file), even root couldn't do this manually from the command line. Thanks to shell scripts that could be changed (check for a tty and ignore the START parameter). But when the runlevel was later changed SysV didn't care about the extra process and didn't stop that. No, it was stupidely processing the links in rc2.d, nmot caring about the actual system status. Not what I would call a super clever solution.

To sum it up: I can easily imagine better init systems than SysV and prefer to do my own stuff and ignore / bypass the system's init system as much as possible. But nowadays I'm also only a hobby hacker.

Btw.: if you use runit (I don't) you might want to take a look at nitro from voildlinux which is (as I understand it) a runit plus some enhancements: https://leahneukirchen.org/blog/archive … runit.html.

Anonymous Goldfish · 2026-06-09 22:02:49

sysvint has worked very well
i have no reason to change it

blackhole · Yesterday 20:41:52

coder-hase, you started out with a put down, followed by a wall of meaningless babble, most of which falls into tl;dr territory. What I can discern is that you haven't understood my post at all. Not interested.

Last edited by blackhole (Yesterday 20:46:47)

greenjeans · Yesterday 21:10:26

Is SysV stable? Yes - which is part of the problem.

Pretty sure that exact same line of incongruous thinking is how systemd got started. And what's wrong in general with Linux these days.

Oh my gosh, can't have stable things just working without breaking, what fun is that? C'mon let's break some stuff, it'll be fun and it's good for people to deal with failure rather than boring predictable behavior, can't have them getting too content and comfortable...nosiree.

*greenjeans most definitely breaks stuff to see what's possible, just not the important stuff*

fsmithred · Today 00:49:30

Since user services seem to be in vogue, I'll mention that runit can be used to supervise user services. You can do this without using runit for the init system.
Here's a howto: https://troubleshooters.com/linux/init/ … _runit.htm

JCK · Today 13:02:50

*greenjeans most definitely breaks stuff to see what's possible, just not the important stuff*

I have that habit too sir!

Wanted to leave this comment yesterday but a bit earlier in the discussion was a remark about service supervision and crashy programs - that is correct i might say, but modern init also brings dependency tree and readiness fd (and few more such not shell friendly ipc things). They were brought by upstart which was quite dubious like systemd but for different reason cause it was designed with desktop in mind, but predates it by a lot, even predates openrc by a year or two.
I would guess they are somewhat useful. Just like how user services are useful in this privilege separated desktop thing that became the norm, don't know when.
Lightweight stuff like puppy replaces sysvinit with busybox but the shell scripts are very similar.

On boot times - maybe systemd was faster when it was new and much slimmer, but as for now i have this modified dinit setup which boots in 1 second (4 seconds with vmlinuz) to the desktop, with nothing too special machine wise.

I personally like seeing things go forward the dinit way and less the daemontools way (for instance s6 compiles it's db, kind of gross). Openrc is a good middle ground here and it looks pretty.

coder-hase · Today 15:29:04

Interesting. Let me follow up on that.

First, thank you, blackhole and greenjeans, for your reply. I noticed that you did not answer the question: What is an admin or user supposed to do if a service fails due to a transient error? How do they know that?

@greenjeans: No, this is not "incongruous thinking". When I get the story right it was like that (feel free to correct me): Around 2000 Linux was the new kid on at the table. HP-UX, IBM AIX, SCO, Sun and yes, Microsoft too were the established names for the server room. You had to persuade your manager to bring Linux. But was still a freaky and nerdy thing made by a group of coder led by some Finish guy. How could that possibly work? But you got the permission. Then the day came where the mail, print, file or web server (or all together) failed. That was clear from the beginning, wasn't it? I mean, what quality can you expect from a bunch of non-professional coders? With good luck they were working for a university (iow: an egghead). Can you even imagine how bad such an admin feels? He then turns to SysV for assistance and what he gets back is like: "Well, you know, the philosophy is that services don't fail". Now Linux does offer great opportunities for everyone, so the admin might have answererd: "Thank you, but I will fork off."

Another question for you:

greenjeans most definitely breaks stuff to see what's possible, just not the important stuff

How do you make the decision what is it important? Or let me ask that otherwise: There was a time before SysV init-style. That was changed (broken?) for SysV. What made this change so extremely good that it seem to hit some optimum, which cannot be enhanced by further changes? Oh, please @blackhole: you might also have suggestion on that. Please let me know.

can't have stable things just working without breaking

Changing is not automatically breaking. There was I time when I asked myself: "How could I change SysV init into something with supervision with minimal (scriptable?) changes to the init scripts?" to have the best of both worlds. But that would things only on the surface.

Thank you, JCK, for mentioning other init-styles. It remembers that the init-space is totally fragmented. Changing / enhancing SysV would only increase that. I'm not suggesting anything like that and I'm really no longer care about init-styles. Instead I started to make my own pidN service controllers that could run with minimal impact below any init-system I find. (If I would have to choose, I think I would take runit: I like its concepts anbd ideas but not so much the implementation.) SysV, systemd, /sbin/init? I doesn't matter. It's pretty easy to configure a single service to whatever the system runs and from that I'm on my own. And in addition to the small footprint, I do not depend on others, their implementation or whatever.

But back to the question above, I would be really interested in how you (all) decide what to consinder to change or update and what not. Because there the difference between bloat and not-bloat starts.

And what's wrong in general with Linux these days.

I agree to that partly. What I think is wrong with Linux is that every program has to have address all (!) possible use cases. Even if they are only useful in years where Easter Monday is on Thursday.

The officially official Devuan Forum!

#1 2026-06-08 07:30:00

Why not use runit? Do you guys use runit?

#2 2026-06-08 09:25:55

Re: Why not use runit? Do you guys use runit?

#3 2026-06-08 10:47:27

Re: Why not use runit? Do you guys use runit?

#4 2026-06-08 11:42:19

Re: Why not use runit? Do you guys use runit?

#5 2026-06-08 17:14:25

Re: Why not use runit? Do you guys use runit?

#6 2026-06-08 18:24:22

Re: Why not use runit? Do you guys use runit?

#7 2026-06-08 18:54:22

Re: Why not use runit? Do you guys use runit?

#8 2026-06-08 21:57:35

Re: Why not use runit? Do you guys use runit?

#9 2026-06-09 07:50:41

Re: Why not use runit? Do you guys use runit?

#10 2026-06-09 20:44:53

Re: Why not use runit? Do you guys use runit?

#11 2026-06-09 22:02:49

Re: Why not use runit? Do you guys use runit?

#12 Yesterday 20:41:52

Re: Why not use runit? Do you guys use runit?

#13 Yesterday 21:10:26

Re: Why not use runit? Do you guys use runit?

#14 Today 00:49:30

Re: Why not use runit? Do you guys use runit?

#15 Today 13:02:50

Re: Why not use runit? Do you guys use runit?

#16 Today 15:29:04

Re: Why not use runit? Do you guys use runit?

Board footer