Bug#801065: service failures should not fail dpkg installation: https://lists.debian.org/debian-devel/2015/09/msg00532.html

--c0285545d7402a2a18f782bcc25a54280655b2581246a6247c825d966e17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

hello,

On Thu, 23 Feb 2023 10:41:41 -0700 Sam Hartman <[email protected]> wrote:
> >>>>> "Wouter" =3D=3D Wouter Verhelst <[email protected]> writes:
>=20
>     Wouter> On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote=
:
>     >> > > > - the service fails to start in the postinst.
>     >>=20
>     >> This implies that "the service is running" is part of "the
>     >> service is configured", which is where I disagree.
>=20
>     Wouter> What Steve said is that if
>=20
>     Wouter> - The service fails to start, *AND* - The service was
>     Wouter> previously running (or this is a new install)
>=20
>     Wouter> *THEN*
>=20
> I think I disagree with Steve that postinst should fail on a new
> install.

devref guidance, section 6.9.4. "Specific types of packages" has some recen=
tly
added guidance but is agnostic as to whether postinst should fail:

 * Packages providing services ("daemons") should be functional on a
  fresh install, to the extent that that is possible without
  compromising security [..]

> I think that failing postinst on a failed restart during upgrade is more
> commonly the correct answer than ignoring the issue.
> I also agree that it should be RECOMMENDED that if the restart fails
> that be flagged to the admin somehow.
>=20
> But in the case of krb5 and I think a few other services, there is not a
> good way to detect at install time *whether* the service is sufficiently
> configured to run from a systemd unit.  I could for example include a
> ConditionPathExists on the Kerberos database.  That's wrong though
> because in an LDAP deployment there will be no such database.

my reading of the bug log is that the guidance needs to be nuanced. here's =
an
attempt to reconcile the various views in the discussion:

	Package maintainers are expected to apply judgment with regards to which
	postinst behavior is more appropriate to any given package. Here is some
	generic guidance:

	1. a service failing to start upon a fresh install should, in general,
	   fail postinst, if
	  1.1 the service configuration is straightforward and can be reasonably
	      expected to work as-is in typical Debian setups
	  1.2 the service has no external dependencies (e.g. a database which
	      may be not configured yet, or unreachable at the time of the
	      install)

	2. a service failing to restart upon an upgrade should, in general, fail
	  postinst if
	  2.1 postinst can verify with high confidence that the service was
	      running prior to the restart (which may not always be feasible)
	  2.2 the service has no external dependencies or postinst can verify
	      that they are functional
	  2.3 the service configuration has not changed in backwards
	      incompatible ways between the old and new package versions

fwiw I wonder whether this would be of much use. "typical Debian setups" is
ambiguous. verifying whether a remote service is unreachable is not always
straightforward. "backwards incompatible" is not always black and white.

thanks,
serafi

--c0285545d7402a2a18f782bcc25a54280655b2581246a6247c825d966e17
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA2RWqo7IwLCLSFYbT59tVQ7WEioFAmoZ/AMACgkQT59tVQ7W
EiqvNhAA23YTidw65bF6bE6CjHj5a9ngY4hP1Vo7VoXL8gvhxOgZogWrDgMyYqc0
QspiXDykzmC5w7j420I6hJ3pidbs4fW/Ko/LIrvUFXExw0xLZtAaIdHqaZbkbv/b
++x/Uwug3szr0PoRm2XecDlOJ6zCboiAKRalv+MrHNGG4jVQI76xgRG9s+S/kcjW
OkqKBII9vn/yJcXeC2UcyADcALbFtCPvA5bKs3IPj6W5Crvia5I2AOUNRvZOvqlq
VXpstmDztqo+0I2zXh/dXrS2GMx0G8zO0UeFghjPLvJmJ27HTcJ0mrN67KiT6Hln
bbAWobDIxxnXcU3od2dhJeH52EW/p3Fqg6+Pk2bXXWrmQgHnBpaD05dxWWPbuAdN
3m3RMM8OoaSpCoscEeEsa+8gkiBBJR73RXd5eww0d9z17t+nLXsxOH8vm7LrmYJj
7dgBDsuaf5leTXSsEFDQLwBQ//BtYGskfB1LVSoIRO7DpOX7mnM13HUhHgyIXi6u
ct+Jus3yh35WDz7xmAMI90MGBIUGQX0OewfvzOYUrtYb7lLDdj3CeCJwyu5cL8qN
tLmWkSlQm/AhoJg0hKXpJO1f1K3Wn/KM6ulEKEG1/CpupxTBZtvm4g4hVBjfFYUR
HKTanSV3nIqL/maYGQdv3yTlx2RUaOZk2EoOj7k6yeO6QxlesHs=
=uoRA
-----END PGP SIGNATURE-----

--c0285545d7402a2a18f782bcc25a54280655b2581246a6247c825d966e17--