Dear Maintainer,

The daemontools-inspired family of supervision suites typically share the
ability to emulate some subset of the daemontools tools with compatible
behaviour.

For example, chpst from runit can emulate envdir, envuidgid, pgrphack, setlock,
setuidgid and softlimit.

Similarly, run scripts for daemons using these suites, if they don't take
advantage of features unique to those suites, may be compatible between them.

In practice, that compatibility is limited because of features included in
distributions, such as runit service directories in Debian typically using
/usr/lib/runit/invoke-run to perform some standard actions. However, third
party-provided service directories especially may well stick to the basics. The
debian package 'publicfile' is compatible with daemontools and runit
supervision.

Ideally someone writing a run script that only needed the behaviour of
'setlock' would simply call 'setlock', for example. However, that would
mean unnecessarily depending on the daemontools package when your
service might be running with runit that already has 'chpst' installed,
and so will be written to use 'chpst -l' instead.

We can fix this by installing all the common tools using the Debian
'alternatives' mechanism. This is very lightweight - symlink traversal is
extremely cheap in Linux.

I attach a patch for daemontools that does this. For simplicitly it groups
together all the tools that 'chpst' can emulate (headlined by the 'envdir'
tool), but theses could be split into a different alternative for each tool if
one wanted that granularity. An additional group just contains 'fghack', which
my 'xchpst' tool can also emulate.

I also attach example patches for the 'runit' and 'xchpst' packages to show how
this could work.

Here is some example output:

  # sudo update-alternatives --config  daemontools
  There are 3 choices for the alternative daemontools (providing /usr/bin/envdir).

    Selection    Path                 Priority   Status
  ------------------------------------------------------------
    0            /usr/bin/envdir.djb   50        auto mode
    1            /usr/bin/chpst        30        manual mode
    2            /usr/bin/envdir.djb   50        manual mode
  * 3            /usr/bin/xchpst       40        manual mode

  Press <enter> to keep the current choice[*], or type selection number: 1
  update-alternatives: using /usr/bin/chpst to provide /usr/bin/envdir (daemontools) in manual mode

The presence of alternatives will also help developers trying to compare
behaviours across different toolsets.

What do you think about this idea?

Andrew

Hi Andrew,

Thanks for your nice bugreport + patch.  In runit's chpst(8) I read:

   If chpst is called as envdir, envuidgid,  pgrphack,  setlock,
   setuidgid,  or  softlimit,  it  emulates the functionality of
   these programs from the daemontools package respectively.

Doesn't this mean that daemons which ship daemontools-style run scripts work
out of the box under runit?  Or am I missing something here?

Bye,

Joost

They could do with these patches :-)

The issue is that the runit package cannot ship chpst linked as
/usr/bin/envdir, etc. because that would clash with the daemontools
package. The options are (1) Conflict with daemontools, (2) Use
'alternatives' to be co-installable.

I prefer the idea of being co-installable because it helps users and
developers experiment with different toolsets, compare differences in
behaviour, etc. Also there's sometimes not 100% overlap/superset/subset
as appropriate between what different packages can do.

And the nice thing about using alternatives is that chpst doesn't even
have to set up the symlinks itself, as the alternatives debhelper does
it as part of the alternatives definition.

The not-so-nice part is that the main package that 'owns' those names
has to rename them, but it works out fine for the user.

A, makes sense; thanks for this explanation.  I'll wait for Jan Mojžíš's
opinion: he's done most of the work on the daemontools packaging.

Bye,

Joost

Great! If Jan agrees in principle then before committing the change I
think it is worth thinking about what the best user experience would be
for grouping the tools together.

Pros for bunching them together

+ easier to switch in or out the whole bank
+ slightly less boilerplate in dh_installalternatives control files

Pros for tool-by-tool alternatives

* handles incomplete suport (e.g. chpst cannot yet [1] emulate fghack)
* lets more packages with varying range of tools join in the fun, e.g.
  s6.
* avoid confusion of needing one arbitrary tool to be the 'main' one

I have a hunch it might be best to do this on a tool-by-tool basis. I
don't mind reworking the patch if this is desired.

[1] https://github.com/g-pape/runit/pull/23

Hi Jan,

Do you have any thoughts on this idea?

I also note that fghack support for chpst has today been merged into
runit's git branch for a future release (although the fghack command is
not yet emulated by it)!

Andrew

Hi,

For the `daemontools` package, this would mean renaming shipped binaries and their manpages to implementation-specific names (as in the patch), e.g.:

* `/usr/bin/envdir` → `/usr/bin/envdir.daemontools`
* `/usr/bin/envuidgid` → `/usr/bin/envuidgid.daemontools`
* `/usr/share/man/man8/envdir.8.gz` → `/usr/share/man/man8/envdir.daemontools.8.gz`
* `/usr/share/man/man8/envuidgid.8.gz` → `/usr/share/man/man8/envuidgid.daemontools.8.gz`

The generic command names (e.g. `envdir`, `envuidgid`, etc.) could then be managed via `update-alternatives`.

For the `daemontools-run` package, this could allow dropping `Conflicts: runit`.

I’m not opposed to this approach, but it would need careful testing to avoid breaking existing setups, including updating autopkgtests that cover daemontools and runit combinations.

Jan

Hi,

For the `daemontools` package, this would mean renaming shipped binaries and their manpages to implementation-specific names (as in the patch), e.g.:

* `/usr/bin/envdir` → `/usr/bin/envdir.daemontools`
* `/usr/bin/envuidgid` → `/usr/bin/envuidgid.daemontools`
* `/usr/share/man/man8/envdir.8.gz` → `/usr/share/man/man8/envdir.daemontools.8.gz`
* `/usr/share/man/man8/envuidgid.8.gz` → `/usr/share/man/man8/envuidgid.daemontools.8.gz`

The generic command names (e.g. `envdir`, `envuidgid`, etc.) could then be managed via `update-alternatives`.

For the `daemontools-run` package, this could allow dropping `Conflicts: runit`.

I’m not opposed to this approach, but it would need careful testing to avoid breaking existing setups, including updating autopkgtests that cover daemontools and runit combinations.

Jan

Hi Jan,

Thank you for reviewing the proposal!

I am happy to add DEP-8 tests; I will look into it.

At present we can't combine 'daemontools-run' and 'runit' because of the
conflict with an update-service binary (see my comment on your thread on
Salsa[1]). This can be solved by moving the binary from the runit
package to the runit-run and runit-init packages.

But we can test 'daemontools' with 'runit-run' and deconflicting the
others can be done as a separate consideration.

Andrew

[1] https://salsa.debian.org/debian/daemontools/-/issues/2#note_729771