Runit integration for additional services

[plorenzo at disroot.org]

Hi Martin,

Ah, this is gong to be long, sorry in advance

May 30, 2020 7:36 AM, "Martin Steigerwald" <martin at lichtvoll.de> wrote:

> I finally tested how easy it is to switch to runit as init (via package
> runit-init).
> 
> [ ... ]
> 
> I had to do the "Yes, do what I say" thing… but other than that I am
> astonished at how easily this went. There had been *no* issues
> whatsoever. This *just worked*. I certainly did not expect that.

Yes, the '"Yes, do what I say" thing' makes it looks far worst than it is.

> I like that as it makes it easy for me now to switch over some other
> services. I do have one candidate to start with and that is thinkfan.

I won't steal you the fun of writing a runscript for thinkfan, if you
need help ask :)

Just uploaded my personal collection of runscripts [1], there is also a very verbose
template with examples, you can use that for writing new services.
If you're going to try some runscript from the collection let my know how it works,
i need testers!
No, I'm not trying to use you as a lightning rod against bad runscripts, i use many of those
daily and they are candidates for merging into debian, but they lack of testing: just use some
caution and don't assume that they are totally bug free.

> I wonder: If I develop runit integration for some service, how to go
> about it? My current idea is:

An official howto doc does not exists yet, I have it in my TODO list but
i want to complete the dh-runit implementation first.
For now you have to do with manpages and i'd recommend

* only if you're new to runit
  - man runsv(8), man sv(8)

* recommended even if you're a runit expert since the debian implementation 
  is somehow different from other runit distro that i know of
  - man invoke-run(8), man dh_runit(1)

I'm going to ask you to NOT send MR on services that do not support
restarting at runtime ( dbus, sddm, lightdm, slim, any other DM and so),
because there is no code to deal with that in dh-runit, for now.
Also, don't send MR for services that are in the middle of a dependency chain
during boot (like elogind) because that will break the boot order for runit-init users.

Apart form that, there are some recommended (but not mandatory) guidelines that will keep
the runscript clean and will easy my effort in maintaining the integration over time:

DH_RUNIT:

  * if your service log to stdout and has a dedicated log service with svlogd, use the 'logscript' option
    instead of using your own log/run file (the ones that you see in [1] are there for testing only)
  * don't use the 'since=' option

RUNSCRIPT:

  * use the 'invoke-run' interpreter instead of plain sh
  * use a 'finish' file like in [3] instead of a ssh-like one
  * ideally the runscript should test each condition that can lead to a permanent failure in
    the service: if the condition is true do 'sv d .' and exit with an appropriate message/exit code.
    The /lib/runit/finish-default is an attempt to standardize this process.
    If you don't do that in a way or another, runit will restart the service once for second, forever, 
    without giving a clue on what is wrong.
  * Print a 'invoke-run: starting foo' just before the exec line, and check for the VERBOSE option.
    i need that for debug. See the template [4]
  * if the service is capable of logging to stdout, log to stdout and use a dedicated log service with svlogd;
    this is the preferred way for runit services.
    if it can't log to stdout or the service has its own logging system (like apache2) then redirect
    the output from 'run' and 'finish' to syslog, with logger.


TESTING:

  * testing in your pc can be ok for trivial services, i'd recomend to try to restart the system in order to
     test the boot sequence, find reces or similar issues. 
     For complex services some kind of test in a clean environment like a freshly installed VM is a must,
     speaking of which..

  * there is a salsa ci test for runit services but it's from Dmitry account,
    not sure it's still working. Anyway, it's a docker thing, so if your
    service is using some kernel related stuff the test may fail even if
    your service is ok.
    For an example on how to use the pipeline see [2]

Anyway, if you're doing a MR and you have also a bug, CC runit at packages.debian.org ; if you only have a MR on Salsa,
let me know of its existence.

Regards,
Lorenzo

[1] https://salsa.debian.org/runit-team/runscript-collection

[2] https://salsa.debian.org/Lorenzo.ru.g-guest/anacron/-/commit/7b21cdaa7e71ccb4ebe684a333a090f7e82369a

[3] https://salsa.debian.org/runit-team/runscript-collection/-/blob/master/apache2/finish

[4] https://salsa.debian.org/runit-team/runscript-collection/-/blob/master/template/run