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

Package: debian-policy; Maintainer for debian-policy is Debian Policy Editors <[email protected]>; Source for debian-policy is src:debian-policy (PTS, buildd, popcon).

Reported by: Daniel Pocock <[email protected]>

Date: Tue, 20 Oct 2015 16:09:01 UTC

Severity: normal

Tags: wontfix

Merged with 780403

Full log


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

Received: (at 802501-quiet) by bugs.debian.org; 23 Oct 2015 16:02:44 +0000
From [email protected] Fri Oct 23 16:02:44 2015
X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02
	(2014-02-07) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 required=4.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HAS_BUG_NUMBER,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,
	SPF_PASS autolearn=ham autolearn_force=no
	version=3.4.0-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 13; hammy, 150; neutral, 131; spammy,
	0. spammytokens: hammytokens:0.000-+--systemd, 0.000-+--distupgrade,
	0.000-+--dist-upgrade, 0.000-+--nagios, 0.000-+--H*UA:31.0
Return-path: <[email protected]>
Received: from mail1.trendhosting.net ([195.8.117.5])
	by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.84)
	(envelope-from <[email protected]>)
	id 1Zpeni-0000fy-NX
	for [email protected]; Fri, 23 Oct 2015 16:02:44 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail1.trendhosting.net (Postfix) with ESMTP id 861451509D;
	Fri, 23 Oct 2015 17:02:38 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pocock.pro; s=mail;
	t=1445616158; bh=MEP7rCYpLOfRKxdT/lYBmb0Z0ZPaOGoTXUNjB/o+LVo=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=nimTcjDzw3sQ2rlqCzLd31DWf2VoyyLNQzcJ6lDWNPbfXikO5V1oXOx0IECYrIb2Z
	 kK26E4YHnjFvkmabwWrdbk7gZRl1zY0Rpwqm342uQngks8VV7SXFhjI7wgQlV6jpVx
	 xIBspWFTkN275n1+dxWH9NuUjfXZ3xdMmQfi0hfw=
Received: from mail1.trendhosting.net ([127.0.0.1])
	by localhost (thp003.trendhosting.net [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id DCryteQb0_qb; Fri, 23 Oct 2015 17:02:18 +0100 (BST)
Message-ID: <[email protected]>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pocock.pro; s=mail;
	t=1445616138; bh=MEP7rCYpLOfRKxdT/lYBmb0Z0ZPaOGoTXUNjB/o+LVo=;
	h=Date:From:To:Subject:References:In-Reply-To:From;
	b=BwzAZdhzYkaCjJmrIn8fKCNGy7Rec/fQcUr+7j1QOSNEL3DUpSoELeRHRO/pcXmGn
	 u4gHVdudxtJbWIp7uveS2NGLvOxRUJ7yeqGEeZ9Zdd5gkD5EnqjF18oX25b18AKmm/
	 TAwypDTivoxLD5GYBqEhVpQYgDfTEzTo7b7RUBy0=
Date: Fri, 23 Oct 2015 18:02:17 +0200
From: Daniel Pocock <[email protected]>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: Henrique de Moraes Holschuh <[email protected]>, 
 [email protected], [email protected]
Subject: Re: Bug#802501: init script failures during postinst and related
 scripts
References: <[email protected]> <1445509617.1740336.417210377.5AC9CD79@webmail.messagingengine.com>
In-Reply-To: <1445509617.1740336.417210377.5AC9CD79@webmail.messagingengine.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

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.



Send a report that this bug log contains spam.


Debian bug tracking system administrator <[email protected]>. Last modified: Thu May 15 16:23:52 2025; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU General Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.