[Pkg-sysvinit-devel] Bug#746580: sysv-rc: [patch] much improved update-rc.d integration w/ systemd

[Raphael Hertzog]

Hello,

On Sun, 15 Mar 2015, Christian Seiler wrote:
> Control: severity -1 important
> Control: tags -1 + patch

I'm tempted to raise the severity to serious as the current behaviour
is really bad for packages that ship both native .service files and
init script.

It's ok for packages that ship only the init script though.

> I have created a patch that implements the previously missing parts of
> systemd integration into update-rc.d, following along the lines of the
> patch I have written for deb-systemd-helper (bug #780522).

While this improves the situation, there is at least another corner case.

I really believe that reimplementing "systemctl enable/disable" ourselves
is a bad choice. I understand it's needed to register this
enabled/disabled status even when systemd is not installed... but we
should have stored those information in a directory of our own
and call all the required "systemctl enable/disable"accordingly when we
install systemd. 

The corner case I just encountered is with "openbsd-inetd". The
service file is inetd.service but the package ships openbsd-inetd.service
as a symlink to inetd.service so both names refer to the same unit
and it effectively masks the init script (/etc/init.d/openbsd-inetd).

Everything is fine except that when deb-systemd-helper enables
inetd.service it creates inetd.service symlinks. And when you do
"update-rc.d openbsd-inetd enable/disable", update-rc.d will create/remove
an openbsd-inetd.service symlink.

So "update-rc.d openbsd-inetd disable" doesn't disable the service
since inetd.service remains... and enable creates a duplicate symlink
in multi-user.target.wants.

Using "systemctl enable|disable inetd" works as expected
but "systemctl enable|disable openbsd-inetd" does not detect
that openbsd-inetd is a synonym for inetd, and will consider
that the unit is one coming from a SysV setup since
/etc/init.d/openbsd-inetd exists...

For the record, I discovered this in Kali because we divert update-rc.d
(into debian-update-rc.d) to call "debian-update-rc.d script disable" for
some blacklisted service after having installed them.

This trick no longer works well for the packages which use different
basename for their .service files compared to the init script :-(

And systemd's preset are also not usable currently (see #772555).


My suggestion would be that when systemctl calls update-rc.d, it passes
an environment variable (or a command line flag) that tells update-rc.d
to not touch the systemd symlinks. Conversely, update-rc.d should use
"systemctl" when it's available and pass some flag/environment variable
to instruct it to not run update-rc.d.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/