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.

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.

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

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.

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

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.

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

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.

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.

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

thanks for your answers.

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

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.

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 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?