[Pkg-sysvinit-devel] Bug#502195: Bug#502195: invoke-rc.d with action [force-]reload doesn't obey runlevel constraints

[Henrique de Moraes Holschuh]

On Wed, 15 Oct 2008, Paolo Miotto wrote:
>>> Well, it is OK that a script called with reload fails if the service is
>>> not running, but the point is: why ask a reload to a service that is not
>>> running (because disabled), maybe failing even a pre/post install script?
>>
>> Because reload (and force-reload, if it was a sane thing which it isn't) are
>> supposed to control a service if that service is running, regardless of the
>> reason.
>>
>
> If I understand well, the bug is in the behavior of the force-reload  
> parameter, that is often (but not always) an alias for restart (and so  
> is a bug for hundreds of packages?)

1. There is no bug in not restricting the RELOAD action.  RELOAD is not
   to be restricted by runlevel.

2. The force-reload action is crap. It is always going to cause trouble.
   I have no strong feelings where it should be resticted by runlevels
   like restart, or non-restricted like reload.

> So if I have the daemon started by hand, or by some HeartBeat OCF  
> scripts (as in our case), possibly with different configurations and  
> parameters, the init script is supposed to [force-]reload it anyway,  
> even if this can change the way the daemons works due to different  
> configurations?

Yes.  It is your fault that you have not disabled the initscript ITSELF if
running it in your custom configuration will blow things up.

Or you have to UPDATE the initscript to do the right thing in your various
configurations.

> Can (must?) I control this via /usr/sbin/policy-rc.d?

Yes, you can use policy-rc.d to make invoke-rc.d just plain refuse to ever
run the initscript.  But watch out for buggy packages calling invoke-rc.d
--force.

However, you don't HAVE to use policy-rc.d.  You can just write an exit 0 to
the top of the initscript if you don't want it to ever run because of your
custom config.  You could also make it non-executable, but I am *NOT* sure
dpkg won't screw that up on upgrade, and I am NOT sure dpkg-statoverride
works properly for conffiles.

>>> It is not cleaner to skip the request at all?
>>
>> Unfortunately, no.
>
> It is not completely clear to me the reason, but maybe this is not an  
> argument to deal with a bug report, so if there is a reference may be  
> good.

I can't help you there :(  I wrote a paper about these things, but it is
quite outdated nowadays.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh