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

Re: Help with init replacement

On Wednesday 19 November 2003 16:43, you wrote:
> On Tue, 18 Nov 2003, Marc A. Pelletier wrote:
> > Now /that/ is interresting and smart and is indeed likely the most
> > promising avenue for quick and dirty daemond integration in debian; the
> > problem is that from what I have understood, update-rc.d suffers from, by
> > design, exactly the same problem that rc.d style inits suffer from: no
> > proper way of specifying dependencies and ordering other than by asigning
> > a cardinal and a set of
> update-rc.d needs either another interface layer, or a sister command to
> register dependencies, alright.
> Want to take on the job?  It must be made _very_ generic, a dependency-rc.d
> (or whatever) that would allow us to plug daemond, as well as the other
> dependency-based init script systems is very welcome.

Hmm; I can see how to make it work if packages register /either/ static 
ordering or dependencies, but not both.

Creating a synthetic dependency graph from services which are strictly defined 
by a numeric "priority" is simple enough, so is finding a correct static 
order derived from a dependency graph...  where I see a problem is when both 
are mixed.

> Don't forget invoke-rc.d either, and if you are mucking with init itself,
> also telinit.

Daemond doesn't use init.d-style scripts normally.  It can be made to (simply 
by specifying "init.d/foo start" and "init.d/foo stop" as the service start 
and stop) but you loose some functionality this way.  [normally, daemond 
prefers to invoke daemons in their non-forking operating mode so that it 
keeps close tab on the process].

> > The *correct* way of doing all this, of course, is for packages to create
> > their own service definition file and install them (possibly through some
> Nope.  The correct way [...]

I mean correct from /daemond's/ perspective-- if there is a unified method to 
have those files generated/installed for it so much the better.

> I actually like the idea of service
> definition files, as long as they are generic

Well, I /do/ have my own grammar and parser-- the general syntax is similar 
from bind's named.conf.  I have toyed with the idea of using XML (much as I 
despise the tendency of trying to use XML at all costs regardless of how well 
it fits the problem set that seems to be prevalent these days) but having 
something as critical as one's init depend on large and complex XML libraries 
is not my idea of a Good Thing (and rewriting an XML parser just for that 
component even sillier).  A yacc grammar, OTOH, compiles quite well and 
compactly statically.

You can see a fairly representative of one of my files there:


I think you can figure it out even without docs (except, perhaps, for the 
somewhat less obvious "wait" directive-- it simply means that if you 
succesfully start "syslogd" (manually or otherwise) you want "klogd" to
be scheduled to start as well if avaliable).

You can browse around the samples in the CVS tree to get a good idea, and 
there is even something that vaguely resembles docs in there.  :-)

> (but I quite dislike the idea
> that one would probably need to run a update-dependency-rc.d or whatever
> script to "transfer" what is in the files to whatever init system is in
> use).

I don't think there's any way around that; either you need to build a 
dependency graph out of statically ordered services, or create a static order 
out of a dependency graph-- in either case you need to look (again) at the 
entire set to build what is needed for the specific init system.

But if you use the update-rc.d and dependency-rc.d method that step can be 
hidden under the interface, done implicitely.

> We already have at least one very good dependency-based initscript system
> in Debian, so daemond is not alone in its troubles.

Oh?  Don't know it. Care to point me to it?

-- Marc A. Pelletier

Reply to: