Re: init systems and Policy
]] Simon McVittie
> On 27/03/12 07:20, Tollef Fog Heen wrote:
> >> It is not clear to me the status of similar policy work for systemd,
> >> although I see that systemd maintainers are participating in
> >> #591791. Again, if you're interested in Debian switch to systemd,
> >> please contribute to that work rather than arguing on -devel.
> >
> > It's not entirely clear to me that we need any policy changes at all for
> > packages to ship systemd unit files.
>
> As far as I understand it, the particular feature of systemd that makes
> it unproblematic to ship systemd unit files is that systemd will
> normally run sysvinit scripts, but will ignore /etc/init.d/foo if it
> sees a foo.service in its own format - so packages without specific
> systemd support still work (systemd runs the sysvinit scripts) and
> packages with a systemd unit file also work, without running the service
> twice (it runs the systemd unit and ignores the corresponding sysvinit
> script).
Correct. You can also have dependencies between LSB init scripts and
systemd units (both ways).
The only case I've seen this cause problems is when you have an init
script that provides other verbs than systemctl does, since
/etc/init.d/foo $verb is translated into systemctl foo.service $verb
> Ubuntu's version of debhelper includes changes to maintainer scripts to
> avoid calling update-rc.d for sysvinit scripts when there is a
> corresponding Upstart job, from which I infer that Upstart does not do
> the same as systemd? If that's the case, then that's why Upstart needs
> special and careful handling in Policy. It also makes Ubuntu's debhelper
> patches unsuitable for use in Debian in their current form, since the
> patch effectively assumes that if there is an Upstart job, it will be
> run, and that's not true on non-Upstart systems.
Yes, upstart needs a transition that needs to be handled carefully and
this is why Steve Langasek has been working on getting this right and
into policy for quite a while. It's not trivial, particularly not if
you upgrade from a non-upstart-job to a package providing an upstart
job.
> I'm inclined to think Upstart's sysvinit compatibility layer should do
> the same as systemd's, unless there's some compelling reason not to -
> then specific support for systemd and/or Upstart would only require
> adding /lib/systemd/system/foo.service and/or /etc/init/foo.conf, which
> would automatically make the corresponding init implementation ignore
> /etc/init.d/foo.
I think that would be a much better course of action for upstart, but
it's not the direction they've chosen.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: