(Sorry for the noise, pressed 'send' to soon...)
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 enable b.service
Failed to execute operation: No such file or directory
(There is no /etc/init.d/a or /etc/init.d/b, so only systemd's own
code-
path will be used here.)
So even if update-rc.d didn't do the logic by itself,
non-Alias=-symlinks
currently don't work with systemctl enable/disable, so your example
wouldn't have worked even if Jessie came only with systemd and insserv
was
only used for sysv scripts.
Christian
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
