Re: Help with init replacement
On Thu, 20 Nov 2003, Marc A. Pelletier wrote:
> Hmm; I can see how to make it work if packages register /either/ static
> ordering or dependencies, but not both.
It must, for backwards compatibility. Once the package has BOTH information
registered, dependencies would take precedence (as in disable the static
ordering).
> > 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].
init.d style scripts often do a lot more then just invoking a program. So
either init.d always, or a choice selected by the package would be needed.
> > > 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 see.
> > 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?
Sure. Package runit.
Also, please read the (now a bit outdated) paper on debian init script
systems at http://people.debian.org/~hmh/
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: