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

[Felipe Sateler]

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.

>  (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.


-- 

Saludos,
Felipe Sateler