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

[Daniel Pocock]

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.

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

[Sam Hartman]

> "Daniel" == Daniel Pocock  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

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

[Henrique de Moraes Holschuh]

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 

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

[Daniel Pocock]

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.