Hi Michael, Michael Biebl <bi...@debian.org> writes: > a/ For a service with sysv + native service, where the service is > masked, we still run the update-rc.d call but then fail when trying to > modify the native service: > > root@pluto:/etc# systemctl mask kbd.service > ln -s '/dev/null' '/etc/systemd/system/kbd.service' > > root@pluto:/etc# systemctl disable kbd.service > Synchronizing state for kbd.service with sysvinit using update-rc.d... > Executing /usr/sbin/update-rc.d kbd disable > insserv: warning: current start runlevel(s) (empty) of script `kbd' > overrides LSB defaults (S). > insserv: warning: current stop runlevel(s) (S) of script `kbd' overrides > LSB defaults (empty). > Failed to issue method call: No such file or directory > > root@pluto:/etc# echo $? > 1 > > root@pluto:/etc# ll /etc/rc?.d/???kbd > lrwxrwxrwx 1 root root 13 Aug 10 13:20 /etc/rcS.d/K19kbd -> > ../init.d/kbd
To dump the state we acquired on IRC: The idea here is to not do anything for masked services, as “masked” is kind of a special state, and the disable/enable state would get out of sync. I briefly looked into this but didn’t find an obvious way to check whether a service is masked from systemctl.c’s C code. I might ask upstream about it tomorrow at DebConf. > b/ the systemctl disable output is incomplete, example rsyslog > without the patch: > > root@pluto:/etc# systemctl enable rsyslog.service > ln -s '/lib/systemd/system/rsyslog.service' > '/etc/systemd/system/syslog.service' > ln -s '/lib/systemd/system/rsyslog.service' > '/etc/systemd/system/multi-user.target.wants/rsyslog.service' > > with the patch: > root@pluto:/etc# systemctl enable rsyslog.service > Synchronizing state for rsyslog.service with sysvinit using update-rc.d... > Executing /usr/sbin/update-rc.d rsyslog enable > ln -s '/lib/systemd/system/rsyslog.service' > '/etc/systemd/system/syslog.service' > > > Notice, how > "ln -s '/lib/systemd/system/rsyslog.service' > '/etc/systemd/system/multi-user.target.wants/rsyslog.service'" > is missing in the second output. It seems to create that symlink, just > misses to output that information. This we solved: update-rc.d creates one of the symlinks, that’s why it is missing in the output :). -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
