hello, On Thu, 23 Feb 2023 10:41:41 -0700 Sam Hartman <[email protected]> wrote: > >>>>> "Wouter" == Wouter Verhelst <[email protected]> writes: > > Wouter> On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote: > >> > > > - 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. > > Wouter> What Steve said is that if > > Wouter> - The service fails to start, *AND* - The service was > Wouter> previously running (or this is a new install) > > Wouter> *THEN* > > 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 recently
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.
>
> 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
signature.asc
Description: PGP signature
