On Fri, Aug 19, 2016 at 05:27:57PM -0300, Felipe Sateler wrote: > On 19 August 2016 at 17:23, Josh Triplett <j...@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 <j...@joshtriplett.org> wrote: > >> > On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler <fsate...@debian.org> > >> > wrote: > >> >> On 17 August 2016 at 03:45, Ferenc Wágner <wf...@niif.hu> wrote: > >> >> > Michael Biebl <bi...@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.
