Debian Bug report logs - #904558
What should happen when maintscripts fail to restart a service

Full log

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

Received: (at 904558) by bugs.debian.org; 18 Oct 2018 08:55:35 +0000
From [email protected] Thu Oct 18 08:55:35 2018
X-Spam-Checker-Version: SpamAssassin 3.4.1-bugs.debian.org_2005_01_02
	(2015-04-28) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-13.6 required=4.0 tests=BAYES_00,FOURLA,
	HAS_BUG_NUMBER,TXREP autolearn=ham autolearn_force=no
	version=3.4.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 14; hammy, 150; neutral, 289; spammy,
	0. spammytokens: hammytokens:0.000-+--mcvittie, 0.000-+--McVittie,
	0.000-+--H*UA:1.10.1, 0.000-+--H*u:1.10.1, 0.000-+--debianspecific
Return-path: <[email protected]>
Received: from latin.grep.be ([2a01:4f8:140:52e5::2])
	by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.89)
	(envelope-from <[email protected]>)
	id 1gD45e-0006si-VH
	for [email protected]; Thu, 18 Oct 2018 08:55:35 +0000
Received: from smtp.office.bosa.be ([193.191.242.81] helo=gangtai.home.grep.be)
	by latin.grep.be with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.89)
	(envelope-from <[email protected]>)
	id 1gD45a-0007yO-2i; Thu, 18 Oct 2018 10:55:30 +0200
Received: from wouter by gangtai.home.grep.be with local (Exim 4.91)
	(envelope-from <[email protected]>)
	id 1gD45Y-0002qy-Dq; Thu, 18 Oct 2018 10:55:28 +0200
Date: Thu, 18 Oct 2018 10:55:28 +0200
From: Wouter Verhelst <[email protected]>
To: Simon McVittie <[email protected]>
Cc: [email protected], Margarita Manterola <[email protected]>,
	Sean Whitton <[email protected]>,
	Ian Jackson <[email protected]>,
	Tollef Fog Heen <[email protected]>,
	Anthony DeRobertis <[email protected]>,
	Gunnar Wolf <[email protected]>, Stuart Prescott <[email protected]>
Subject: Re: Bug#904558: What should happen when maintscripts fail to restart
 a service
Message-ID: <[email protected]>
References: <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email protected]>
X-Speed: Gates' Law: Every 18 months, the speed of software halves.
Organization: none
User-Agent: Mutt/1.10.1 (2018-07-13)

Hi,

On Wed, Oct 17, 2018 at 09:47:57PM +0100, Simon McVittie wrote:
> However, it leaves the default as "fail hard", which I'm not convinced
> is the most appropriate thing for systems that lack an experienced
> sysadmin (which are the systems where defaults matter most, because an
> inexperienced user is the least able to make an informed decision about
> where they should deviate from defaults).

I think that's where we disagree, so allow me to focus on that.

I think everyone would agree that when a service fails to (re)start upon
package installation or upgrade, that there is a problem and that this
problem needs to be reported in whatever way is most appropriate (if
not, we have a bigger disagreement than I thought and we need to take a
step back ;-)

The question that remains is "how". Currently, Debian has four ways of
informing a system administrator of such failures:

- Log a message to stdout and/or stderr. This is liable to scroll by
  unnoticed, and therefore is not a reliable way to inform the system
  administrator. For that reason, I don't think it's a good idea.
- Log a message to syslog and/or the systemd journal. This will not
  scroll by, but relies on the system administrator to actively hunt for
  problems in system logs, which they probably won't do unless and until
  they notice that the daemon isn't running anymore (and by that time it
  may be too late).
- Produce a debconf error note. This is mildly better than the above
  two, since debconf error notes are shown at highest priority, and
  therefore will only be hidden if debconf is configured to be
  noninteractive; in that case, debconf will send an email to root. On
  systems without a configured MTA, this will not help; and for daemons
  where failure to restart is a catastrophic that needs to be resolved
  ASAP, such as sshd, this might not be desirable.
- Exit from postinst with nonzero exit state. This is unlikely to be
  missed by system administrators; however, it has several disadvantages
  that were pointed out by other people during this discussion.

I think it is perfectly fine to have the TC say that "failures to
restart a service must be reported, either by exiting nonzero, or by
another appropriate action", without going in detail what those other
actions could be.

> policy-rc.d also has some practical integration issues. It normally relies
> on putting an unpackaged file in /usr/sbin (unless you have installed
> policyrcd-script-zg2), and it's common for tools like debootstrap and
> debian-installer to create and delete policy-rc.d to suppress service
> startup while carrying out bootstrap operations. One Debian derivative
> that I'm involved in (SteamOS) is *meant* to have a policy-rc.d, but we
> recently discovered that it has always been deleted at the end of the
> debian-installer run, and so doesn't exist in practice.

I think that problem is not something that should be resolved by this
discussion.

I'll readily admit that I did not actually test any of the suggestions I
made wrt policy-rc.d. There are other issues with it too; I'm thinking
of filing a wishlist bug to have it replaced by something better.

On top of that, policy-rc.d has alwyas irked me as a bit of an awkward
interface; it is the only type of Debian-specific configuration that
does not go into /etc, but for which you need to write a script in
/usr/sbin. This is confusing, as shown by debian-installer removing it
unconditionally. In an ideal world, the policies currently implementable
through policy-rc.d should be configuration snippets in a run-parts
style directory. The "just drop a script somewhere" idea is a
poorly-defined interface which is inflexible and inappropriate for the
purpose of a distribution, but "policy-rc.d should be replaced by
something better" is not an appropriate response to the question "what
should happen when a service fails to restart in postinst".

Also related to this problem is what happens with postinst failing for
other reasons than "the daemon doesn't restart". While that is probably
the most likely reason for postinst failures today, it is by no means
the only one; so if you say "postinst failing because of daemon restart
failing" is something that should not ever happen, I think you should
then also make guidelines as to when, exactly, a postinst should be
allowed to fail (and muck up the whole system).

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Send a report that this bug log contains spam.