Bug#801065: Documenting how to not fail postinst on service fails to start
* Steve Langasek <vorlon@debian.org> [230214 13:09]:
> On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote:
> > * Steve Langasek <vorlon@debian.org> [230212 00:03]:
> > > FWIW I think that it's the wrong thing to do if the "circumstances" include
> > > reverse-dependencies on the package which expect to interact with the
> > > service the package provides, as these packages may themselves do such
> > > interaction in the maintainer script, resulting in cascading damage.
>
> > > And the decision for whether there are reverse-dependencies on your package
> > > is non-local and asynchronous.
>
> > > Therefore I think it's always wrong for a package's postinst to exit 0 if:
>
> > > - it ships a service,
> > > - it is a new install or an upgrade on a system where the service was
> > > previously started successfully, and
> > > - the service fails to start in the postinst.
>
> > I have to strongly disagree with this. Suppose package A ships a
> > service, and package B depends on A and requires A's service to be
> > running in order for package B to be useful. If I install A and disable
> > its service, and then install B, I would be very disappointed if B's
> > postinst script failed and left B in what dpkg considers an unconfigured
> > state.
>
> > Succeeding the install and requiring the user to manually run some
> > documented configuration steps is _so_ much more user friendly than
> > leaving a broken package (from dpkg's POV). I intentionally disabled A,
> > so when I want to use B, I will take the necessary steps. I would
> > expect that attempting to use B without completing the configuration
> > would produce a useful error message.
>
> Up until now the conversation has been about the semantics of exit codes for
> package A's maintainer script.
>
> You are now arguing that a package *B* is not allowed to fail on install if
> the conditions for its full configuration have not been met.
>
> And I absolutely disagree! Your rationale that it's user-unfriendly to
> leave a package in an unconfigured state, if followed to its logical
> conclusion, applies to *any* package. We might as well not care about
> postinst exit codes at all!
You are right, I went off on a tangent. I agree that if a package
installation script is unable to leave the package's own configuration
in a "usable" state (barring explicit misconfiguration prior to upgrade
by the sysadmin), that it should fail.
The condition in the original bug report was that the problem that
prevented the service from starting or restarting was orthogonal to
anything the installation script was doing. In that case, the
installation script will leave the filesystem in an identical state
regardless of whether starting the service succeeds or fails. The
package is installed and perfectly usable if and when the outside
condition, unrelated to the package installation, is fixed.
In these cases, there is nothing more that the installation scripts can
or should do, so there is no need to leave the package in a dpkg
half-configured state.
I think the real problem is that the ideas of "configured" and "running"
have been conflated specifically for services. The same type of issue
with a user program would not cause a failure of installation.
The part of your message that I disagree with is
> > > - the service fails to start in the postinst.
This implies that "the service is running" is part of "the service is
configured", which is where I disagree.
...Marvin
Reply to: