Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
On 1/11/19 6:37 AM, Dmitry Bogatov wrote: > [2018-07-19 23:47] Richard Laager >> My current intention is to rename the service from ntp.service to >> ntpsec.service. Accordingly, I'm undoing my severity change here. > > For what it worth, you may be interested virtual facilities > (/etc/insserv.conf). We could introduce new virtual dependency $ntp, > provided by either ntp or ntpsec package. Thanks for the reference. My initial desire to use "ntp" as the service name was for backwards-compatibility with system administrators, not other services' dependencies, so a virtual dependency wouldn't matter. Somewhat related, there is an existing $time virtual service: https://wiki.debian.org/LSBInitScripts Note that ntpsec (like ntp) is not providing a $time implementation. The $time service should depend on an ntpwait service, not simply ntpd, because $time is defined as when the clock is _set_. If you wish to discuss that further, we should move off this bug, either to private email or to a new bug on ntpsec. -- Richard
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
[2018-07-19 23:47] Richard Laager > On 07/14/2018 08:34 PM, Richard Laager wrote: > > Purging ntp after installing ntpsec seems to be fairly common with > > users. Accordingly, I'm raising the severity of this bug to important. > > My current intention is to rename the service from ntp.service to > ntpsec.service. Accordingly, I'm undoing my severity change here. For what it worth, you may be interested virtual facilities (/etc/insserv.conf). We could introduce new virtual dependency $ntp, provided by either ntp or ntpsec package.
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
control: tags -1 +patch
[2012-07-04 22:17] Paul Menzel
> Dear Debian folks,
>
>
> the manual of `update-rc.d` contains the following paragraph.
>
> $ man update-rc.d
> […]
> When invoked with the remove option, update-rc.d removes any
> links in the /etc/rcrunlevel.d directories to the
> script /etc/init.d/name. The script must have been deleted
> already. If the script is still present then update-rc.d aborts
> with an error message.
> […]
>
> It looks like `update-rc.d remove name` still works though when the
> script in `/etc/init.d/name` is not removed beforehand.
>
> $ sudo update-rc.d pulseaudio remove
> update-rc.d: using dependency based boot sequencing
> $ ls -l /etc/init.d/pulseaudio
> -rwxr-xr-x 1 root root 2227 1. Okt 2011 /etc/init.d/pulseaudio
> $ ls -l /etc/rc*.d/*audio
> ls: Zugriff auf /etc/rc*.d/*audio nicht möglich: Datei oder
> Verzeichnis nicht gefunden
> $ sudo service pulseaudio stop
> PulseAudio configured for per-user sessions ... (warning).
>
> I guess the bug has been present for a longer time, so please update the
> version information accordingly.
Dear maintainers of init-system-helpers, please consider following
patch, that adjust behaviour of update-rc.d to match manpage.
From 46c7069cf9253399540cb0a75c51e164293e8689 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Thu, 10 Jan 2019 15:57:35 +
Subject: [PATCH] update-rc.d: refuse to remove links to present script
Fix behaviour of update-rc.d to match manual page: throw error on
attemps to remove links to script, that is not removed.
(Closes: #680293)
---
script/update-rc.d | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/script/update-rc.d b/script/update-rc.d
index 71fb1a6..870af0e 100755
--- a/script/update-rc.d
+++ b/script/update-rc.d
@@ -193,7 +193,7 @@ sub create_sequence {
$sysv_insserv->{remove} = sub {
my ($scriptname) = @_;
if ( -f "/etc/init.d/$scriptname" ) {
-return system($insserv, @opts, "-r", $scriptname) >> 8;
+error("/etc/init.d$scriptname exists, refusing `remove' action.");
} else {
# insserv removes all dangling symlinks, no need to tell it
# what to look for.
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
On 07/14/2018 08:34 PM, Richard Laager wrote: > Purging ntp after installing ntpsec seems to be fairly common with > users. Accordingly, I'm raising the severity of this bug to important. My current intention is to rename the service from ntp.service to ntpsec.service. Accordingly, I'm undoing my severity change here. -- Richard
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
On Wed, 04 Jul 2012 23:00:53 +0200 Paul Menzel wrote: > Am Mittwoch, den 04.07.2012, 21:33 +0100 schrieb Roger Leigh: > > On Wed, Jul 04, 2012 at 10:17:10PM +0200, Paul Menzel wrote: > > > Does the manual need updating? > > > > No, I think the manual is correct and update-rc.d is not behaving as > > documented. > > I wonder though, what is the disadvantage of leaving `/etc/init.d/name` > behind and `-f` has to be used to do so? The documented behavior is important if two packages provide a service of the same name. For example, the packages "ntp" and "ntpsec" both provide a service called "ntp". (I am the maintainer of ntpsec.) A user hit this in bug #901439: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901439 Consider this series of steps: 1) apt install ntp 2) apt install ntpsec 3) apt purge ntp Step 1 creates /etc/init.d/ntp and the symlinks. Step 2 results in the ntp package being removed, and ntpsec's /etc/init.d/ntp installed instead. Step 3 results in ntp's postrm script, by way of the standard dh_installinit snippet, calling `update-rc.d ntp remove`. Expected results: /etc/rc*.d/*ntp symlinks are left alone. Actual results: /etc/rc*.d/*ntp symlinks are deleted. Purging ntp after installing ntpsec seems to be fairly common with users. Accordingly, I'm raising the severity of this bug to important. I would mark it serious, but I can't currently point to an explicit policy item being violated nor am I the maintainer of this package (nor a release manager). The same thing happens, for the exact same reasons, if you start with ntpsec, install ntp, then purge ntpsec. -- Richard
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
Package: sysvinit Version: 2.88dsf-28 Severity: normal Dear Debian folks, the manual of `update-rc.d` contains the following paragraph. $ man update-rc.d […] When invoked with the remove option, update-rc.d removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already. If the script is still present then update-rc.d aborts with an error message. […] It looks like `update-rc.d remove name` still works though when the script in `/etc/init.d/name` is not removed beforehand. $ sudo update-rc.d pulseaudio remove update-rc.d: using dependency based boot sequencing $ ls -l /etc/init.d/pulseaudio -rwxr-xr-x 1 root root 2227 1. Okt 2011 /etc/init.d/pulseaudio $ ls -l /etc/rc*.d/*audio ls: Zugriff auf /etc/rc*.d/*audio nicht möglich: Datei oder Verzeichnis nicht gefunden $ sudo service pulseaudio stop PulseAudio configured for per-user sessions ... (warning). Does the manual need updating? I guess the bug has been present for a longer time, so please update the version information accordingly. Two more or less related notes. 1. The printing of `update-rc.d: using dependency based boot sequencing` is unexpected. 2. To disable an init.d script, is it better to just remove the executable flag of `/etc/init.d/name` with the latest changes in 2.88dsf-28? Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
On Wed, Jul 04, 2012 at 10:17:10PM +0200, Paul Menzel wrote: the manual of `update-rc.d` contains the following paragraph. $ man update-rc.d […] When invoked with the remove option, update-rc.d removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already. If the script is still present then update-rc.d aborts with an error message. […] This is my understanding. It should only remove the links if you use -f remove to force removal. It looks like `update-rc.d remove name` still works though when the script in `/etc/init.d/name` is not removed beforehand. $ sudo update-rc.d pulseaudio remove update-rc.d: using dependency based boot sequencing $ ls -l /etc/init.d/pulseaudio -rwxr-xr-x 1 root root 2227 1. Okt 2011 /etc/init.d/pulseaudio $ ls -l /etc/rc*.d/*audio ls: Zugriff auf /etc/rc*.d/*audio nicht möglich: Datei oder Verzeichnis nicht gefunden $ sudo service pulseaudio stop PulseAudio configured for per-user sessions ... (warning). Does the manual need updating? No, I think the manual is correct and update-rc.d is not behaving as documented. Mind you, I've not seen this before. But I can also reproduce it: % ls /etc/init.d/cups /etc/init.d/cups % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups % sudo update-rc.d cups remove update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups zsh: no matches found: /etc/rc*.d/*cups % sudo update-rc.d cups defaults update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups I'm fairly sure this didn't happen until recently. But there were only two changes to update-rc.d in 2012, and both were trivial changes which didn't affect this. This will need investigating in more detail. I guess the bug has been present for a longer time, so please update the version information accordingly. Two more or less related notes. 1. The printing of `update-rc.d: using dependency based boot sequencing` is unexpected. It's always done this when using insserv AFAIK. If you hadn't converted to using dependency based boot until 2.88dsf-28, this might be new though. I think we should remove it in wheezy+1 though, or even wheezy if it's not going to cause too much confusion--should people who have been converted to dependency based boot be reminded of the fact every time update-rc.d is run? 2. To disable an init.d script, is it better to just remove the executable flag of `/etc/init.d/name` with the latest changes in 2.88dsf-28? You can do that, certainly. Or just use update-rc.d service disable: % sudo update-rc.d cups disable update-rc.d: using dependency based boot sequencing insserv: warning: current start runlevel(s) (empty) of script `cups' overwrites defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (1 2 3 4 5) of script `cups' overwrites defaults (1). % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/K01cups /etc/rc3.d/K01cups /etc/rc4.d/K01cups /etc/rc5.d/K01cups % sudo update-rc.d cups enable update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups This converts the start links to stop links, and enable reverses this. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
Am Mittwoch, den 04.07.2012, 21:33 +0100 schrieb Roger Leigh: On Wed, Jul 04, 2012 at 10:17:10PM +0200, Paul Menzel wrote: the manual of `update-rc.d` contains the following paragraph. $ man update-rc.d […] When invoked with the remove option, update-rc.d removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already. If the script is still present then update-rc.d aborts with an error message. […] This is my understanding. It should only remove the links if you use -f remove to force removal. It looks like `update-rc.d remove name` still works though when the script in `/etc/init.d/name` is not removed beforehand. $ sudo update-rc.d pulseaudio remove update-rc.d: using dependency based boot sequencing $ ls -l /etc/init.d/pulseaudio -rwxr-xr-x 1 root root 2227 1. Okt 2011 /etc/init.d/pulseaudio $ ls -l /etc/rc*.d/*audio ls: Zugriff auf /etc/rc*.d/*audio nicht möglich: Datei oder Verzeichnis nicht gefunden $ sudo service pulseaudio stop PulseAudio configured for per-user sessions ... (warning). Does the manual need updating? No, I think the manual is correct and update-rc.d is not behaving as documented. I wonder though, what is the disadvantage of leaving `/etc/init.d/name` behind and `-f` has to be used to do so? Mind you, I've not seen this before. But I can also reproduce it: % ls /etc/init.d/cups /etc/init.d/cups % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups % sudo update-rc.d cups remove update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups zsh: no matches found: /etc/rc*.d/*cups % sudo update-rc.d cups defaults update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups I'm fairly sure this didn't happen until recently. But there were only two changes to update-rc.d in 2012, and both were trivial changes which didn't affect this. This will need investigating in more detail. I tried it on a system with sysv-rc 2.88dsf-22.1 which has *not* been converted to dependency based boot yet. There it behaved as described in the manual. $ ls -l /etc/init.d/pulseaudio -rwxr-xr-x 1 root root 2249 Mai 18 20:54 /etc/init.d/pulseaudio $ sudo update-rc.d pulseaudio remove update-rc.d: /etc/init.d/pulseaudio exists during rc.d purge (use -f to force) I guess the bug has been present for a longer time, so please update the version information accordingly. Two more or less related notes. 1. The printing of `update-rc.d: using dependency based boot sequencing` is unexpected. It's always done this when using insserv AFAIK. If you hadn't converted to using dependency based boot until 2.88dsf-28, this might be new though. I used `update-rc.d` the first time, but the output looked strange to me. I think we should remove it in wheezy+1 though, or even wheezy if it's not going to cause too much confusion--should people who have been converted to dependency based boot be reminded of the fact every time update-rc.d is run? I guess the other maintainers and developers should answer that. 2. To disable an init.d script, is it better to just remove the executable flag of `/etc/init.d/name` with the latest changes in 2.88dsf-28? You can do that, certainly. Or just use update-rc.d service disable: % sudo update-rc.d cups disable update-rc.d: using dependency based boot sequencing insserv: warning: current start runlevel(s) (empty) of script `cups' overwrites defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (1 2 3 4 5) of script `cups' overwrites defaults (1). % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/K01cups /etc/rc3.d/K01cups /etc/rc4.d/K01cups /etc/rc5.d/K01cups % sudo update-rc.d cups enable update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups This converts the start links to stop links, and enable reverses this. Thank you for the explanation. Although skimming through the manual pages, I did not find how these links are used. Links starting with »S« are executed with the `start` argument and links starting with »K« with the `stop` argument? Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
On Wed, Jul 04, 2012 at 11:00:53PM +0200, Paul Menzel wrote: Am Mittwoch, den 04.07.2012, 21:33 +0100 schrieb Roger Leigh: On Wed, Jul 04, 2012 at 10:17:10PM +0200, Paul Menzel wrote: the manual of `update-rc.d` contains the following paragraph. $ man update-rc.d […] When invoked with the remove option, update-rc.d removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already. If the script is still present then update-rc.d aborts with an error message. […] This is my understanding. It should only remove the links if you use -f remove to force removal. I'm not entirely certain of the historical reasons, but it's likely a safety feature to prevent accidental removal of links, since you could make your system unbootable if you removed a critical link. It looks like `update-rc.d remove name` still works though when the script in `/etc/init.d/name` is not removed beforehand. $ sudo update-rc.d pulseaudio remove update-rc.d: using dependency based boot sequencing $ ls -l /etc/init.d/pulseaudio -rwxr-xr-x 1 root root 2227 1. Okt 2011 /etc/init.d/pulseaudio $ ls -l /etc/rc*.d/*audio ls: Zugriff auf /etc/rc*.d/*audio nicht möglich: Datei oder Verzeichnis nicht gefunden $ sudo service pulseaudio stop PulseAudio configured for per-user sessions ... (warning). Does the manual need updating? No, I think the manual is correct and update-rc.d is not behaving as documented. I wonder though, what is the disadvantage of leaving `/etc/init.d/name` behind and `-f` has to be used to do so? As above, I think it's not so much about leaving the init script behind, as it is about preventing removing needed links inadvertently. Mind you, I've not seen this before. But I can also reproduce it: % ls /etc/init.d/cups /etc/init.d/cups % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups % sudo update-rc.d cups remove update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups zsh: no matches found: /etc/rc*.d/*cups % sudo update-rc.d cups defaults update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups I'm fairly sure this didn't happen until recently. But there were only two changes to update-rc.d in 2012, and both were trivial changes which didn't affect this. This will need investigating in more detail. I tried it on a system with sysv-rc 2.88dsf-22.1 which has *not* been converted to dependency based boot yet. There it behaved as described in the manual. Thanks, that's useful to know. % sudo update-rc.d cups disable update-rc.d: using dependency based boot sequencing insserv: warning: current start runlevel(s) (empty) of script `cups' overwrites defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (1 2 3 4 5) of script `cups' overwrites defaults (1). % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/K01cups /etc/rc3.d/K01cups /etc/rc4.d/K01cups /etc/rc5.d/K01cups % sudo update-rc.d cups enable update-rc.d: using dependency based boot sequencing % ls /etc/rc*.d/*cups /etc/rc1.d/K01cups /etc/rc2.d/S04cups /etc/rc3.d/S04cups /etc/rc4.d/S04cups /etc/rc5.d/S04cups This converts the start links to stop links, and enable reverses this. Thank you for the explanation. Although skimming through the manual pages, I did not find how these links are used. Links starting with »S« are executed with the `start` argument and links starting with »K« with the `stop` argument? Yes. This is classic System V init behaviour. When you enter a runlevel, you run all the S links with start. When you leave a runlevel, you run all the K links with stop; actually the ways the scripts are run when you switch runlevels isn't quite that straightforward, but that's almost essentially what happens. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
