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.
