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:
http://cvs.sourceforge.net/viewcvs.py/daemond/daemond/doc/sample/daemond.d/syslog?rev=1.1&view=auto
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: