The officially official Devuan Forum!

denk_mal

Member

Registered: 2017-12-01

Posts: 9  

runit scripts

I am using runit as init system but it seems to me that for now it is only a binary replacement for the sysvinit binary because the init.d/* scripts are executed as before. So I have started to replace them with real runit scripts.

I am using for now the debian scripts from Lorenzo Pulit
(https://salsa.debian.org/runit-team) as base for my devuan system.

• Are there other, more devuan like sources for runit scripts?

I noticed that the runit stage 1 is based on the execution of rcS.d/* what looks ok for me.

• Will runit stop if some of those initscripts will fail?

• Does it make sense to implement real runit stage 1 scripts?

in the runit stage 2 every run script should check for depencies. sysvinit scripts contains a LSB header for facility. A sysvinit script could contain for example a $syslog facility that is resolvable with rsyslog or socklog.

• what is the best way to transfer this to a runit init script?

• Is it necessary to check for LSB facilities?

• is it necessary to check for any possible facility e.g. that rsyslog has started OR socklog has started

• or is there a common way to check for e.g a started $syslog daemon indepentely from the real installed syslog daemon?

And especially for $syslog; Is it necessary to check for it if there is a log/run script for the service?

---

Linux - be root
Windows systemd - reboot

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: runit scripts

I don't know the answers to most of your questions, but there's a link to additional runscripts in this post:
https://dev1galaxy.org/viewtopic.php?pid=27300#p27300

I think these are the two main discussions of runit on our forum:
https://dev1galaxy.org/viewtopic.php?id=3716
https://dev1galaxy.org/viewtopic.php?id=3628

denk_mal

Member

Registered: 2017-12-01

Posts: 9  

Re: runit scripts

Hi fsmithred,

thanks for your answers.

I don't know the answers to most of your questions, but there's a link to additional runscripts in this post:
https://dev1galaxy.org/viewtopic.php?pid=27300#p27300

This is the place where I found most of the answers and urls

I think these are the two main discussions of runit on our forum:
https://dev1galaxy.org/viewtopic.php?id=3716
https://dev1galaxy.org/viewtopic.php?id=3628

I even read them, too but there is very less informations about the runit scripts.
On the internet I found this https://github.com/cloux/aws-devuan/issues/1 but unfortunally the repos from cloudx are not longer valid.

I will try to take a look into the scripts from void linux for now.

Last edited by denk_mal (2021-05-26 07:21:22)

---

Linux - be root
Windows systemd - reboot

Lorenzo

Member

Registered: 2020-03-03

Posts: 46  

Re: runit scripts

On the internet I found this https://github.com/cloux/aws-devuan/issues/1 but unfortunally the repos from cloudx are not longer valid.

try here
https://github.com/cloux/runit-base/tree/master/etc/sv

I noticed that the runit stage 1 is based on the execution of rcS.d/* what looks ok for me.

    Will runit stop if some of those initscripts will fail?

    Does it make sense to implement real runit stage 1 scripts?

As long as we use sysv's initscripts for boot it works exactly as in sysv: if something is really broken during boot you'll get an emergency shell, otherwise it will spit error messages on the console and try to proceed with the boot sequence.
Implement a set o runit boot-scripts is very low priority on my TODO list simply because the advantages are very few compared with the risk of regression. The amount of work required to have a runit boot-scripts that is on par with initscripts (works on several setups and all Debian arch, including non linux kernels) is too high and I'm focusing my work on other areas where with the same amount of work users will get far more concrete advantages.
Downstream like Devuan can use the BTS to request me to adjust the dependency in a way that makes it easier to experiment with their own set of bootscript, I would consider that a valid bug.

in the runit stage 2 every run script should check for depencies. sysvinit scripts contains a LSB header for facility. A sysvinit script could contain for example a $syslog facility that is resolvable with rsyslog or socklog.

    what is the best way to transfer this to a runit init script?

    Is it necessary to check for LSB facilities?

    is it necessary to check for any possible facility e.g. that rsyslog has started OR socklog has started

    or is there a common way to check for e.g a started $syslog daemon indepentely from the real installed syslog daemon?

Right now there is no such thing as facilities in runit (another valid bug on BTS). This on is on top of my TODO list and I need to sort it out before uploading the runit-services package. Runit doesn't need all sysv facilities, but it needs a facility when there are 2 or more alternative runit services that have to be checked for dependencies. Syslog is an excellent example.

And especially for $syslog; Is it necessary to check for it if there is a log/run script for the service?

Services that can log to stdout and use svlogd don't need to depend on syslog; same for services that have their own log system (like apache2). Simple rule of thumb: if there is a log/run that execs svlogd you don't need to depend on syslog.

Lorenzo

denk_mal

Member

Registered: 2017-12-01

Posts: 9  

Re: runit scripts

Hi Lorenzo

try here
https://github.com/cloux/runit-base/tree/master/etc/sv

Thanks for the hint. I have cloned the repo and have taken a (deep) look into it.
I will change some things because it is perfect for cloud and container environments where the vm is often destroyed and recreated but is IMHO not perfect for real servers/desktop. E.g. every initscript is (re)reating the symlink from /etc/init.d/* to /bin/sv what is something that should be done by a debian package or a separate install script.

As long as we use sysv's initscripts for boot it works exactly as in sysv: if something is really broken during boot you'll get an emergency shell, otherwise it will spit error messages on the console and try to proceed with the boot sequence.

So it is still best practice to check for all necessary depencies.

Implement a set o runit boot-scripts is very low priority on my TODO list simply because the advantages are very few compared with the risk of regression. The amount of work required to have a runit boot-scripts that is on par with initscripts (works on several setups and all Debian arch, including non linux kernels) is too high and I'm focusing my work on other areas where with the same amount of work users will get far more concrete advantages.
Downstream like Devuan can use the BTS to request me to adjust the dependency in a way that makes it easier to experiment with their own set of bootscript, I would consider that a valid bug.

Yep, I totally agree with you. If stage 2 is working perfectly it may be time to step forward to change stage 1 and stage 3.
And stage 2 can be implemented as a separate independed debian package while stage 1 and stage 3 changes affects the runit debian package.

Right now there is no such thing as facilities in runit (another valid bug on BTS). This on is on top of my TODO list and I need to sort it out before uploading the runit-services package. Runit doesn't need all sysv facilities, but it needs a facility when there are 2 or more alternative runit services that have to be checked for dependencies. Syslog is an excellent example.

Even systemd has not a perfect solution for this problem; it still needs HI instead of KI.

Services that can log to stdout and use svlogd don't need to depend on syslog; same for services that have their own log system (like apache2). Simple rule of thumb: if there is a log/run that execs svlogd you don't need to depend on syslog.

Ahh, fantastic because this means there is a daemon independed way to administrate logfiles for different services to different locations. This is very useful on low memory mashine where I can pick only those log that I really need.

Thanks again for your explanations and your excellent work on the debian runit-script package.

---

Linux - be root
Windows systemd - reboot

denk_mal

Member

Registered: 2017-12-01

Posts: 9  

Re: runit scripts

Hi,

i am using runit as init service and have running some service as 'core' runit scripts now.

I had some issues with the runit version in devuan (2.1.2-25) which have been fixed with 2.1.2-40
So I have installed the version 2.1.2-40 (from the antix repo) and found a behavior thats sound silly.

When I install a new service (e.g. update-service --add cron) that contains a log part then the link for the supervise folder
(e.g. log/supervise linked to /run/runit/supervise/cron.log) will be deleted and replaced by an (empty) supervise folder.

All fiiles (control, lock, ok, pid, stat, status) will stay in the /run/runit/supervise/cron.log folder and the newly created
/etc/sv/cron/log/supervise folder is empty. I can delete those folder and recreate the link but on the next reboot it will be reverted.

This doesn't happen to the supervise link of the service itselfs. (e.g. /etc/sv/cron/supervise will be linked to /run/runit/supervise/cron
and is not changing)

Where can I set the basefolder for the supervise folders for logs so they will work  as the supervise folder of the services itselfs?

EDIT: I got the runit version from bullseye (also 2.1.2-40) and it is the same behavior.

Last edited by denk_mal (2021-06-16 13:14:51)

---

Linux - be root
Windows systemd - reboot