On Thu, May 30, 2013 at 12:32:59PM +0100, Simon McVittie wrote:
> On 30/05/13 11:19, Marc Haber wrote:
> > On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery <rra@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
While you could do it this way, I think it would be better to do this:
pre-start exec /usr/share/myservice/hack-up-the-config.sh
exec /usr/sbin/myservice
No need to use 'script' if you're just running a single command (that just
forks a shell uselessly). And for a pre-start that's not expected to fail
in the normal case, there's no need to worry about a "clean" stop of the job
from the pre-start; the only difference this makes is to whether upstart
tries repeatedly to start the job and hits the respawn limit, or whether the
job is stopped immediately when there's a failure. So that's a trade-off
between a little bit of extra log spam, vs. spawning an extra shell.
> 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).
Yes. A lot of the people expressing concern about being forced to migrate
to non-sysvinit seem to be overlooking the fact that both upstart and
systemd provide backwards-compatibility for sysvinit scripts. So changing
the default init comes with no obligation on maintainers to write
configuration files for the new thing before they're convinced of its
utility.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature