Debian Bug report logs - #152955
force-reload should not start the daemon if it is not running

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bernd Eckenfels <ecki@lina.inka.de>

To: submit@bugs.debian.org

Subject: debian-policy: section 10.3.2 in force-reload should be more clear

Date: Sun, 14 Jul 2002 22:20:11 +0200

Package: debian-policy
Version: 3.5.6.1
Severity: wishlist

After short discussion on debian-devel it is obvious, that the section on
policy about the restart and force reload of daemons in init.d scripts could
be more verbose. There are two options, one is to document the current
behavior (which can be found in the skel script) the other is a change in
the behavior, which is less desirable.

I propose the following extension to 10.3.2 (please correct my stupid
English).

---
The 'restart' method of the init.d script must not fail, if the daemon was
not running. This means, it will simply start a new daemon instance, without
reporting an error. This behavior is also allowed for 'force-reload' if it
is linked to the restart method. Other methods of 'force-reload' (like
signalling or null implementation, because of automatic config reload) do
not need to start a terminated process. In this case a non null error level
should be returned.
---

<... most likely we should also define exit levels, like RH does ...>

Greetings
Bernd

-- System Information
Debian Release: 3.0
Kernel Version: Linux calista 2.4.18-xfs #8 Wed May 1 10:30:33 CEST 2002 i686 unknown

Versions of the packages debian-policy depends on:
ii  fileutils      4.1-10         GNU file management utilities

Message #10 received at 152955@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Bernd Eckenfels <ecki@lina.inka.de>, 152955@bugs.debian.org

Subject: Re: Bug#152955: debian-policy: section 10.3.2 in force-reload should be more clear

Date: Mon, 15 Jul 2002 13:37:09 -0300

On Sun, 14 Jul 2002, Bernd Eckenfels wrote:
> After short discussion on debian-devel it is obvious, that the section on
> policy about the restart and force reload of daemons in init.d scripts could

I agree with that.  We do not define what force-reload does if the service
is not running [and it does indeed support configuration reloading].

> be more verbose. There are two options, one is to document the current
> behavior (which can be found in the skel script) the other is a change in

The current behaviour is not consistent.  There are packages doing it either
way.  THAT is the real problem.

> the behavior, which is less desirable.

Oh, quite the opposite.  It is *desirable* to have force-reload defined as
"force a full configuration reload of the service, if it is running.  Fail
otherwise".  But the code to do so is more complicated.

> reporting an error. This behavior is also allowed for 'force-reload' if it
> is linked to the restart method. Other methods of 'force-reload' (like
> signalling or null implementation, because of automatic config reload) do
> not need to start a terminated process. In this case a non null error level
> should be returned.

I object to this change.  We should choose a method for force-reload, and
have it consistently implemented.  We probably should also try to get the
LSB to fix "force-reload" in their standard as well.  They have exactly the
same problem:

"force-reload: cause the configuration to be reloaded if the service supports
this, otherwise restart the service" -- LSB 1.3 draft

What should be done if the service supports the reload, but is not running?

-- 
  "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

Message #15 received at 152955@bugs.debian.org (full text, mbox, reply):

From: Wichert Akkerman <wichert@wiggy.net>

To: Henrique de Moraes Holschuh <hmh@debian.org>, 152955@bugs.debian.org

Subject: Re: Bug#152955: debian-policy: section 10.3.2 in force-reload should be more clear

Date: Mon, 15 Jul 2002 19:46:58 +0200

Previously Henrique de Moraes Holschuh wrote:
> Oh, quite the opposite.  It is *desirable* to have force-reload defined as
> "force a full configuration reload of the service, if it is running.  Fail
> otherwise".  But the code to do so is more complicated.

I don't see that begin complicated, the --test option for
start-stop-daemon should be everything you need.

> What should be done if the service supports the reload, but is not running?

Nothing IMNSHO.

Wichert.

-- 
  _________________________________________________________________
 /wichert@wiggy.net         This space intentionally left occupied \
| wichert@deephackmode.org            http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Message #20 received at 152955-quiet@bugs.debian.org (full text, mbox, reply):

From: Thomas Hood <jdthood@aglu.demon.nl>

To: 152955-quiet@bugs.debian.org

Subject: Re: #152955: force-reload semantics

Date: Fri, 25 Jun 2004 13:35:08 +0200

I think that the meaning of force-reload is pretty well established.
It means "reload if that's implemented, otherwise restart".

Yes, that means that the exit status is hard to interpret.  A status of
nonzero is returned if either reload or restart failed.  Thus, a status
of zero means either that the service was successfully reloaded or
that it was successfully restarted _or_ that reload is not implemented
and the service is not running.

If the caller wants a more useful exit status then he can call reload
or restart directly.
--
Thomas Hood

Message #25 received at 152955@bugs.debian.org (full text, mbox, reply):

From: Sven Mueller <sven@debian.org>

To: Debian Bug Tracking System <152955@bugs.debian.org>

Subject: debian-policy: Clarify force-reload, be LSB-compliant in doing so.

Date: Fri, 07 Jul 2006 18:30:12 +0200

[Message part 1 (text/plain, inline)]

Package: debian-policy
Version: 3.7.2.1
Followup-For: Bug #152955

According to LSB 3.1 (see [1]), force-reload should only restart the
service if it is already running. Therefore I suggest applying the
attached patch, which just adds "if it is already running" to the
force-reload description.

 	      <tag><tt>force-reload</tt></tag>
 	      <item>cause the configuration to be reloaded if the
 		  service supports this, otherwise restart the
-		  service.</item>
+		  service if it is already running.</item>
 	    </taglist>

[1]:
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

In general, it might be good to point to LSB specifications on init
scripts in policy 9.3.2 since LSB-compliance is a release goal for etch
anyway.

Sven

-- System Information:
Debian Release: 3.1
  APT prefers stable
  APT policy: (990, 'stable'), (400, 'experimental'), (90, 'testing'), (50, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.12-incase
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

-- no debconf information

[clarify-force-reload.diff (text/plain, attachment)]

Message #30 received at 152955@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Sven Mueller <sven@debian.org>, 152955@bugs.debian.org

Subject: Re: Bug#152955: debian-policy: Clarify force-reload, be LSB-compliant in doing so.

Date: Sun, 9 Jul 2006 00:13:21 -0300

On Fri, 07 Jul 2006, Sven Mueller wrote:
> Package: debian-policy
> Version: 3.7.2.1
> Followup-For: Bug #152955
> 
> According to LSB 3.1 (see [1]), force-reload should only restart the
> service if it is already running. Therefore I suggest applying the

This is directly against what we have implemented on Debian (even if it does
make sense to do it the LSB way).

Policy cannot be changed for this in a way to strong rule the LSB behaviour.
The vast majority of the initscripts need to be fixed to comply, first.

-- 
  "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

Message #35 received at 152955@bugs.debian.org (full text, mbox, reply):

From: Sven Mueller <sven@debian.org>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: 152955@bugs.debian.org

Subject: Re: Bug#152955: debian-policy: Clarify force-reload, be LSB-compliant in doing so.

Date: Mon, 10 Jul 2006 15:39:22 +0200

Henrique de Moraes Holschuh wrote on 09/07/2006 05:13:
> On Fri, 07 Jul 2006, Sven Mueller wrote:
> 
>>Package: debian-policy
>>Version: 3.7.2.1
>>Followup-For: Bug #152955
>>
>>According to LSB 3.1 (see [1]), force-reload should only restart the
>>service if it is already running. Therefore I suggest applying the
> 
> This is directly against what we have implemented on Debian (even if it does
> make sense to do it the LSB way).
> 
> Policy cannot be changed for this in a way to strong rule the LSB behaviour.
> The vast majority of the initscripts need to be fixed to comply, first.

I think we need something like a "policy to be", i.e. some document
which shows which changes _should_ go into the policy document as soon
as packages are fixed accordingly. Something that results in an
important (and thus not yet release-critical) bug if violated now and
will some day move to the real policy and will therefor result in a
release-critical bug at that time.

Currently, many necessary changes are delayed because they are not yet
implemented in most packages. Note that this bug is over three years old
and still not in policy. The reason is simple: Many maintainers don't
care to implement upcoming policy changes until they really are in policy.

Regarding this special case "force-reload" command to init.d scripts,
currently maintainers have the choice between two differen RC bugs:
1) Implement "force-reload" as a "restart" alias if "reload" is not
   available and violate LSB (which, according to the RMs means an RC
   bug).
2) Implement "force-reload" as a conditional "restart" alias only
   executed when the service is already running. This violates current
   policy wording and is therefor also an RC bug.
At the very least, I would suggest the following wording of the
"force-reload" description:

********************************************************************
<tag><tt>force-reload</tt></tag>
<item>cause the configuration to be reloaded if the service supports
this. If it doesn't support reloading, restart the service. Note that
the service should not get started if it wasn't already running.</item>
********************************************************************

This would cause non-LSB compliant behaviour to be a non-RC bug and make
LSB-compliant behaviour (which, BTW, is already implemented by _many_
init scripts) perfectly OK with policy.

After all, even if policy can't _mandate_ (must, required) the wanted
behaviour, it should not encourage behaviour that is supposed to get RC
buggy at some point in time.

Regards,
Sven.

Regards,
Sven

Message #40 received at 152955@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Sven Mueller <sven@debian.org>

Cc: 152955@bugs.debian.org

Subject: Re: Bug#152955: debian-policy: Clarify force-reload, be LSB-compliant in doing so.

Date: Mon, 10 Jul 2006 11:53:24 -0300

On Mon, 10 Jul 2006, Sven Mueller wrote:
> I think we need something like a "policy to be", i.e. some document
> which shows which changes _should_ go into the policy document as soon
> as packages are fixed accordingly. Something that results in an

We can have a "ongoing tasks" page in the wiki, and document where that page
is properly (i.e. at least an email to d-d-a).

That said, you are encouraged to propose a policy change that uses "may",
with a footnote that specifies that it will become a should and must when
the goals of "x% of packages" have been met (I suggest 80% and 98% for the
should and must thresholds).  This has been done before, and it works.

> and still not in policy. The reason is simple: Many maintainers don't
> care to implement upcoming policy changes until they really are in policy.

True, and AFAIK the usual way to fix this is do a patch run, followed by a
not-so-friendly prodding for the patch acceptance, and then a NMU to delayed
run.  It takes a few months for non-invasive changes, but it is not too
painful.  You end up with enough packages fixed to bump policy to a should
without much resistence, and after a few months, another patch run which can
be a lot more forceful will allow it to be brought to a must.

> 1) Implement "force-reload" as a "restart" alias if "reload" is not
>    available and violate LSB (which, according to the RMs means an RC
>    bug).

Did you specifically ask the RM if this *particular* violation of the LSB
is RC?  If you didn't, please clarify it with them.

> 2) Implement "force-reload" as a conditional "restart" alias only
>    executed when the service is already running. This violates current
>    policy wording and is therefor also an RC bug.

It is also non-trivial to implement.  "already running" is not always easy
to detect, and most initscripts are really just crap and don't even do the
start-stop-daemon dance properly.

Usually, if you are going to implement any such thing, it would be good to
implement "status" while at it.

One of the reasons I would get behind a massive workforce to switch to runit
(provided we *still* keep init.d scripts -- they will often be little more
than generic calls into runit helpers and a base initscript shell library
anyway) is that we'd fix all initscripts and maintainers would not have an
excuse to write bad ones anymore because it would be simpler to just do it
right (and runit makes it MUCH easier to track "running state" properly).

> At the very least, I would suggest the following wording of the
> "force-reload" description:
> 
> ********************************************************************
> <tag><tt>force-reload</tt></tag>
> <item>cause the configuration to be reloaded if the service supports
> this. If it doesn't support reloading, restart the service. Note that
> the service should not get started if it wasn't already running.</item>
> ********************************************************************

I can second such a change.

> After all, even if policy can't _mandate_ (must, required) the wanted
> behaviour, it should not encourage behaviour that is supposed to get RC
> buggy at some point in time.

That I agree with completely.

-- 
  "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

Message #47 received at 152955@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 152955@bugs.debian.org

Cc: pkg-systemd-maintainers@lists.alioth.debian.org, pkg-sysvinit-devel@lists.alioth.debian.org

Subject: Re: Bug#152955: force-reload should not start the daemon if it is not running

Date: Tue, 21 Apr 2015 09:48:32 +0200

Control: block 782993 by 152955

Hi,

the meaning of the "force-reload" action comes up again with systemd:

 - systemctl implements "force-reload" as documented by LSB, that is
   a service not running does *not* get started,
 - the init script integration maps "/etc/init.d/X force-reload" to
   "systemctl force-reload X",
 - but "service X force-reload" gets mapped to "systemctl X
   reload-or-restart" which *does* start a service not running before.

As I understand the discussion, Policy currently documents that
"force-reload" *should* start services not already running and is
contradicting LSB here; on the other hand initscripts behave in both
ways, at least back when the bug was discussed initially.

So I would like to re-raise the issue and propose the change suggested
by Sven Mueller[1] again:

| Regarding this special case "force-reload" command to init.d scripts,
| currently maintainers have the choice between two differen RC bugs:
| 1) Implement "force-reload" as a "restart" alias if "reload" is not
|    available and violate LSB (which, according to the RMs means an RC
|    bug).
| 2) Implement "force-reload" as a conditional "restart" alias only
|    executed when the service is already running. This violates current
|    policy wording and is therefor also an RC bug.
| At the very least, I would suggest the following wording of the
| "force-reload" description:
|
| ********************************************************************
| <tag><tt>force-reload</tt></tag>
| <item>cause the configuration to be reloaded if the service supports
| this. If it doesn't support reloading, restart the service. Note that
| the service should not get started if it wasn't already running.</item>
| ********************************************************************
|
| This would cause non-LSB compliant behaviour to be a non-RC bug and make
| LSB-compliant behaviour (which, BTW, is already implemented by _many_
| init scripts) perfectly OK with policy.

This makes the behaviour as defined by LSB and as implemented in systemd
a "should", making scripts behave consistent wheather systemd in used as
init or not.

Ansgar

  [1] <https://bugs.debian.org/152955#35>

Message #54 received at 152955@bugs.debian.org (full text, mbox, reply):

From: "USPS Home Delivery" <claude.david@ch.universmotri.ru>

To: 152955@bugs.debian.org

Subject: Notification status of your delivery (USPS 07938703)

Date: Thu, 26 Jan 2017 23:41:19 +0300

[Message part 1 (text/plain, inline)]

Dear Customer,



We can not deliver your parcel arrived at January 24.



Review the document that is attached to this e-mail!



Thank you,

Claude David,

USPS Chief Delivery Manager.

[Delivery-Receipt-07938703.zip (application/zip, attachment)]

Send a report that this bug log contains spam.