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

[Christian Seiler]

Am 2015-03-20 15:01, schrieb Raphael Hertzog:
> 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.

I was also tempted, but decided to first raise it to important first 
(it
was normal before).

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

Note that with bare systemd (at least 215, I didn't test newer 
versions),
this doesn't really work either:

# cat > /lib/systemd/system/a.service <<EOF
[Service]
ExecStart=/bin/true
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
# ln -s a.service /lib/systemd/system/b.service
# systemctl daemon-reload
# systemctl enable a.service        # works
Created symlink from 
/etc/systemd/system/multi-user.target.wants/a.service to 
/lib/systemd/system/a.service.
# systemctl disable a.service       # works
Removed symlink /etc/systemd/system/multi-user.target.wants/a.service.
# systemctl

>
> 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/