Florian Zieboll <f.zieboll@???> writes:
> Simon Hobson <linux@???> wrote:
>> Florian Zieboll <f.zieboll@???> wrote:
>>
>> > Seriously, what else besides dependencies on other daemons that
>> > have to be running and some testing for the existence of certain
>> > (everything is) files would be necessary to pass to a parser
>> > script, which could be packaged with the respective init system?
>>
>> Are we in danger of removing one of the great benefits of the shell
>> scripts used by sysvinit - the ability to code pretty well anything
>> that's needed. I realise that this also means the scripts can tend to
>> "sprawl", but it gives great flexibility - including for local
>> modifications.
>
> hallo simon,
>
> i was not talking about replacing sysvinit's shellscripts, but suggest
> to implement a routine that creates them "on the fly" on installation
> of a new daemon, from /one/ init-independent "meta" configuration file,
> packaged with the daemon.

What's "a daemon"? Eg, certain machines I'm dealing with do all of
their internal communication over a set of ssh-based VPNs. Example
start command:

   starting "quicksand VPN" \
    daemon -n chdir / monitor -n qvpn ssh-vpn mes-pgsql 5000 quicksand quicksand4

This already involves running 5 different program. ssh-vpn is a shell
script whose final command looks like this:

exec multi-cmd \
    monitor -n "${vtun}-t" chids -u "$user" ssh -n -N -L $lport:127.0.0.1:$rport "$host" \; \
    monitor -n "${vtun}-v" vtund -f "$cfg" -n "$vtun" 127.0.0.1

[In my experience, this combination works reliably while ssh alone
doesn't]

There are 4 more program here. None of them 'is' the server/ daemon, all
9 work in concert to provide a service in a certain way. With the
exception of ssh and vtund, these are all program written by me but
that's not necessarily so. And no 'package' not specifically created for
this use case could provide the meta-information needed here.