Re: Help with init replacement
On Tuesday 18 November 2003 10:35, Frank Küster wrote:
> I generally agree with what Joachim said. But note that for the package
> to be integrated into debian, you would need to write a daemond version
> of update-rc.d, which is the generic interface packages use to add
> themselves to the init process. For the process of converting, you (or
> the interested guy) can take a look at file-rc.
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
runlevels-- this nullifies many of the gains daemond gives.
Daemond allows expressing, as an example, that the 'smbd' service
- requires the presence of a proper smbd configuration
- needs networking to be up; and
- that the 'nmbd' service should be started after smbd if it is avaliable.
Another thing that daemond allows is to have a number of defined services
declare providing a specific facility; say you can have an 'apache' or
'oracle-webserver' both provide 'httpd', and have services depend on that.
It is then possible for another service, or an operating mode (akin to the
init-style runlevels) to request that "any" or "all" avaliable providers of
'httpd' be started-- this then works regardless of which actual http daemon
you happen to be using.
A concrete example is the way network interface work-- they are defined as
services (that bring the if up on start and down on stop) that provide
"network-interfaces" so that any service that depends on them being setup
need only declare its dependency on "network-interfaces". Any of those
interface could declare a dependency on, say "pppd" or some kernel module.
The point of this flexible dependency scheme is that it allows starting
services as early as possible, and in parallel. This is a big gain in speed
(especially if the services and their datafiles span multiple disks) and it's
also less error-prone once setup.
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
published interface rather than manuall), but this would require updating
every package that possibly wants to add themselves to the bootstrap. In
other words, that can't be done before some time after daemond /already/ is
the de facto init process.
So, in the meantime, daemond would need to provide the service definition
files for packages that don't (i.e. in the beginning every one). Thankfully,
they can be made to be conditional to the presence of the installed package
and made unavaliable otherwise.
-- Marc A. Pelletier
Reply to: