Hi Andreas and Robie, Thank you for thoroughly evaluating and investigating this ticket.
We both accept that situations arise when a service cannot start after package install/upgrade. For kernel-space service I think the maintainer script should poll and abort in that case. For user-space daemons ideally the maintainer scripts are cognizant to the reality that a failed service, while not ideal, is an acceptable state for a user space daemon. I fully support the underlying philosophy that both you and Andreas have communicated - ideally the service gets started. There is at least one important exception to this philosophy where we want to migrate from provider A to provider B (i.e. apache to nginx) in a rolling fashion and the workflow maybe a stepped process of install B package while service A is still running (and locking resources needed for service B), migrate the configuration, stop service A, start service B, uninstall package A. This is a corner case which I encountered with legacy linux systems. I presume the policy-rc.d mechanism holds across Debian-derivative systems - we have a specific saltstack bug tracking this issue - so this is possible workaround. I need to check that this mechanism is well documented because I was unable to find this API when searching for a workaround to this behaviour. I never saw this issue with Samba-Winbind in Ubuntu 16.04. We both accept that this policy causes difficulties in at least the three cases you have listed. Thanks for the detailed summarization of these issues. On the basis that this is general issue I accept that technically marking this ticket (and a corresponding nginx ticket) as invalid works at maintainer and package level. However please understand this behaviour can be frustrating in the wider scheme of things when we want to design resilient systems where failures are expected. I have not looked at the implementation in detail with DEP packages but would prefer and encourage non-blocking checks by maintainer scripts so apt continues to work. I wanted to ask if there was a Technical Steering Committee (TSC) this matter could be raised with. I lack the bandwidth to pursue this matter at TSC right now - my FOSS work is voluntary - but for the future what is the best way to NOT forget this issue. It's frustrating from Engineer perspective. thanks Noel On Wed, Mar 20, 2019 at 6:50 AM Robie Basak <1818...@bugs.launchpad.net> wrote: > 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 subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1818431 > > Title: > Winbind failing to start leads to postinst erroring out > > Status in samba package in Ubuntu: > Invalid > > Bug description: > Ubuntu 16.04 just works: Winbind was a smooth experience. We install > `winbind`, `libnss-winbind`, and `libpam-winbind` using APT > successfully, join the Domain/Realm, and start winbind with systemd! > > Ubuntu 18.04 is regression: The `winbind` package breaks APT/DPGK > package manager because `/var/lib/dpkg/info/winbind.postinst` is > trying to start the service - that's bad regression. > > I need package-manager (apt/dpkg) to handle packages, and service- > manager (systemd/upstart) to manage services. Can the winbind package > maintainer do anything to reverse the regression? > > I have been reading up on debhelper but cannot find a way to prevent > breaking apt. > > ``` > ~$ dpkg-query --list | grep winbind > iU libnss-winbind:amd64 > 2:4.7.6+dfsg~ubuntu-0ubuntu2.6 amd64 Samba nameservice > integration plugins > iU libpam-winbind:amd64 > 2:4.7.6+dfsg~ubuntu-0ubuntu2.6 amd64 Windows domain > authentication integration plugin > ii libwbclient0:amd64 > 2:4.7.6+dfsg~ubuntu-0ubuntu2.6 amd64 Samba winbind client > library > iF winbind > 2:4.7.6+dfsg~ubuntu-0ubuntu2.6 amd64 service to resolve user > and gro > > ... trace ... > > Active: failed (Result: exit-code) since Sun 2019-03-03 11:30:11 MST; > 19ms ago > Docs: man:winbindd(8) > man:samba(7) > man:smb.conf(5) > Process: 43699 ExecStart=/usr/sbin/winbindd --foreground > --no-process-group $WINBINDOPTIONS (code=exited, status=1/FAILURE) > Main PID: 43699 (code=exited, status=1/FAILURE) > > Mar 03 11:30:11 myhost1 systemd[1]: Starting Samba Winbind Daemon... > Mar 03 11:30:11 myhost1 winbindd[43699]: [2019/03/03 11:30:11.597251, > 0] ../source3/winbindd/winbindd_cache.c:3170(initialize_winbindd_cache) > Mar 03 11:30:11 myhost1 winbindd[43699]: initialize_winbindd_cache: > clearing cache and re-creating with version number 2 > Mar 03 11:30:11 myhost1 winbindd[43699]: [2019/03/03 11:30:11.600710, > 0] ../source3/winbindd/winbindd_util.c:891(init_domain_list) > Mar 03 11:30:11 myhost1 winbindd[43699]: Could not fetch our SID - did > we join? > Mar 03 11:30:11 myhost1 winbindd[43699]: [2019/03/03 11:30:11.600854, > 0] ../source3/winbindd/winbindd.c:1366(winbindd_register_handlers) > Mar 03 11:30:11 myhost1 winbindd[43699]: unable to initialize domain > list > Mar 03 11:30:11 myhost1 systemd[1]: winbind.service: Main process > exited, code=exited, status=1/FAILURE > Mar 03 11:30:11 myhost1 systemd[1]: winbind.service: Failed with result > 'exit-code'. > Mar 03 11:30:11 myhost1 systemd[1]: Failed to start Samba Winbind Daemon. > dpkg: error processing package winbind (--configure): > installed winbind package post-installation script subprocess returned > error exit status 1 > dpkg: dependency problems prevent configuration of libpam-winbind:amd64: > libpam-winbind:amd64 depends on winbind (= > 2:4.7.6+dfsg~ubuntu-0ubuntu2.6); however: > Package winbind is not configured yet. > > dpkg: error processing package libpam-winbind:amd64 (--configure): > dependency problems - leaving unconfigured > dpkg: dependency problems prevent configuration of libnss-winbind:amd64: > libnss-winbind:amd64 depends on winbind (= > 2:4.7.6+dfsg~ubuntu-0ubuntu2.6); however: > Package winbind is not configured yet. > > dpkg: error processing package libnss-winbind:amd64 (--configure): > dependency problems - leaving unconfigured > Processing triggers for libc-bin (2.27-3ubuntu1) ... > Errors were encountered while processing: > winbind > libpam-winbind:amd64 > libnss-winbind:amd64 > ``` > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1818431/+subscriptions > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. 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 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
