Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Theodore Ts'o <tytso@mit.edu> writes:
> 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.
> 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).
Ah, I see.
However, I do think this is mostly a solvable problem. We should provide
meaningful flexibility in our init script configuration, which may include
providing hooks so that local administrators have a place to put that
local policy.
You're right that some of this functionality will probably be lost in the
initial conversion to something other than init scripts, but I would
consider that to (usually) be a bug, and as people report problems, we can
be sure it's added back in after understanding the issues involved. Yes,
this may be a bit annoying for people in the short term, but I do think it
gets us to a better place in the long run by way of supporting clean and
documented interfaces for those policy settings.
It is true that currently init scripts are full-blown programs, allowing
anyone who is capable of programming in that language to make arbitrary
policy modifications. We lose that by switching to a higher-level
language, and only policy decisions anticipated by that language will be
easily implemented. More complex policy decisions would have to be
handled at a higher level, via selectively creating or removing the
configuration files. It's certainly a disruptive change. I'm not
convinced it's a net negative, but it will depend on how strong the
available hooks are and what types of policy the local administrator wants
to easily change.
I do think that being able to treat the init scripts as real configuration
files will make maintaining such local policy easier than it is currently.
The prospect of modifying init scripts was already dire enough that we
pushed most meaningful configuration into /etc/default instead of asking
that people change the complicated init scripts and then handle merges on
package upgrades. *Most* local changes are fairly simple, and would only
require small and mergable changes to upstart configuration files, and
small overrides to systemd files.
I personally like upstart's model a little better, but systemd's model of
/etc overrides /lib is, I think, workable as long as people remember to
change only the setting they want and then include the original instead of
making copies of the whole configuration. (That being said, I'm worried
about how the systemd model handles the common case of wanting to change
the command-line arguments to a daemon, and then having the package also
change the command-line arguments in some orthogonal way.)
> 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.
You can do quite a bit with the hooks that are part of the specification
of both types of files. For example, logic that you may add to control
whether the service should start at all can be implemented by adding a
pre-start stanza to the upstart configuration.
This particular action appears to be harder to do in systemd, which
doesn't, at least from the documentation that I've found, support running
arbitrary shell code to determine whether to start a unit, but there are a
bunch of other possible built-in checks. I suppose one could also change
the command started to wrap it and put the check there, although that
feels quite ugly.
In general, upstart's integration with arbitrary actions in shell
fragments is considerably better than systemd's, at least based on the
documentation I've read. upstart feels like it provides more useful
flexibility.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: