Re: enabling/disabling daemons
Hi
i agree that the init.d stuff isn't handled as nice as possible.
we at least need the ability to enable and disable services per runlevel.
the current system needs some squirks to get an overview, what gets started
when.
configuration should be handled in a config file in /etc.
as i read your mail i got some questions...
Am Montag, 23. September 2002 23.21 schrieb Noah L. Meyerhans:
> Personally, I don't see why we have never used something like the *BSD
> /etc/rc.conf system. It's very simple and works well (and no, it
> doesn't require us to move to the BSD initscript system).
> /etc/default/rc.conf defines the default state of installed daemon
> (whether they should be run or not) and /etc/rc.conf overrides this with
> lines like:
> sendmail_enable=NO
- how do you control the different runlevels? are there different
/etc/rc?.conf... files? are there different variables like
sendmail_enable_1=NO sendmail_enable_0=YES? a list of runlevels per variable
like sendmail_enable= "1 5 9" ?
- this way the init.d-script would need the runlevel anyway ( $(runlevel) ),
and could see whether it is linked in /etc/rc?.d/S??sendmail.
- we could make 'init' set a link from /etc/rc?.conf to /etc/rc.conf to solve
that. not that nice, i think
- where to put the priority? do we still use S??SERVICE links? are they in
default or in user?
- we maybe should use a little script called 'start-rc.d SERVICE' which looks
SERVICE up in /etc/rc.conf and runs it if it is enabled in this runlevel.
- this script could work also without modifying the initsystem, by looking up
links in /etc/init/rc?.d/S??SERVICE
- gives postrm and the like scripts possibility to simply call start-rc.d
MYSERVICE without looking up the runlevel
> And since everything is really just shell syntax, the init scripts
> merely need to source the defaults file, then source the user-editable
> file to get the override values.
so we need one user-editable file per runlevel and need to source the right
one, which in turn sources the default? i don't rely like that.
> This defines a standard mechanism for overriding the system defaults,
> which is easy for maintainers since we don't have to invent our own each
> time we want a convenient way to allow users to disable services, and
> it's easy for users, since they don't have to worry about what special
> file they have to create or delete in order to toggle the service.
yeah! standard! we need one, keep on discussing.
> I would be perfectly happy to do the legwork to implement a standard
> mechanism such as this, if it would be acceptable. The status quo is
> really starting to bug me.
>
> noah
great! it's hard to work on stuff like this, as it just works in almost all
cases and people don't like changing runing systems... but it is often realy
necessary:-)
just my 2c
simon
Reply to: