Re: insserv + apache2 + bind9 = pain
On Tue, 28 Dec 2010 12:07:30 -0800, Mike Bird wrote:
> On Tue December 28 2010 10:56:48 Camaleón wrote:
>> JFYI:
>>
>> apache2: fails to start with dependency based boot if DNS is required
>> by configuration
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606334
>
> Thank you for the link but the bug is not in Apache.
Nobody said that.
I pointed you to the bug because you are experiencing the same situation.
You still don't know (or did not tell) why your apache fails to boot at
start up. You can add your comments to the report to help fixing the
problem.
> The bug is the poorly thought out and poorly documented startup
> mechanism which is being pushed onto previously stable and reliable
> Debian servers.
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.
> People have also encountered problems with MySQL, Request Tracker,
> Apache, and Bind. We haven't even started testing LDAP, Samba, Postfix,
> ClamSMTP, ClamAV, Quagga, YP/NIS, WordPress etc in the various
> combinations and with the various configurations and various plugins
> employed on different servers.
Then you better report them in BTS. There is no chance to get them fixed
is nobody is aware of the problem.
> If anyone doubts it's a nightmare, take a look at the sysv-rc changelog
> and see how many special case hacks and weeks of effort went into
> getting insserv to work with just a virgin Linux system with no
> significant services running.
Again, I've been using for years this booting system (yes, in my racked
servers) and nothing terribly happened.
> Remember that configuring the priorities of N services is O(N), while
> configuring all their dependencies is O(N*N). It just doesn't scale on
> real world servers. You're breaking stable Debian servers and pushing
> all the repair work on Debian users and sysadmins. FOR NO GOOD REASON.
"Reasons" were stated time ago:
http://lists.debian.org/debian-devel-announce/2009/09/msg00003.html
More here:
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
In fact, I guess dependency boot system will be soon replaced by newer
methods, like systemd or upstart. Dependency booting can be new in Debian
but not in the linux world.
> What's worse is that the startup sequence is not repeatable. A service
> required may just happen to be ready in time on most reboots but start
> up a little slower sometimes and thus cause intermittent failures.
> Analyzing every piece of code and configuration on a system - some of it
> written more than ten years ago - is a nightmare.
Disable parallel booting and see if you get any gain.
> It's the Microsoft way to use a separate box for each service but prior
> to Squeeze it has always been a big selling point for Debian that you
> could always add another service to a box and it would just work. In
> the past Debian has worked REALLY WELL for small businesses and schools.
Things change, but again, this is not new is only that you are not used
to it.
> There's no VALID reason for FORCING insserv on Debian servers other than
> someone's desire to see his/her software being used.
Open a wishlist report (to express your thoughts and concerns on this
matter) or a documentation report (so the new boot method gets well
documented) or write an e-mail to Debian devel mailing list. You can
complain about the things you don't like and you can also help to get
them fixed. Choose your poison... you can even choose both paths:
complain and help to fix errors >:-)
> So I will repeat the key question, and with increased desperation:
>
> How do we run the old reliable Snn/Knn style startup mechanism in
> Squeeze?
It is still there (sysv-rc and insserv play "together") and I already
answered to that question. In fact, I remember that months ago I was
asked by the installer if I wanted to migrate to the new dependency boot
and I choose "yes".
What have you already tested for getting rid of insserv? Did you try to
remove the package (insserv)? Did you try by reconfiguring it? (don't do
these things on production servers but in testing machines). If it does
not work, please, tell what is exactly failing so anyone can help you
with this.
Greetings,
--
Camaleón
Reply to: