Bug#834524: init-system-helpers: does not own /etc/rc?.d

[Josh Triplett]

On Fri, Aug 19, 2016 at 05:27:57PM -0300, Felipe Sateler wrote:
> On 19 August 2016 at 17:23, Josh Triplett <josh at joshtriplett.org> wrote:
> > On Fri, Aug 19, 2016 at 04:51:12PM -0300, Felipe Sateler wrote:
> >> On 19 August 2016 at 15:24, Josh Triplett <josh at joshtriplett.org> wrote:
> >> > On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler <fsateler at debian.org> wrote:
> >> >> On 17 August 2016 at 03:45, Ferenc Wágner <wferi at niif.hu> wrote:
> >> >> > Michael Biebl <biebl at debian.org> writes:
> >> >> >
> >> >> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> >> >> >>
> >> >> >>> Recently both my daemon packages started to exhibit this piuparts error:
> >> >> >>>
> >> >> >>> ERROR: FAIL: Package purging left files on system:
> >> >> >>>   /etc/rc2.d/         not owned
> >> >> >>>   /etc/rc3.d/         not owned
> >> >> >>>   /etc/rc4.d/         not owned
> >> >> >>>   /etc/rc5.d/         not owned
> >> >> >>>
> >> >> >>> I think this is the result of sysv-rc losing its Essential flag, which means
> >> >> >>> it isn't present in minimal chroots (like those used by piuparts) anymore.
> >> >> >>> On the other hand, init-system-helpers imported update-rc.d in version 1.25,
> >> >> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
> >> >> >>> this results in piuparts failures in recently tested daemon packages.
> >> >> >>>
> >> >> >>> If the above analysis is correct, please fix this.
> >> >> >>
> >> >> >> Fix what exactly?
> >> >> >
> >> >> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
> >> >> > directories.  (Removing them if they become empty is another option, but
> >> >> > does not sound a very good idea.)  Previously they were owned by
> >> >> > sysv-rc, which also provided update-rc.d, which used these directories.
> >> >> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
> >> >> > followed along, but was forgotten, I guess.
> >> >>
> >> >> Indeed. init-system-helpers even already did this for
> >> >> /etc/systemd/system. I have added the rc?.d directories to the list.
> >> >>
> >> >> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
> >> >
> >> > This will cause the directories to continue to exist even when empty.
> >>
> >> Yes.
> >>
> >> >
> >> > Ideally, these directories could become empty and disappear eventually,
> >> > on a system not running sysvinit.  What would it take for that to
> >> > happen?
> >>
> >> A lot more than reverting that commit :)
> >>
> >> On my system I see:
> >>
> >> % dpkg -S /etc/init.d/*
> >> avahi-daemon: /etc/init.d/avahi-daemon
> >> binfmt-support: /etc/init.d/binfmt-support
> >> cron: /etc/init.d/cron
> >> dbus: /etc/init.d/dbus
> >> util-linux: /etc/init.d/hwclock.sh
> >> procps: /etc/init.d/procps
> >> rsync: /etc/init.d/rsync
> >> openssh-server: /etc/init.d/ssh
> >> sudo: /etc/init.d/sudo
> >> udev: /etc/init.d/udev
> >> unattended-upgrades: /etc/init.d/unattended-upgrades
> >> x11-common: /etc/init.d/x11-common
> >>
> >> util-linux is essential, udev is pretty much required on
> >> non-containers. Procps and cron are Priority important.
> >>
> >> As long as we support non-systemd init, all of those need to ship init
> >> scripts. And as long as they do, there will be /etc/rc?.d directories.
> >
> > Not necessarily.  /etc/init.d will need to exist; /etc/rc?.d doesn't,
> > unless an init system making use of rc?.d links is installed.
> 
> Systemd is an init systemd that makes use of rc?.d links, as it uses
> that information to determine if a service without native unit is
> enabled.

That seems potentially fixable, by making the "disable" mechanism create
a foo.service -> /dev/null link.  (Or, more easily, by providing a
native unit.)

(I'm not arguing that this should happen *soon*, but I look forward to
moving in that direction.)

> >  (As a
> > random possibility, installing sysvinit or similar could trigger the
> > generation of rc?.d scripts, avoiding the need to generate them at
> > install time.  That would be a lot easier if update-rc.d ran via a
> > trigger, which seems a lot more plausible now that it no longer accepts
> > any kind of priority options and all such information must live in the
> > script.)
> 
> Unfortunately, invoke-rc.d relies on the enablement links as well.
> Thus update-rc.d must happen before invoke-rc.d. Converting
> invoke-rc.d to triggers is not as trivial, as not all scripts have to
> be started on package installation/upgrade, and restart-on-upgrade
> behavior differs.

That seems like something we should eventually migrate to something like
systemd-preset files, which would also make it much more convenient for
admins to set policies like whether to start services on installation or
not.  In addition, that would eliminate a huge number of maintainer
scripts in favor of declarative information.