Control: tags -1 confirmed On Mon, 31 Mar 2014 17:54:06 +0200 Ralf Jung <p...@ralfj.de> wrote: > I very much like how commands like "systemctl mask" or "systemctl unmask" > print to stdout the commands they are executing, so that it becomes > clear to the admin where this "magic" systemd state is stored and that > it's not so magic after all. > I seem to remember that this also used to be the case for > "systemctl disable" and "systemctl enable". > However, currently, no such output is done for what systemctl does > with the service file: > > $ sudo systemctl disable osspd > Synchronizing state for osspd with sysvinit using update-rc.d... > Executing /usr/sbin/update-rc.d osspd defaults > Executing /usr/sbin/update-rc.d osspd disable > insserv: warning: current start runlevel(s) (empty) of script `osspd' > overrides LSB defaults (2 3 4 5). > insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script > `osspd' overrides LSB defaults (0 1 6). > > I expected to see something like > > rm '/etc/systemd/system/multi-user.target.wants/osspd.service' > > in there. > The same goes for "systemctl enable".
So, the underlying reason for this behaviour is, that systemctl disable/enable will first callout to update-rc.d. The update-rc.d tool already creates some of the symlinks specified in [Install]. It does so silently. The support for [Install] in update-rc.d is incomplete though [1]. So for the remaining symlinks, systemctl will create them and actually display what it is doing. This I agree is highly inconsistent. My suggestion would be, that if update-rc.d is is called from systemctl, it should skip all .service file handling and leave that to systemctl. We could set a env variable in /lib/systemd/systemd-sysv-install and check for that env variable in update-rc.d. Thoughs? Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746580 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
