Re: insserv + apache2 + bind9 = pain
On Wed December 29 2010 00:13:04 Camaleón wrote:
> AFAIK, booting scripts have been rewrited to play with dependency booting
> and provided this is new for Squeeze, I would expect some glitches, but
> nothing that cannot be solved.
The question is not whether the problem can be solved. People can
as a last resort always hack the source. The immediate question is
whether the insserv mess can be reasonably maintained. And the big
picture question is whether the ego boost for the insserv developer
is worth the substantial hit to Debian's reputation.
I'll give you just a few examples that we've run into since this
thread started a few hours ago.
(1) We cannot find any useful documentation as to who controls
/etc/init.d/foo, /etc/insserv/overrides/foo, /etc/insserv.conf.d/foo,
/usr/share/insserv/overrides/foo, and /etc/insserv.conf. All of
these can be used to specify dependencies. Which are intended for
Debian packagers, and which for sysadmins? Which are supported
properly through upgrades and dist-upgrades? How are conflicts
between the five sources of dependencies handled, i.e. which has
priority over which others?
You recommended that sysadmins edit /etc/init.d/foo. Is that Debian
policy or a kludge that will cause pain on the next upgrade? Would
it be better to use one of the many other places where overrides
can be specified?
(2) There are many kinds of connections and tunnels and routes that
need to be established on some boxes but not on others. For example,
some servers need ethernet interfaces, then openvpn, then quagga.
Others need early PPP although we don't have a test box configured for
that right now. Debian Stable handles all this correctly out of the
box. After insserv wreaks havoc, openvpn can erroneously be brought
up last while apache can fail before openvpn, named, quagga, and mysql
are started.
Any sane dependency boot system would allow me to say "start openvpn
before services X, Y, and Z" but under insserv we're stuck with
creating a separate override for each of X, Y, and Z. insserv appears
to be a high-school coding experiment, not a professional sysadmin tool.
(3) insserv wants to start openvpn before gdm3 on workstations. That's
probably a good idea as that's what Debian Stable does. However, although
that dependency appears in the generated /etc/init.d/.depend.start we
cannot find the source of the dependency. It is not in any of the places
listed in (1) above. Are there more special cases hidden somewhere? What
if someone needed gdm3 to start before openvpn, how would they override a
hidden (possibly hard-coded?) dependency?
(4) /etc/init.d/bootlogs describes itself as "Various things that don't
need to be done particularly early in the boot, just before getty is run."
And yet it has no defined relationship to getty, and defines the opposite
relationship to gdm3, kdm, etc. Which is correct, the description or the
dependencies?
Thanks for looking into this. I still fail to see why saving half a
second a year on server booting is worth inflecting days of drudgery
on tens of thousands of sysadmins.
So yet again, why is Debian forcing this horrible change? The old
sysv-rc is not hard to support alongside file-rc. Why abuse the power
of Debian dependencies to push this bad idea on sysadmins who don't
want it? Why can't we keep the excellent debugged working reliable
sysv-rc from Lenny? If some people want to use insserv let them, but
don't force people to go through this nonsense!
insserv simply throws away all the hard work by Debian Developers over
many many years that went into tuning the default rc2.d/Snn priorities.
--Mike Bird
Reply to: