Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> > I suspect you and I have a root disagreement over the utility of exposing
> > some of those degrees of freedom to every init script author, but if you
> > have some more specific examples of policy that you wanted to change but
> > couldn't, I'd be interested in examples.
>
> It's not necessarily the init script author who might want the degrees
> of freedom, but the local system administrator.
>
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing in configuration files
> such as /etc/default/*, for example.
Both systemd and upstart support this well enough.
With systemd you can say EnvironmentFile=/etc/default/<whatever>
and use the variables in ExecStart=/path/to/prog $VAR1 $VAR2.
This is usually discouraged, not because it doesn't work, but
because it uses two files to provide very little value. In majority
of cases it turns out that the settings in /etc/default either
can't be changed in an useful way, or are better read by the daemon
itself from a different configuration file. But if you want this, then
it's there.
If the settings are to complicated for the declarative style, you
can always use an helper shell script to launch the daemon.
Again, discouraged, but certainly supported.
> Yes, yes, you can do this via if you use system V init scripts scripts
> in backwards compatibility mode, but you've argued that we should be
> moving briskly away from that. In which case system administrators
> will need to hand-edit the services files by hand, which will no doubt
> increase the chances of conflicts at package upgrade time, compared to
> if the configuration options were isolated away in files such as
> /etc/default/rsync (for example).
Actually this doesn't happen that often. Typical systemd service file
has 1-3 lines of documentation, 1+ lines of ExecStart stuff, and a few
additional settings. They are mostly orthogonal, so you just override
the one you need. Probably most common case is to override ExecStart=,
done by adding the file like /etc/systemd/system/myservice.d/custom-start.conf
which only overrides ExecStart. Nice and simple, no conflicts on upgrade.
> > I realize that
> > the local administrator may have other goals, and they should have ways of
> > achieving them, but both systemd and upstart support running SysV init
> > scripts for those cases.
>
> If the package does not ship a SysV init script (which is your ideal
> long-term outcome), that may not be very practical option for a system
> adminsitrator who may need to recreate a SysV init script, especially
> if the service file is rather complicated, or is using some of the
> more advanced feature of systemd/upstart.
Why would you recreate the whole script? Let the init manager take
care of starting and stopping and supervising, and only do the custom
stuff in the script. Then it should be just a few lines.
Zbyszek
Reply to: