On Thu December 30 2010 03:42:45 Camaleón wrote: > On Wed, 29 Dec 2010 12:08:10 -0800, Mike Bird wrote: > > I have not lied about your postings. I started this thread > > by posting a solution[1] and by asking if there is a better solution. > > And I told you another way to get the job done (in fact, if you read the > manual, is one of the recommended ways of doing it) and some hints on how > to debug the error of the non-booting service (by disabling pararel > booting). But you are only complaining about something that -I think- you > don't fully understand and not attending to anything else (nor Debian > developer's reasons who wanted to make the change to insserv, nor > documentation, nor helping in enhance it... nothing!).
(Sigh). I do a lot of volunteer teaching, but not usually in this subject area. Oh well, here goes ... Parallelism isn't the issue. The issue is that insserv throws away years of work by Debian Developers, causing services to boot in the wrong order, and thus to fail. I found the problem, debugged it, and created a solution before posting. I posted that solution when I started this thread. And I asked if there is a BETTER solution.[1] You replied with a different solution but not a better solution. In fact, within the limits of the appalling documentation, your solution appears to be worse. Understanding why your solution is worse is a small step on your road to becoming a competent sysadmin. My solution is to create a file in /etc/insserv/overrides. My solution at this time handles upgrades perfectly. However the lack of proper documentation means that we don't know if conflicts may arise in future if a Debian package wants to create a file with the same name in that directory. Your solution is to edit /etc/init.d/apache2. Your solution requires manual intervention on every apache2 upgrade. Therefore your solution is worse than mine. However I would still appreciate it if anyone can offer a better solution than mine, or Debian's policy on which of the five or more sources of dependency information are for sysadmins and which are for packagers, or Debian's policy on which of the five or more sources of dependency information will in future automatically migrate to upstart or systemd or launchd, or where the mysterious dependency between openvpn and gdm3 is declared, or advice on reverting this insserv mess and using the reliable Snn/Knn startup sequencing for Squeeze servers. Now if you want to keep arguing who has the largest cojones, please take it elsewhere. Nobody will argue with you. This thread is about insserv problems and solutions. Anything else is off-topic. --Mike Bird [1] http://lists.debian.org/debian-user/2010/12/msg01609.html -- 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/201012301057.39599.mgb-deb...@yosemite.net