enterprise-support team mailing list archive

[Robie Basak <1818431@xxxxxxxxxxxxxxxxxx>]

Thank you for taking the time to report this bug and helping to make
Ubuntu better.

I accept that it is a problem that situations can arise when a service
will fail to start (for example by system misconfiguration, or as a
result of necessary changes to local customisations triggered by a
release upgrade), and this causes apt to fail when maintainer scripts
fail to start such a service.

The underlying principle that leads to this behaviour is the long
standing philosophy that if a user installs a package, it is presumed
that the user intends to use it, and so after installation is complete
the service for which the user installed the package should be active
with sensible defaults. This is why packages that provide services
configure and start them by default.

As Andreas points out, you can control this behaviour using policy-rc.d,
which is the mechanism provided to allow sysadmin override of service
control behaviour.

In my view this policy causes difficulties in three cases:

1) On servers, a package's default behaviour often isn't useful, and it
is expected that the user is a sysadmin who will configure the daemon.
In this case, an automatic service start on package install just gets in
the way. In my opinion, management tools (chef, puppet, ansible, etc)
should therefore automatically use policy-rc.d on Debian and derivatives
to provide more sensible default behaviour in their automation case, but
they currently do not. You mention saltstack so that sounds like this
problem applies here. This point however is a tangent to your assertions
about service and package manager integration.

2) On server packages, it is fairly common for users to end up in a
misconfigured state where a service cannot be started. This causes
problems on package upgrades, since sometimes a user isn't impacted by
the service start failure, but does get impacted by a subsequent service
restart attempt on package upgrade unwinding through to an apt failure.

3) On release upgrades, intentional changes to how packages operate may
invalidate previous local customisations, breaking services until the
customisations are updated manually. This can be mitigated somewhat by
smarter package upgrade paths, but fundamentally cannot be eliminated in
the general case.

I therefore accept that "something needs to be done". However it is
clearly a general problem and not one specific to winbind, and the right
way to solve this is to find a general solution for individual packages
to implement. The solution needs to come from the top, not from
individual package maintenance changes on a piecemeal basis; otherwise
we'll just end up with inconsistent behaviour and confuse users further.

In the meantime, nothing in particular has changed in the way Debian and
Ubuntu work. Under the current design, it is still a local configuration
problem that a service is enabled but fails to start. If this happens by
default, then it is a bug in packaging. If it happens because of some
local event, then it is something that is expected behaviour that needs
to be addressed by the sysadmin. If your automation is not using policy-
rc.d, then under the current distribution design your automation is
buggy on Ubuntu, as well as on Debian and other Debian derivatives.

That we have a higher level concern suggesting a design change does not
stop this being true.

To manage this most effectively, I think the only reasonable path
forward is to treat individual reports of local misconfigurations as
unactionable (bug status Invalid), but we can certainly have a higher
level bug open, with Wishlist importance, proposing a change in
distribution design in how we manage service restarts on package
upgrades. Such a bug needs to be written up carefully to cover the
generic case and accomodate multiple use cases.

Therefore I'm marking this bug Invalid to accurately reflect that there
is no action that can currently be taken on your concern except for a
separate general and extensive effort, but feel free to discuss further.


** Changed in: samba (Ubuntu)
       Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Server/Client Support Team, which is subscribed to samba in Ubuntu.
Matching subscriptions: Ubuntu Server/Client Support Team
https://bugs.launchpad.net/bugs/1818431

Title:
  Winbind failing to start leads to postinst erroring out

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1818431/+subscriptions