severity 500176 important thanks FWIW this problem is found in many other cases: see lighttpd with apache2 installed, or caudium or any other http daemon, and none of them has a bug about it, it's unfair to mark it as RC. On Wed, Oct 01, 2008 at 09:47:38AM +0000, martin f krafft wrote: > reopen 500176 > severity 500176 serious > thanks > > This bug is actually release-critical because installation leaves > the dpkg database in an unusable state. Please either conflict with > other DNS servers, do not start it by default, bind it to > 127.0.0.42, fail gracefully (which would not be ok, I think), or do > something else, but don't close bug reports about messages like > > Errors were encountered while processing: > unbound > E: Sub-process /usr/bin/dpkg returned an error code (1) I believe the problem here is somehow very generic, and that using a virtual package like proposed in the bug report (#500176) doesn't scale well. Especially for dns daemons. Packaging two of them myself (nsd3 that is an authoritative server only, and pdnsd that is a caching daemon only) I can tell the virtual package solution would be a mess: I _want_ to be able to use nsd3 _and_ pdnsd on the same machine (I actually do since the former binds to the external IPs only and pdnsd to 127.0.0.1) but by default nsd3 listens on 0.0.0.0 and you can't apt-get install pdnsd if you haven't configured nsd3 properly first. And you cannot make both conflict, both should work fine. Also I don't like setting a default file for every single daemon out there for the first install purpose only. Anyways I think there is a more general solution to find and here are a path. The fact that Debian starts every single service on first install is something that we strive for, but causes some grief for sysadmins that don't wish to open an unprotected service before they configured it. It also generates the issue we're disussing. Though, we could probably do better: a bit like solaris does, we could have some kind of service handler that wraps every single service, and if the start action fails, it marks the service as "broken" and refuse it to start, prints whatever warning you want to, but doesn't prevent the package manager to do its job. People could also probably configure it so that when first installed a service would be in the "broken" or "unconfigured" or "disabled" state, so that it's not started by default, which would please somehow everyone. If you do so, the problems that criple multiple installs of different $service servers that would like to bind on the same port disappears. It would also help a lot for chroots and things like that. Technically it would mean that we need a simple tool à la svc (I think it's how the solaris counterpart is known as, and fwiw I don't know it well, I just saw _this_ functionnality, and I believe we want it) in Base, that would provide a /lib/init/service-functions.sh that every single /etc/init.d script would have to include (well maybe not bootmisc.sh or friends of course, but you grok the general idea of course). Coming with it a simple database of the disabled/broken/... services. Then it would work like this: * If you /etc/init.d/$service start/reload/restart a service that is disabled or broken, an error message would appear saying that there was some problem with the service and that you must run "debian-svc enable $SERVICE" to enable it again. * stop action would always be enabled. * If the start action fails, then the service would automatically be put in the broken state. The maintainer could help in that regard using: start-stop-daemon .... || debian-svc broken "$some_reason" or the sourcing of /lib/init/service-functions.sh could also trap errors and do an automatic 'debian-svc broken "<service $foo failed to start at $(date -R)>"' As a side effect, most of the "ENABLED=true|false|yes|no|..." tricks in /etc/default/$service could be dealt with from the postinst that when it's a first install would force the service to be disabled by default in a more generic way. I don't believe such a service manager is hard to write, though it requires some bit of migration of the maintainer scripts, which could be a worthy squeeze release goal. What do people think ? -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgp2yQImLZthQ.pgp
Description: PGP signature