On Mon, 15 Sep 2025, Steve Litt wrote:
>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.
>
Heh, it's mostly inspired from apache2 and other modulable software.
>>
>>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!
>
You can have a conf template, which ease the daemon writing process.
Peculiarities goes into the script file, and the conf file contains standardized
variable (log, debug, options...).
>>
>>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?
>
The `-b' flag, from the man file:
# -b argv0
# argv0. Run prog with argv0 as the 0th argument.
The log/run file has to handle logging, thus if disabled you `cat' whatever
content to /dev/null. mpd-log-null would show up somewhere, I guess.
>
>>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.
>
Not having any dots solve logging in my case. So I'll leave it as that.
>>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.
>
To be clear, pipewire isn't the issue. The issue are the multitude of daemon
that depends on the sound server running. `pipewire-pulse' is just a translation
layer for DE written with pulseaudio in mind.
Cheers,
Ludovic