On 30/05/13 11:19, Marc Haber wrote:
> On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery <r...@debian.org>
> wrote:
>> Using an imperative language for a descriptive purpose is a bad mismatch
>> of tools and has been ever since the practical effect of init scripts has
>> become fairly standardized.
>
> Some init scripts in Debian build dynamic configuration before the
> daemon is started. It has grown to be an important part of conffile
> and configuration management for software that cannot by itself read
> its configuration in snippets from a foo.conf.d directory.
>
> I am not sure how we would handle that in a "descriptive" approach.
My preferred answer is "give the daemon better configuration handling,
so you can get maximum benefit from having a declarative init", but if
that isn't an option:
systemd:
ExecStartPre=/usr/share/myservice/hack-up-the-config.sh
ExecStart=/usr/sbin/myservice
Upstart:
pre-start script
# entirely untested, but [1] suggests that this might be right?
/usr/share/myservice/hack-up-the-config.sh || { stop; exit 0; }
end script
script
/usr/sbin/myservice
end script
Or keep using a legacy sysvinit script (they'll have to remain supported
for quite some time, at least in runlevels 2-5, for LSB if nothing
else), or wrap the daemon in a shell script that does some initial setup
and eventually exec()s the real daemon (like openarena-server).
Perhaps your favourite package can't derive much/any benefit from a more
declarative init, but I would guess that 90%+ do. That's still a
significant reduction in the number of lines of shell script boilerplate
in the distribution :-)
S
[1]
http://upstart.ubuntu.com/cookbook/#stop-a-job-from-running-if-a-pre-start-condition-fails
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a738eb.9040...@debian.org
