Bug#904558: What should happen when maintscripts fail to restart a service
Stuart Prescott writes ("Bug#904558: What should happen when maintscripts fail to restart a service"):
> Ian Jackson wrote:
> > When I wrote that, it didn't occur to me that anyone would think that
> > a failure by a postinst script to perform an intended operation should
> > be treated any other way than a failure of the postinst script.
>
> That was perhaps also written before we started to realise that maintainer
> scripts are actually best avoided
I don't think that makes any difference.
Whether things are implemented by handcoded code in postinst, or
dh-generated templatey postinst, or some kind of declarative system,
is important for manageability of our codebase etc. etc.
But it doesn't have any bearing on what the error handling should be
like. Any kind of declarative or automatic system or whatever ought
to have similar error handling: failure to perform an intended
function is an error and should not be ignored.
See for example the handling of errors which occur during trigger
processing.
One of the things that I am most proud of in dpkg is the comprehensive
and thoughtful error behaviours.
> > If the postinst fails, then the user has the opportunity to fix the
> > root cause and rerun dpkg-source --configure --pending. That will
> > then repair the system completely.
>
> \u2026 causing a snowball of errors in an awkward half-upgraded
> environment is nasty.
>
> The problem comes when you don't yet have the right tools installed to be
> able to fix the problem. We see that scenario often enough in #debian where
> someone has a failed upgrade and we try to collect more information via
> pastebinit, strace, traceroute, netcat, gdb, etc; we frequently discover
> that the relevant tool isn't installed and because apt is sufficiently
> unhappy about broken packages and a half-completed upgrade, you can't ask it
> to install the tool at that point in time.
This is a bug in apt, plain and simple.
Of course it is a design error, but that does not make it a bug.
There is nothing conceptually incoherent in installing strace while
cupsd and its dependencies are broken. dpkg will happily do it.
I agree that in the absence of a fix to this, some workarounds would
be good. Perhaps
dpkg --configure --force-postinst-fail broken-package
?
> In the upgrade scenario, while you're trying to fix one particular
> problem, you're also in a completely untested half-upgraded
> situation and so latent bugs in any number of other tools may also
> be exposed.
dpkg is designed so that it is in general only the _configuration_ of
other packages which is blocked, not their actual upgrade. So
hopefully you should be in a reasonably coherent state.
> So while ignoring errors is wrong, so is making it harder to fix them. This
> isn't a question of absolutes.
As I say I think it is a bug in apt that when you have an error, apt
makes it hard to fix the error by insisting that you can't do anything
(even install diagnosis tools) until you have fixed the error (which
you can't do).
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: