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/
_______________________________________________
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
