Re: Bug#857452: Steps towards a patch to document disabling a daemon upon installation
- Date: Thu, 5 Oct 2017 09:57:00 -0300
- From: Felipe Sateler <fsateler@xxxxxxxxxx>
- Subject: Re: Bug#857452: Steps towards a patch to document disabling a daemon upon installation
On Tue, Sep 12, 2017 at 9:49 AM, Ian Jackson
> Felipe Sateler writes ("Re: Steps towards a patch to document disabling a daemon upon installation"):
>> I suggest instead mentioning the real reasons its bad:
> Thanks for providing real reasons.
>> > I can't speak to the behaviour of systemd, but I think the
>> > update-rc.d add-disabled
>> > operation I propose would, for sysvinit systems, do the follow:
>> > 1. Are there already rc*.d links for DAEMON ? If so, do nothing.
>> > 2. If not, create them in the way that defaults && disable
>> > would have done.
>> Currently, update-rc.d leaves all the hard work to insserv under sysvinit.
>> The behaviour would have to change to check if any links exist and skip
>> invoking insserv in that case. I am not sure if that would mean a behavior
>> change though. Maybe this early in the release cycle is a good time to
>> try these kinds of changes.
> I think that the right thing for `update-rc.d defaults-disabled' is to
> do this:
> 1. check to see if any links already exist
> if they do, do nothing else
> 2. parse the init script to find the default-start and default-stop
> 3. run
> insserv add DAEMON,stop=RLVL,RLVL,....
> (for the complete set of start and stop runlevels)
> After this, the script is run for `stop' in each of those runlevels,
> roughly like update-rc.d disable would do (the sequence numbers will
> briefly not be identical, until insserv is re-run).
I have a branch that does some refactoring to update-rc.d and adds the