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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.12.29.08.13...@gmail.com