[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: insserv + apache2 + bind9 = pain



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


Reply to: