Skip to main content ↑ ↓
Topic: Yet another runit-rc overhaul (aka. how should we handle stage{1,3} and oneshot) (Read 2229 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Yet another runit-rc overhaul (aka. how should we handle stage{1,3} and oneshot)

Alright. So, runit is a init and a service manager with process supervision, which means it must supervise a process, which makes it less than ideal to run one-shot scripts (e.g. iptables, alsa-utils). It also can only be run on stage 2 (or stage where getty has been setup, etc.), which means we need something else for stage 1 (or sysinit), and stage 3 (or shutdown). As of now, we already have a solution in form of bringing in Arch's old initscript and tailor it to the current situation.

For stage 2 scripts, we have pause from Void Linux which works as a workaround for one-shot services.

And for stage 1 and 3, we have a modifiable sysv-rc style "initscripts". Personally, I have to say I'm not fond of modifiable stage 1 and stage 3 since I think all scripts that we put there has to be essential for startup and shutdown of a system.

However, I do recognize there's a need for "non-essential" (i.e. not needed for boot and shutdown) oneshot services like static internet, and also there's network filesystems, iptables, etc. These need to be run in stage 2, preferably after we run network services.

Therefore, I hereby propose yet another overhaul for runit-rc system.

Currently, we have a sysv-rc style scripts for everything in stage 1. I'm going to change it into a Void Linux-style stage 1. Stage 3 will also get the same treatment.

For remaining one-shot services (e.g. static network, netfs, binfmt, alsa-utils, etc.) The current rc-sv system will most likely be used (and it will be run after we run the runit services), but rc-sv themselves will get yet another overhaul to allow handling true runit services (and to simplify its code). And it's more than likely that we change rc-sv into a better name, like service.

Of course, the old way of ln -s /etc/runit/sv/<service name> /run/runit/service and sv down <service name> will also be supported, but this will make our lives easier.

rc-sv is a semi-documented (no manpages, but there are some barebones help) method of handling sysinit and shutdown. But again as I said it earlier, I don't really like that method.

Since this is a "barebone" announcement, I figured you guys would have questions. Please, ask away. Or, if you have any opinions regarding my proposal, please speak your mind.
now only the dinit guy in artix

Re: Yet another runit-rc overhaul (aka. how should we handle stage{1,3} and oneshot)

Reply #1 –
I'm confused. I personally just use cronie for this kind of stuff. I didn't realize we do it that much differently than void though.

Re: Yet another runit-rc overhaul (aka. how should we handle stage{1,3} and oneshot)

Reply #2 –
Quote from: konimex – on
Alright. So, runit is a init and a service manager with process supervision, which means it must supervise a process, which makes it less than ideal to run one-shot scripts (e.g. iptables, alsa-utils). It also can only be run on stage 2 (or stage where getty has been setup, etc.), which means we need something else for stage 1 (or sysinit), and stage 3 (or shutdown). As of now, we already have a solution in form of bringing in Arch's old initscript and tailor it to the current situation.

For stage 2 scripts, we have pause from Void Linux which works as a workaround for one-shot services.
[...]

Since this is a "barebone" announcement, I figured you guys would have questions. Please, ask away. Or, if you have any opinions regarding my proposal, please speak your mind.

I'm not a runit user and don't know its internals, but can't oneshot scripts be handled by the equivalent of rc.local (if present in runit)? Or, to distinguish from rc.local which is more associated with patchy and temporary startup stuff, make stage 2 execute such scripts when found in a directory, e.g. /etc/runit/oneshot/. I must also say that I don't particularly like the oneshot nomenclature from systemd, I'd prefer oneoff - but then again I'm not a native English speaker.

Re: Yet another runit-rc overhaul (aka. how should we handle stage{1,3} and oneshot)

Reply #3 –
Quote
Therefore, I hereby propose yet another overhaul for runit-rc system.
I am a new user of runit init, but have been using Artix since the beginning (even previous if you include Manjaro Openrc, which brought me here).
I am just wondering how painful this proposed overhaul could be for someone like myself who is not well versed in runit init.
Of course I have the option of going back to the more familiar, (to me) openrc init,
although I am very satisfied with my current system of Artix w/Plasma and runit init.

Best regards.
We should try to be kind to everyone.....we are all fighting some sort of battle.

Re: Yet another runit-rc overhaul (aka. how should we handle stage{1,3} and oneshot)

Reply #4 –
Quote from: Dudemanguy – on
I'm confused. I personally just use cronie for this kind of stuff. I didn't realize we do it that much differently than void though.
There are practically zero differences in stage 2 (and we're certainly not touching it). But how we boot-up (stage 1) and shutdown (stage 3) the system is vastly different from Void. I am going to change it to a simpler approach.

Quote from: nous – on
make stage 2 execute such scripts when found in a directory, e.g. /etc/runit/oneshot/
Yes, it's what I'm aiming for. One-shot service scripts (or initscripts if we're going with sysv-rc-style lingo) will be handled separately in /etc/runit/oneshot or its equivalent, using an OpenRC-like approach so runit itself will no longer handle it through pause. (But I'm possibly going to use some code from FreeBSD's /etc/rc.subr and integrate it to our old /usr/lib/rc/functions since I like the structure.)

(P.S. can we please disable emoticons? I wanted to write something like
Code: [Select]
pause(8)
but the two last characters are always replaced by an emoticon)

Quote from: nous – on
I must also say that I don't particularly like the oneshot nomenclature from systemd, I'd prefer oneoff - but then again I'm not a native English speaker.
Hah. I think it didn't came from systemd at first, but systemd certainly made it popular.

Quote from: conky60 – on
I am just wondering how painful this proposed overhaul could be for someone like myself who is not well versed in runit init.
Of course I have the option of going back to the more familiar, (to me) openrc init,
For me? It'll radically change the structure again. I'll have to write new docs for stage 1 and stage 3. For users? pacman -Syu should be enough once this overhaul is done since from the runit service side nothing is changed. I'm hoping for a flawless transition.
now only the dinit guy in artix

Re: Yet another runit-rc overhaul (aka. how should we handle stage{1,3} and oneshot)

Reply #5 –
Quote

Quote from: conky60  -  16 hours ago
Quote
I am just wondering how painful this proposed overhaul could be for someone like myself who is not well versed in runit init.
Of course I have the option of going back to the more familiar, (to me) openrc init,
For me? It'll radically change the structure again. I'll have to write new docs for stage 1 and stage 3. For users? pacman -Syu should be enough once this overhaul is done since from the runit service side nothing is changed. I'm hoping for a flawless transition.
Thank you for your efforts....and for explaining. :)

Best regards
We should try to be kind to everyone.....we are all fighting some sort of battle.