[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian systemd survey



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

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


Reply to: