Bug#591791: systemd point of view
]] Steve Langasek
Hi Steve,
| Picking up this policy thread after a bit... Let's see if we can drive this
| to a conclusion now.
Sounds good.
| Right. I've looked around, and the better interface to use here is 'initctl
| version'; this command tries to query the running init daemon over the
| upstart-specific control socket and fails if it can't connect. Of course,
| if the initctl command doesn't exist at all on the system, this will fail.
Works for me. I can most likely get a systemctl version command added
to systemd. (Or systemctl ping to just see if init is alive.)
| > + Dependency-based boot managers for SysV init scripts, such as
| > + <package>insserv</package>, may bypass a given init script
| > + entirely when an equivalent upstart job is present, to avoid
| > + unnecessary forking of no-op init scripts.
|
| > What happens to the dependency resolution of insserv in that case? I'd
| > much rather have insserv not do anything and the non-sysvinit init
| > system be smart and parse LSB headers rather than insserv seeing that A
| > depends B, but B is missing (since it's provided by a systemd
| > service/upstart job) and then flake out.
|
| This was a good question, which took me a while to answer. The answer I've
| come up with is
| <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-October/005345.html>.
| It's a deliberate design decision for upstart to not support parsing of LSB
| headers of init scripts, instead delegating this to insserv (and delegating
| the execution to /etc/init.d/rc). The linked patch, however, allows
| startpar to recognize when a dependency should be satisfied by an upstart
| job instead of by the corresponding init script.
If insserv just doesn't do anything when it sees systemd, that'd be fine
| > I'd also like us to forbid depending on implementation-specific scripts
| > such as mountkernfs since there won't necessarily be anything that maps
| > to in a non-sysvinit world. The exception would be if an init script is
| > shipped as part of the init system, so sysv-rc's scripts could have
| > dependencies on mountkernfs, but random daemons could not.
|
| udev already depends on mountkernfs as part of the rcS sequence. Of course,
| the entire rcS sequence should be replaced by the alternative init system,
| but this will still require cooperation between several packages.
We have ~115 init scripts which claims to start in rcS, replacing all of
these with systemd units and upstart jobs sounds like a bit too much, I
think, especially if this should come from the init system itself.
(I'm sure there are things in rcS that shouldn't be there too. Fixing
that would be great.)
| I'm not sure whether this needs to be documented in Policy per se, or with
| what level of granularity. I do think there's a bootstrapping tangle here,
| in that I don't want to start pushing patches to sysvinit, lsb-base, and
| debhelper until we have the basic Policy agreed upon, and I don't think
| we'll be able to discern a correct policy for things like mountkernfs until
| we've gotten fairly far along with implementing it. So if you don't mind,
| I'd like to split this particular issue off to be dealt with separately.
Ok, I can live with that. Alternatively, we could require packages
depending on implementation-specific init scripts to also ship
configurations for alternative init systems.
| > A final thing I'd like to get added to the policy text is how
| > standardised facility names are handled. insserv for some reason does
| > not handle init scripts providing $x-display-manager and similar, but
| > requires those to be added to the insserv configuration file. We should
| > either require init implementations to allow providing the standardised
| > facility names or we should put that information somewhere in a a
| > neutral location and format so all init implementations can make use of
| > it.
|
| Does this refer to aliases standardized in the LSB, or to some other
| standard? (I'd answer this for myself, but once again it looks like I can't
| find the text of the LSB when I'm looking for it...)
(refspecs.lf.o is still down, it seems)
They're (mostly) standardised in the LSB, but iirc Debian adds some of
their own. It seems like systemd might grow code to read the insserv
configuration files, but I'd rather it just lived in init scripts
themselves.
The patch seems mostly ok to me. I think we should decide whether we
want a single invoke-rc.d that everybody uses and which knows how to
handle all of sysvinit, upstart and systemd or if we want each init
system to ship their own. From the patch, it looks like each init
system should ship their own, but that it still must keep compatibility
with all other implementations.
Also, I'm a bit annoyed about you grabbing /etc/init, not because
systemd wants it for anything, but because it'll destroy tab completion
for those of us doing /etc/in<TAB>/foo restart so the namespace grab
will affect not only upstart users, but everybody.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: