BoF Protocol

[Erich Schubert]

Hi,
> Is exec for forking mode and restart for non-forking mode? Just to make
> sure I understand you here.

Kind of. But it's more of a way that "exec" could be used for services
that are non-forking.
respawn is exactly what it says: exec it and restart it when the
process terminates.
exec is just single-shot.

The difference between a mere 'exec' and a 'forking' daemon happens
later on: in an 'exec' mode, you can either assume the service remains
up even when the process has quit (forking mode), or that the service
is complete (init scripts, what is 'up' for hwclock anyway?) - or that
the service has died (in which case dependent services might need to
be terminated as well).
The latter is especially interesting when service restarting is meant
to be handled by other applications. When an 'exec' service goes down,
the init system might issue a "service quit" message to some other
application, which could then e.g. trigger a failover to a backup
system, start an alternative service. Or restart the service according
to some policy.
For example you could set it up to try a new configuration in
single-shot mode and return to the previous configuration after one
service failure within 10 minutes.
(and it is intentional that the admin can s/respawn/exec/)

Usually, services will of course use "respawn" whereas hook scripts
will be "exec".

Another thing: don't rely that in a configuration such as
Exec: foobar parameters
foobar is the actual application. (e.g. testing for it in the
generated init script).

A common setup might be
Exec: nohup somedaemon

In that case, the existence check should be done for somedaemon and
not nohup, obviously.
I'd maybe use syntax like this instead:
Pre-Start-Hook: test -x /usr/sbin/somedaemon

Note that if we at some point end up with an init system which can
actually use our meta-init files directly (or end up at using upstart
syntax), we also can't rely on the file being removed on uninstall,
since it's a configuration file. So it's not sufficient to not
generate the init scripts when the corresponding package is in an
'uninstalled, config' state.

> Ok, but that's an issue with sys-v-init scripts, and we do not plan to
> solve them here. But if you think that any "normal" daemon (i.e., those
> daemons simple enough to use metainit) should have a /etc/default/*
> file, that would be possible of course − just adjust the init script
> generation script. (Current try on [1])

This is maybe even deprecated for sysvinit scripts.
If you require people to modify the service files to disable a certain
service, this means they're more likely to run into an upgrade
conflict. That's well documented in the policy:
---
Often there are some variables in the init.d scripts whose values
control the behavior of the scripts, and which a system administrator
is likely to want to change. As the scripts themselves are frequently
conffiles, modifying them requires that the administrator merge in
their changes each time the package is upgraded and the conffile
changes. To ease the burden on the system administrator, such
configurable values should not be placed directly in the script.
Instead, they should be placed in a file in /etc/default, which
typically will have the same base name as the init.d script.
---
That's another reason why so many packages use /etc/default/foobar for
disabling: the init scripts tend to be changed more often by the
maintainer, and it's nice if people can upgrade without having to
understand a large diff output.

There are many cases where this comes into effect. For example, when
you modify /etc/default/foobar, the changes take effect at the next
restart of the service. With meta-init, you need to run
update-init-scripts afterwards to ensure the changes take effect.

And note that this setup is *very* common, some examples:

/etc/default/apache2:NO_START=0
/etc/default/avahi-daemon:AVAHI_DAEMON_START=1
/etc/default/bootlogd:BOOTLOGD_ENABLE=No
/etc/default/cpufrequtils:ENABLE="true"
/etc/default/cryptdisks:CRYPTDISKS_ENABLE=Yes
/etc/default/dbus:ENABLED=1
/etc/default/mpd:START_MPD=false
/etc/default/nfs-common:NEED_IDMAPD=
/etc/default/nfs-common:NEED_GSSD=
/etc/default/openvpn:AUTOSTART="none"
/etc/default/pulseaudio:PULSEAUDIO_SYSTEM_START=0
/etc/default/pyroman:PYROMAN_ENABLED="y"
/etc/default/rsync:RSYNC_ENABLE=false
/etc/default/smartmontools:start_smartd=yes
/etc/default/spamassassin:ENABLED=0
/etc/default/tomcat5.5:TOMCAT5_USER=
/etc/default/zeroconf:#DISABLE=yes

And I might have missed some more on my system...
Note that they have quite inconsistent syntaxes (enable, start,
disable; tomcat even abuses the user variable to disable the service)
and defaults (e.g. rsync defaults to 'no', zeroconf to 'yes').

Since that is so common, we should support it somehow. Of course we
won't be able to support all such setups (e.g. the tomcat user name
option...), but IMHO we need to think about what we can support
reasonably (note that this might also vary between init systems).
As for the tomcat case, I think using a shell script to handle the
actual startup and /etc/default/tomcat* handling is appropriate; the
meta-init file should just execute this setup script.

best regards,
Erich Schubert
--
    erich@(mucl.de|debian.org)      --      GPG Key ID: 4B3A135C    (o_
  To understand recursion you first need to understand recursion.   //\
  Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für   V_/_
        eine Stunde wie eine Heimat aus. --- Herrmann Hesse