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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
