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

enabling/disabling daemons



I perceive a problem with the way daemons are enabled and disabled in
Debian.  In theory, /etc/rc?.d/* should be enough, right?  Well, maybe,
except that /etc/init.d/* doesn't know anything about those directories
and thus can't tell whether or not to start the daemon upon upgrade,
which makes the rc links only meaningful at boot time.

This leads to some non-standard kludges to mark services as enabled or
disabled.  The ssh package has '/etc/ssh/sshd_not_to_be_run' or
something like that, while Postgres has the hideous
# NOTE TO SYSTEM ADMINISTRATORS #
# To stop postgresql running, do
#   ln -sf /bin/false /usr/lib/postgresql/bin/can_i_run
# To re-enable it, do
#   rm /usr/lib/postgresql/bin/can_i_run

I recall an announcement from several months ago about some work that
seemed to be related to this issue, but I never read the full document.
Does that work address this problem?  Is it going to actually be
deployed within Debian?  What's its development status?  If anybody has
a link to that paper handy, please send it my way.

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

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.

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.

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

-- 
 _______________________________________________________
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 

Attachment: pgpWJ67kYPFQk.pgp
Description: PGP signature


Reply to: