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