Debian Bug report logs - #802501
init script failures during postinst and related scripts

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Daniel Pocock <[email protected]>

To: [email protected]

Subject: init script failures during postinst and related scripts

Date: Tue, 20 Oct 2015 18:08:23 +0200

Package: debian-policy
Severity: important

If postinst or one of the other scripts does a service restart and the
restart operation fails, should the postinst abort or should it mask the
error, continue and return success?

If it continues, is there any other convention for reporting the
problem, e.g. stderr?

Looking at s9.3.3 "Interfacing with the initscript system"

https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3

it doesn't explicitly state what should happen.

Message #10 received at [email protected] (full text, mbox, reply):

From: Henrique de Moraes Holschuh <[email protected]>

To: [email protected]

Subject: Re: Bug#802501: init script failures during postinst and related scripts

Date: Thu, 22 Oct 2015 08:26:57 -0200

On Tue, Oct 20, 2015, at 14:08, Daniel Pocock wrote:
> If postinst or one of the other scripts does a service restart and the
> restart operation fails, should the postinst abort or should it mask the
> error, continue and return success?

Whatever makes more sense for that particular service, as in "safer". 
And by safer I do mean: smaller chance of aggravating already present
damage, causing security issues, or data loss".

> If it continues, is there any other convention for reporting the
> problem, e.g. stderr?

You report errors and warnings to stderr, yes.  For sysvinit there is a
shell API that can be used for that.  Systemd might have its own
convention for unit files.

A better way to get error/warning information to the user would be
welcome, but it needs to be properly planned (headless nodes, unattended
upgrades, desktops with crippled local mail delivery/routing, etc).

-- 
  "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 de Moraes Holschuh <[email protected]>

Message #18 received at [email protected] (full text, mbox, reply):

From: Daniel Pocock <[email protected]>

To: Henrique de Moraes Holschuh <[email protected]>, [email protected], [email protected]

Subject: Re: Bug#802501: init script failures during postinst and related scripts

Date: Fri, 23 Oct 2015 18:02:17 +0200

On 22/10/15 12:26, Henrique de Moraes Holschuh wrote:
> On Tue, Oct 20, 2015, at 14:08, Daniel Pocock wrote:
>> If postinst or one of the other scripts does a service restart and the
>> restart operation fails, should the postinst abort or should it mask the
>> error, continue and return success?
> 
> Whatever makes more sense for that particular service, as in "safer". 
> And by safer I do mean: smaller chance of aggravating already present
> damage, causing security issues, or data loss".
> 


Ok, I thought about this some more in terms of what should be in the
policy document

It is a situation of minimizing damage: if one of the pre* or post*
scripts fails during a big dist-upgrade, it sometimes leaves the system
in a very bad state.  Being able to "apt-get dist-upgrade" the same box
every 2 years is one of the beautiful things about Debian that people
respect.

So, I feel that by default, if errors occur when trying to stop or start
services, the policy should encourage people to write the scripts in
such a way that they continue anyway.  If somebody really cares about
whether a particular daemon is running at the end of their upgrade, they
should be monitoring it with Nagios or some other tool.  These scripts
are primarily responsible for ensuring that the files on the system are
in a consistent state.

That is the default attitude people should take, but with exceptions:

- stopping daemons: if the maintainer scripts have to make some changes
to data (e.g. changing a schema), they should not attempt to do so if
the attempt to stop the daemon fails.  In this case, the daemon should
be stopped in the preinst of the new version of the package.  If the
preinst script can't stop the daemon it should abort.



>> If it continues, is there any other convention for reporting the
>> problem, e.g. stderr?
> 
> You report errors and warnings to stderr, yes.  For sysvinit there is a
> shell API that can be used for that.  Systemd might have its own
> convention for unit files.
> 
> A better way to get error/warning information to the user would be
> welcome, but it needs to be properly planned (headless nodes, unattended
> upgrades, desktops with crippled local mail delivery/routing, etc).
> 


Thanks, I'm aware of the way the init scripts should use log_warning_msg
and friends.  I was only asking about any specific logging or reporting
that the pre* and post* scripts should do, maybe that should also be
mentioned in this section of the policy and included in the example.

Message #23 received at [email protected] (full text, mbox, reply):

From: Sam Hartman <[email protected]>

To: Daniel Pocock <[email protected]>

Cc: Henrique de Moraes Holschuh <[email protected]>, [email protected], [email protected]

Subject: Re: Bug#802501: init script failures during postinst and related scripts

Date: Fri, 23 Oct 2015 12:24:22 -0400

>>>>> "Daniel" == Daniel Pocock <[email protected]> writes:


I agree.
I think Henrique's advice is correct as far as it goes.
However as a distribution, I think we should explicitly encourage people
to consider the consequences on dist-upgrade and other operations.
For some daemons, where the system is likely to be totally broken,
having the installation break is probably the right answer.
If  the postinst is reasonably convinced that the problem is going to
make additional installation difficult (for example root partition or
/usr full) then failing also make sense.

However, for the vast majority of daemons, breaking installation is far
worse than a silent failure to restart.

I believe that this is a significant problem in Debian today andsystemd
makes this  a
significant regression of jessie over wheezy.
(Here I'm not saying systemd is bad; it does a better job of reporting
errors to postinst.; it just gives us behavior that sucks for our users)

--Sam

Message #48 received at [email protected] (full text, mbox, reply):

From: Sean Whitton <[email protected]>

To: [email protected]

Cc: [email protected], [email protected]

Subject: Concluding "What should happen when maintscripts fail to restart a service?"

Date: Thu, 20 Jun 2019 16:11:14 +0100

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

tag 802501 + wontfix
user [email protected]
usertag 802501 = normative stalled
thanks

Hello,

In #904558 I asked the T.C. for advice about how to move #802501
forward.  Their ultimate response was to recommend that a working group
of developers come up with some method, other than exiting nonzero, for
a maintscript to indicate that it failed to restart services.  Let me
take this opportunity to thank all those who were involved in #904558.

In this message, I seek to explain my understanding of what the closing
of T.C. bug #904558 means for debian-policy bug #802501, and those
merged with it.  Apologies for the length.  I wanted this general sort
of reasoning to be recorded somewhere for reference in future
discussions.

~ ~ ~

When the Policy Changes Process fails to establish consensus, we have a
few options.  If we think that consensus hasn't been established only
because no-one has volunteered to come up with an adequately detailed
response to the problem uncovered by the filing and discussion of the
bug, and the bug has been open for a while with no evidence of anyone
working on it, we (the Policy Editors) will often just close the bug.
We don't want such things to stick around, clogging up the list of open
issues in a way that's demotivating.  This is the 'obsolete' usertag.

If we think that consensus hasn't been established because there are
good arguments on all sides, but we (the Policy Editors) additionally
think that argument to determine the very best solution is less
important right now than settling on one of the possible solutions
rather than remaining in further discussion, then we can refer the bug
to the T.C. to make a call between the competing options.  This was, I
think, the intended purpose of the 'ctte' usertag, but we haven't been
using it.

Finally, if we don't want to refer the bug to the T.C. -- generally
because it's not important enough -- but we think that closing the bug
would be counterproductive because someone else will just open a new bug
raising the same issue again at some near point in time, we can just
leave the bug open, as a kind of placeholder to hopefully reduce the
number of duplicate bugs filed.  I just added a 'stalled' usertag for
this case.

The 'obsolete', 'ctte' and 'stalled' usertags are meant to be used in
addition to the 'wontfix' tag.

~ ~ ~

In #904558, I did not ask the T.C. to rule on what maintscripts should
do when they fail to restart a service.  Rather, I asked them to weigh
in on the decision between the options described above, given that the
Policy Changes Process had failed to achieve consensus.  However, in the
message closing #904558, the T.C. indicated that they declined to issue
a ruling about what maintscripts should do when they fail to restart a
service.  So the second option described above, corresponding to the
'ctte' usertag, has been taken off the table.

That leaves us with the question of whether to leave #802501 open, in
the absence of the possibility of closing it by having the T.C. make a
call.  Given that this bug has already been filed (at least) twice, I
think it would be best for us to leave it open.  So I'm tagging
wontfix+stalled.

~ ~ ~

In filing #904558, I made an alternative suggestion to the above:

> As a Policy delegate I want to move this issue along, and I can see
> three ways of doing that:
>
> 1. write a patch to explicitly state in Policy that what happens when a
>    service (re)start fails in a maintscript is left up to package
>    maintainer discretion, and close the bugs
> [...]

I no longer think this would be useful enough to have in Policy, but I'd
like to hear from anyone who disagrees.

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #55 received at [email protected] (full text, mbox, reply):

From: Gunnar Wolf <[email protected]>

To: Sean Whitton <[email protected]>

Cc: [email protected], [email protected], [email protected]

Subject: Re: Concluding "What should happen when maintscripts fail to restart a service?"

Date: Thu, 20 Jun 2019 11:18:46 -0500

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

Hello Sean,

> In #904558 I asked the T.C. for advice about how to move #802501
> forward.  Their ultimate response was to recommend that a working group
> of developers come up with some method, other than exiting nonzero, for
> a maintscript to indicate that it failed to restart services.  Let me
> take this opportunity to thank all those who were involved in #904558.
> 
> In this message, I seek to explain my understanding of what the closing
> of T.C. bug #904558 means for debian-policy bug #802501, and those
> merged with it.  Apologies for the length.  I wanted this general sort
> of reasoning to be recorded somewhere for reference in future
> discussions.

Thank you for providing this framing and for helping us (me, at
least!) better understand the circumstances of your bug filing. Quite
probably, I should have probably read #802501 during the #904558
discussion (and it's a very short bug FWIW), but didn't. Understanding
the bug follow-up policy of the Policy Editors makes me more at ease
with what we (TC) decided — We were not the first ones to fail to find
an always-good solution :-|

Now, I would more than welcome this bugs to be pushed to the right
areas: To d-devel, or to a new, specialized working group tackling the
issue. Both in the bugs and in our discussions, it is often repeated
(quoting here Sam, from #802501) «as a distribution, I think we should
explicitly encourage people to consider the consequences on
dist-upgrade and other operations». Inconsistently failing is *not*
OK, and nobody implied it that way...

So,

> The 'obsolete', 'ctte' and 'stalled' usertags are meant to be used in
> addition to the 'wontfix' tag.
> 
> ~ ~ ~
> 
> In #904558, I did not ask the T.C. to rule on what maintscripts should
> do when they fail to restart a service.  Rather, I asked them to weigh
> in on the decision between the options described above, given that the
> Policy Changes Process had failed to achieve consensus.  However, in the
> message closing #904558, the T.C. indicated that they declined to issue
> a ruling about what maintscripts should do when they fail to restart a
> service.  So the second option described above, corresponding to the
> 'ctte' usertag, has been taken off the table.
> 
> That leaves us with the question of whether to leave #802501 open, in
> the absence of the possibility of closing it by having the T.C. make a
> call.  Given that this bug has already been filed (at least) twice, I
> think it would be best for us to leave it open.  So I'm tagging
> wontfix+stalled.

I want to interpret this wontfix+stalled, and the TC answer ("The
Technical Committee does not engage in design of new proposals and
policies") don't mean this problem will just lay dormant and unsolved
forever. As Marga said in her mail closing this bug, «While we
recognize that this is a problem worth fixing, this is not something
that we can fix as a body and need the help of the Developers to do
it.»

I want to insist on our recommendation to create a work group of
developers to tackle this issue. Maybe we can start it off as a BoF
session in DC19?

[signature.asc (application/pgp-signature, inline)]

Message #60 received at [email protected] (full text, mbox, reply):

From: Sean Whitton <[email protected]>

To: Gunnar Wolf <[email protected]>

Cc: [email protected], [email protected]

Subject: Re: Concluding "What should happen when maintscripts fail to restart a service?"

Date: Fri, 21 Jun 2019 14:36:05 +0100

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

Hello Gunnar,

On Thu 20 Jun 2019 at 11:18am -0500, Gunnar Wolf wrote:

>> ~ ~ ~
>>
>> In #904558, I did not ask the T.C. to rule on what maintscripts should
>> do when they fail to restart a service.  Rather, I asked them to weigh
>> in on the decision between the options described above, given that the
>> Policy Changes Process had failed to achieve consensus.  However, in the
>> message closing #904558, the T.C. indicated that they declined to issue
>> a ruling about what maintscripts should do when they fail to restart a
>> service.  So the second option described above, corresponding to the
>> 'ctte' usertag, has been taken off the table.
>>
>> That leaves us with the question of whether to leave #802501 open, in
>> the absence of the possibility of closing it by having the T.C. make a
>> call.  Given that this bug has already been filed (at least) twice, I
>> think it would be best for us to leave it open.  So I'm tagging
>> wontfix+stalled.
>
> I want to interpret this wontfix+stalled, and the TC answer ("The
> Technical Committee does not engage in design of new proposals and
> policies") don't mean this problem will just lay dormant and unsolved
> forever. As Marga said in her mail closing this bug, «While we
> recognize that this is a problem worth fixing, this is not something
> that we can fix as a body and need the help of the Developers to do
> it.»
>
> I want to insist on our recommendation to create a work group of
> developers to tackle this issue. Maybe we can start it off as a BoF
> session in DC19?

My reading of the conclusion to #904558 is that the recommendation to
form a working group is a recommendation that can be directed only to
the developer body as a whole, not to the Policy process.  That's
because actually implementing in the archive some new mechanism for
maintscripts is a prerequisite to any Policy change requiring packages
to use that new mechanism.  In other words, what the working group would
be tasked with doing is beyond the scope of the Policy process.  We do
design work as part of the Policy process, but we don't write code.

Assuming that the T.C.'s recommendation is the right way to proceed
here, and someone doesn't come up with any other way to unblock things,
the wontfix+stalled status will remain until and unless the working
group actually forms, designs and implements something, and starts using
it in the archive.  There is no role for the Policy process (and thus no
role for the Policy Editors qua Policy Editors) until that occurs.

So, by all means insist on the recommendation, but so far as I can tell
that's something which does not involve either the Policy process or the
T.C., but simply the body of Debian contributors qua contributors.

Stepping back a bit, tagging this bug wontfix+stalled is part of the
broader attempts, in which the Policy Editors are engaged, to more
sharply delineate the boundaries of the Policy process.  We want to get
to the point where the only bugs that we have listed are either
highly actionable, or tagged wontfix.  For a bug to be highly actionable
is for it to be the case that someone with enough time and background
knowledge can sit down, think through the problem, and come up with at
least a first version of a change proposal.

I think that a large number of very-difficult-to-action bugs strongly
discourages people from getting involved.  It makes Policy seem like a
sprawling, unmanageable morass of difficult problems.  That isn't how
things are, because while there are indeed a lot of hard problems, they
are largely independent of each other, and tackling individual
debian-policy bugs really does improve Debian.  However, it is much
harder to see that when half of the open bugs are more than five years
old yet not tagged wontfix.

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #65 received at [email protected] (full text, mbox, reply):

From: Gunnar Wolf <[email protected]>

To: Sean Whitton <[email protected]>

Cc: [email protected], [email protected]

Subject: Re: Concluding "What should happen when maintscripts fail to restart a service?"

Date: Fri, 21 Jun 2019 09:54:11 -0500

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

Sean Whitton dijo [Fri, Jun 21, 2019 at 02:36:05PM +0100]:
> My reading of the conclusion to #904558 is that the recommendation to
> form a working group is a recommendation that can be directed only to
> the developer body as a whole, not to the Policy process.  That's
> because actually implementing in the archive some new mechanism for
> maintscripts is a prerequisite to any Policy change requiring packages
> to use that new mechanism.  In other words, what the working group would
> be tasked with doing is beyond the scope of the Policy process.  We do
> design work as part of the Policy process, but we don't write code.
> 
> Assuming that the T.C.'s recommendation is the right way to proceed
> here, and someone doesn't come up with any other way to unblock things,
> the wontfix+stalled status will remain until and unless the working
> group actually forms, designs and implements something, and starts using
> it in the archive.  There is no role for the Policy process (and thus no
> role for the Policy Editors qua Policy Editors) until that occurs.
> 
> So, by all means insist on the recommendation, but so far as I can tell
> that's something which does not involve either the Policy process or the
> T.C., but simply the body of Debian contributors qua contributors.

I completely agree with you - My idea to kickstart this at DC19 is not
for TC and Policy Editors leading a session, but rather us (as
individuals) expressing the issue at a BoF trying to get more eyeballs
(and, more important, more brains) on it.

> Stepping back a bit, tagging this bug wontfix+stalled is part of the
> broader attempts, in which the Policy Editors are engaged, to more
> sharply delineate the boundaries of the Policy process.  We want to get
> to the point where the only bugs that we have listed are either
> highly actionable, or tagged wontfix.  For a bug to be highly actionable
> is for it to be the case that someone with enough time and background
> knowledge can sit down, think through the problem, and come up with at
> least a first version of a change proposal.
> 
> I think that a large number of very-difficult-to-action bugs strongly
> discourages people from getting involved.  It makes Policy seem like a
> sprawling, unmanageable morass of difficult problems.  That isn't how
> things are, because while there are indeed a lot of hard problems, they
> are largely independent of each other, and tackling individual
> debian-policy bugs really does improve Debian.  However, it is much
> harder to see that when half of the open bugs are more than five years
> old yet not tagged wontfix.

Right. This is a bug where I was quite happy that the TC decided to
declare it outside of its functions - And it is just fitting that it's
outside the Policy as well. We don't have a commonly implemented
practice to document / show / follow. This should go to the developer
body at large.

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.