Skip to main content ↑ ↓
Topic: Which Do You Prefer - OpenRC, s6, or runit?? (Read 49848 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #15 –
Wikipedia has a good overview and history.  google on "linux init vs runit s6 openrc -systemd" for more comparisons.
Linux is fun!  Artix + MX + Puppy + Tinycore + Mint @ home; embedded + Ubuntu + RHEL @ work.
Artix rolling no-systemd + XFCE ISO (thank you!) + MX tweaks + goodies = Heaven!

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #16 –
I have tried s6, runit, and openrc.

OpenRC allows you to configure `need`, `want`, `after`, and `before`. Without `want` directive, there is going to be a lot of hassle.
`after` and `before` are not very important. However, OpenRC needs services to go background and produce PID files. This is no good.
OpenRC still retains /etc/inittab which is awful.

runit just hands over the responsibility of dependency management to run script which you write yourself.
So, you can handle `want` directives in run scripts which are just shell scripts.
One problem of runit is that an init service has to constantly check if all dependencies started.
If one of the dependencies permanently failed, the init service would be stuck in a loop.

s6 handles only strict dependencies. With s6, you have to compile database. Compiling database is a nuisance.
OpenRC automatically creates its own database cache. I also don't like the fact that dependencies are a file in s6. Dependencies file and lack of want directive create aggressive conflicts over dependencies among administrators and different init services. Dependencies should be a directory instead. s6 should acquire want directive. Anopa is better than s6, but it is dead.

None is excellent in my experiences. But, I think I am going to try runit again. With runit, it's at least easy to write my own scripts and deploy them.

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #17 –
Quote from: MilkCow – on
s6 handles only strict dependencies. With s6, you have to compile database. Compiling database is a nuisance.
OpenRC automatically creates its own database cache. I also don't like the fact that dependencies are a file in s6. Dependencies file and lack of want directive create aggressive conflicts over dependencies among administrators and different init services. Dependencies should be a directory instead. s6 should acquire want directive. Anopa is better than s6, but it is dead.

Ι am not sure if you are referring to s6-rc (which is what artix uses) or s6 :(
anopa is build on top of s6, it is quite different from s6-rc and seems abandoned. Some of the missing functionality of s6-rc (optional dependencies) can be done on top of s6-rc and the same is true for the compiled db creation. Of course optional dependencies (wants) will be enabled when the service is enabled an not on runtime. The above is not theoretical - 66 does them (and more) already.
 

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #18 –
Quote from: mobinmob – on
Ι am not sure if you are referring to s6-rc (which is what artix uses) or s6 :(
anopa is build on top of s6, it is quite different from s6-rc and seems abandoned. Some of the missing functionality of s6-rc (optional dependencies) can be done on top of s6-rc and the same is true for the compiled db creation. Of course optional dependencies (wants) will be enabled when the service is enabled an not on runtime. The above is not theoretical - 66 does them (and more) already.

I still can't differentiate s6, s6-rc, and s6-linux-init. Is there a way to make 66 work without writing a lot of code on artix linux?
By the way, I don't like the name 66 because it reminds me of 666, a symbol of devil.

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #19 –
Quote from: MilkCow – on
I still can't differentiate s6, s6-rc, and s6-linux-init. Is there a way to make 66 work without writing a lot of code on artix linux?
By the way, I don't like the name 66 because it reminds me of 666, a symbol of devil.


s6 is  process supervision suite. That is a suite of tools that can reliably and cleanly start, stop, monitor and restart long-running programs/services/daemons. It is analogous to runit sans the runit-init part.
s6-rc is a service manager. That is a suite of tools that builds on s6 and adds a lot of features. Artix uses s6-rc+s6-linux-init and refers to the solution as s6.
s6-linux-init is a project that creates the missing pieces to use s6 or s6-rc as full init systems.
66 is a set of programs that make implementation and control of s6/s6-rc services easier and adds some really nice features to them.
It should not be difficult to use 66 on artix - both obarun and artix are based on arch, but it will need some work. Ι am using it on voidlinux :)

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #21 –
I prefer runit. Much simpler than the others and faster, at least on my computers. Greetings.
Free the world from the evil software called systemd.

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #23 –
About S6

 s6/s6-rc vs systemd, or why you probably do not need systemd
https://forums.gentoo.org/viewtopic-t-1105854.html

I should add one thing: S6 works well within Docker.
it can replace supervisord

S6 Made Easy, with the S6 Overlay | Tutum Blog
https://tutumcloud.wordpress.com/2015/05/20/s6-made-easy-with-the-s6-overlay/

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #24 –
Quote from: Everyone – on
From my experience:
  • OpenRC works great on a desktop system where no service/deamon monitoring is needed (no support for restarting crashed programs out of the box).
  • Runit is better suited for running for servers/power users.
  • Never came in contact with S6, can't say.
Programs should not crash in the first place (eg pulseaudio :))

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #25 –
I can work with openrc & sysv-rc but know nothing about s6 or dinit.
Before i install i install artix with s6 or dinit i must understand it.
How do i enable & disable services to be run or not run at boot with s6 or dinit?
What are possible advantages of s6 or dinit ?

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #26 –
Quote from: MilkCow – on
I have tried s6, runit, and openrc.
...
None is excellent in my experiences. But, I think I am going to try runit again. With runit, it's at least easy to write my own scripts and deploy them.

I know this post is old, but I just wanted to point out that dinit addresses every negative that you mention:
  • supports both "need" and "want" dependencies (as well as "before" and "after", just like OpenRC)
  • doesn't require services to go into background or mandate use of pid file - can supervise foreground processes
  • doesn't use inittab
  • doesn't need recompilation of service database - just edit the service descriptions
  • ability to configure dependencies via a directory (
    Code: [Select]
    waits-for.d
    directive, one dependency per file in the directory)

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #27 –
Quote from: devosalain – on
How do i enable & disable services to be run or not run at boot with s6 or dinit?

https://wiki.artixlinux.org/Main/S6
https://wiki.artixlinux.org/Main/Dinit

For Dinit the "dinitctl enable" and "dinitctl disable" commands can be used to make or prevent a service run at boot. I'm not actually certain what the recommended procedure is for S6-RC.

Quote from: devosalain – on
What are possible advantages of s6 or dinit ?

https://github.com/davmac314/dinit/blob/master/doc/COMPARISON
https://forum.artixlinux.org/index.php/topic,3498.0.html

I'm the author of Dinit so I'm biased. Here's a description of Dinit from Chimera, which compares it to some other systems:

Quote
The dinit project provides the service manager and init system for the OS. It’s a lightweight, dependency-based (unlike e.g. runit), supervising (unlike e.g. sysvinit) and portable (unlike systemd) system with a good balance of features to simplicity and ease of use/deployment (unlike e.g. s6) and Chimera uses it extensively for both system and user services.

It's also got a reputation for being fast (fast boot times). However, I will say that I personally think S6 is also extremely well engineered and solid.

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #28 –
Indeed Dinit is probably the fastest or at least on tie with runit.

Quote from: davmac – on
For Dinit the "dinitctl enable" and "dinitctl disable" commands can be used to make or prevent a service run at boot.

I switched yesterday to Dinit on my big PC aswell, I had it on testing on the thinkpad for about one year now and been happy with it, so it's an honour and with this occasion I wish to thank you for your work!

I have a question regarding enable/disable and listing of which service is enabled or not: In my utilities script I came up these last few months with a method of going through the dependency chains of the services to see a list of what's enabled, this is meant to complement dinitctl list with a complete overview of sorts:

Code: [Select]
 find /etc/dinit.d/*.d -not -type d -exec grep -E 'waits|depends' {} + | tee >(cut -d= -f2) | cut -d/ -f5 | cut -d: -f1 | sort -u | while read -r s; do echo $s; grep -rlE "waits-for.d.*$s|depends.*$s" /etc/dinit.d | cut -d/ -f4; done | sort -u

Of course this has a caveat: If I run dinitctl disable on a service which is present in the dependency chain of another, it will continue to show up as enabled (which is correct, the service is still running and will still be brought up on boot), however this method has no way of telling if the service is explicitly disabled on not (with my thought going towards e.g. how OpenRC handles it).

Is there a way to force disable a service without having to manually edit it's parent?
Or, to do away with my above method, something like a tree view of the dependencies, or a dependency view per-service (like dinitctl status xyz lists - Activation: start due to dependent(s) - to list which dependent(s) they actually are)?

Re: Which Do You Prefer - OpenRC, s6, or runit??

Reply #29 –
Quote from: Hitman – on
I switched yesterday to Dinit on my big PC aswell, I had it on testing on the thinkpad for about one year now and been happy with it, so it's an honour and with this occasion I wish to thank you for your work!

I'm glad to hear that it's working well for you!

Quote from: Hitman – on
Is there a way to force disable a service without having to manually edit it's parent?

There's not, if the parent specifies the dependency via a waits-for line in its service description file.

If the parent has a waits-for.d directory and specifies the dependency via that, you can use dinitctl disable --from (parent) (service)

Also, if the parent (dependent) doesn't really need a service, it can specify "after =" instead of "waits-for =". This has the advantage that you can just use a standard "dinitctl disable"/"enable" without worrying about the other dependent services.

In summary, it's a question of how the services and the dependencies are defined. There are ways of doing this (user "after =" or "waits-for.d =")  so you can more easily enable and disable services, but the Artix services might not be defined optimally for that.

Quote from: Hitman – on
Or, to do away with my above method, something like a tree view of the dependencies, or a dependency view per-service (like dinitctl status xyz lists - Activation: start due to dependent(s) - to list which dependent(s) they actually are)?

Currently there's not - it would be nice, obviously, so perhaps something I can think about (or someone can contribute!). Right now I'm trying to finalise the features I had already set for the beta release which I hope to get out sometime in the next few weeks, so I don't want to add new features into that mix, but once I've got 1.0 out it will be time to think about what features would still be useful.