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

[Daniel Pocock <daniel@pocock.pro>]

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.