Ludovic Bellière via Dng said on Mon, 15 Sep 2025 09:08:53 +0000

>Hello,
>
>A bit of feedback after setting up my local runit based on the howto.
>
>First thing is the usage of directories and their names. I settled on:
>

>       mkdir -p "${HOME}/runit.s/"{active,disabled,bin}

>
>The `bin' directory is there to host the various helper scripts needed
>to run runit itself, such as `svl' and `runsvdir_user'.
>
>The `disabled' directory is there to host the daemon files that are
>not yet active.
>
>The `active' directory is the reverse: contains symlinks to the stuff
>present in the `disabled' directory.

What you describe is a great way of doing it. It's probably an
improvement over what's on the website.

>
>- - -
>
>For each service:
> * a conf file (sh format), contains variable for both the
> service/run file and the service/log/run file.
> * a log sub-directory containing a `run' file.

Everyone but me uses a conf file. I don't like them. I'd rather just
put the variables in the run script, and perhaps repeat them in the
finish script. But people including djb and the author of Runit agree
with you!

>
>Example content of the log/run file:
>
>--8<---------------cut here---------------start------------->8---
>#!/bin/sh
>
>[ -r ../conf ] && . ../conf
>

>if [ "${LOGGING_ENABLE}x" = "1x" ]; then
>     # Create the log directory if not exists.
>     [ -d "${LOG_DIR:-}" ] || mkdir -p "${LOG_DIR:-}"

>

>     exec svlogd -tt "${LOG_DIR:-}"
>else
>     exec chpst -b mpd-log-null cat >/dev/null
>fi
>--8<---------------cut here---------------end--------------->8---

Very nice! I plan to write about logging in the next few days, and this
looks like a great way to do it.

I'm not familiar with the preceding use of chpst. Does the chpst -b
cause the string "mpd-log-null to appear in the log file?


[snip]

>On the website, it is specified to exec runsvdir with dots appended to
>the command[1]. That didn't work for me: runit complained with: "log
>must have at least seven character."[2]. Removing the 'Log: ...' part
>solved my issue.

:-) I too got that message once, and reducing the number of dots fixed
the problem. I think it gives that same error message if you have *too
many* dots. I think 350 dots would be supported in most cases.

>runit doesn't support dependencies. However you can delay the start of
>a daemon by checking the status of whatever it needs. Returning with
>an error will tell runit to wait before retrying, until timeout. For
>example, using pipewire-pulse that requires pipewire, the
>pipewire-pulse daemon will exit with 1 until pipewire is available:
>
>--8<---------------cut here---------------start------------->8---
>#!/usr/bin/env sh
>
>svl check pipewire > /dev/null || exit 1
>
>[ -r ./conf ] && . ./conf
>
>exec chpst -U user:pipewire pipewire-pulse ${OPTS:-} 2>&1
>--8<---------------cut here---------------end--------------->8---
>
>The annoyance is that the service will fail to start without saying
>why.

Hopefully that situation doesn't last long. If it does, then an
underlying problem, probably with Pipewire, must be solved. For a
diagnostic you could log an svl status pipewire and look at the results.

>On the examples given on the bottom of the page, fetchmail only
>doesn't require a supervisor. It exists as a mature daemon capable of
>handling itself painlessly. You can run it as a daemon and send a
>`kill -s SIGUSR1' to it in order to force a poll. If you still want to
>have runit supervise it, then use the `--nodetach' flag in addition to
>`--daemon <interval>'. No dirty infinite loop required. But really,
>fetchmail manages its own pid file and will refuse to start if it
>somehow still exists. Which may be helpful when it doesn't stop
>cleanly.

For 20+ years I was running it as a daemon, using usr1 and usr2. All I
can tell you is life got easier, and debugging got easier, when I moved
the loop to a shellscript. The other thing is, I *really* don't like
relying on PID files, and my personal Runit eliminates that need.

But yeah, I had to actually add about 40 lines of ksh infrastructure to
do everything including guarantying that downing the daemon would let
it finish one trip through all my mail collection, and I think the
daemon does that on its own.


>That's about all I could think off. I hope whatever I wrote can be of
>help.

It does help, and it will be even more helpful as I flesh out this
page, especially about logging. Also if and when I implement Pipewire,
which as I mentioned is very difficult on Void Linux.

>[1]:
>https://www.troubleshooters.com/linux/init/normal_user_runit.htm#makerunsvdirrunner
>[2]: https://github.com/g-pape/runit/blob/main/src/runsvdir.c#L141

Thanks!

SteveT

Steve Litt

http://444domains.com