On Wed, 3 Jul 2019 20:22:42 +0200
viverna <viverna@???> wrote:

> il devuanizzato Steve Litt <slitt@???> il 03-07-19
> 01:09:55 ha scritto:
> >On Tue, 2 Jul 2019 20:28:51 +0200
> >viverna <viverna@???> wrote:
> >
> >> I'm not an expert of Runit and I want ask you how make a service
> >> depend another script not daemon.
> >Hi viverna,
> Hi Steve Litt, thanks for the reply.
>
> >I'm not quite sure what you're trying to accomplish, but if
> I'm playing with runit mainly because I like to study new things and
> because I'd like to have various init system installed in my machine
> and script/config file related for all daemon.
>
> I think that users wants, like me, when they installed a daemon with
> apt and friends script/config file created for all init system
> installed.
>
> Ideally it is possible to make this executing a script on event
> "DPkg::Post-Invoke" and copy script/config file in proper directory.
>
> I have already written a simple posix shell script that works in my
> computer with epoch init system, but I need help because code is
> written in my spare time (very little time) and need coder better
> than me.
>
> Finally for all init system supported there will be:
> - a package for init system (for example runit)
> - a complete collection of script/config file (for example
> runit-init-collection-script) in a proper format
> - above script copy/delete script/config file in the correct
> directory.
>
> I don't know if this can be a feasible solution for to ensure init
> freedom. What do you think?
>
> >If service_required should still be running when my_service starts
> >up, then service_required should have its
> >own /etc/sv/service_required and the symlink in /var/service, and a
> >test should be devised to determine whether service_required is
> >functional. Let's say that test is contained in a shellscript called
> >service_required_is_functional, that returns 0 when the service
> >proves it's functioning, and some other number otherwise (I use 1).
> >Then the run script for my_service looks like this:
> >
> >#!/bin/sh
> >if service_required_is_functional; then
> > exec my_service
> >fi
> >sleep 1
> Very interesting. Simple and useful. I will try your solution as soon
> as I have time available.

Hi viverna,

I have a very different viewpoint than most people, so the following is
*my opinion* and is not in the mainstream.

I think that, for both s6 and runit, run scripts (and any finish
scripts or environment files) should come from a small committee of
runit/s6 experts, NOT from the overworked "upstreams" who created the
software, nor the overworked distro-based maintainers who adapt the
software to the distro. During the Debian-User systemd war, one of the
greatest sources of resistance to multi-initism was "upstreams" and
maintainers who bitched about now having to take care of an extra set
of init scripts.

If each "upstream" simply documents:

1) How to run the software, in the foreground, without excessive
logging.
2) The preferred user and group to run the software.
3) What daemons should already be running before the software.
4) Any special state circumstances necessary to start the software. For
instance:
* Network up
* Such and such file with so and so permissions
* Etc.
5) Any cleanup that must be done after the software finishes or crashes.
6) Any environment vars the software is responsive to.
7) The software's response to any signals.
8) Any special logging the software does all by itself.
9) Does it require a "twin" daemon, like smbd and nmbd, and if so,
which should start first?

Possessing the preceding info, it's easy to make an s6 or runit run
script, finish script, and if necessary environment file. In most cases
only the first 4 are really necessary. If an "upstream" refuses to
answer the questions, the info can probably be gleaned from the
software's systemd unit file.

This list of questions could be sent to each "upstream", and the
answers will almost 1 for 1 correspond to the run script.

The runit package could install tree /etc/runit/scriptdirs and the
directory /etc/sv, and a daemon's (call it mydaemon) install could
include something like the following:

if -d /etc/runit/scriptdirs; then
ln -s /etc/runit/scriptdirs/mydaemon /etc/sv/mydaemon
fi

Uninstalling the mydaemon package would remove symlink /etc/sv/mydaemon.

My method runs counter to the way it's always been done, and I always
get a lot of pushback when suggesting it, but my way would probably
limit resistance from "upstreams" and maintainers, and would not
require those people to become runit and/or s6 experts. Meanwhile, it
would be trivial for a couple runit and s6 experts to write the actual
startup files, based on the "upstream"s answer to a few simple
questions.

SteveT

Steve Litt 
July 2019 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques