2007-04-15
chkconfig --add
considered misleading
Presented in the traditional illustrated form:
# chkconfig ntpd || echo not running not running # chkconfig --add ntpd # chkconfig ntpd || echo not running not running
I like Red Hat's chkconfig
, but its --add
option is so badly
misnamed it winds up irritating me half the time I use it. One
indication of how bad it is is that the chkconfig
manpage needs to
use a paragraph to half explain it, and the explanation is exceedingly
technical.
Part of the problem is that chkconfig
is overloaded: it is used by
sysadmins to enable and disable services, and it is used by RPMs to add
and remove init.d scripts. Because --add
half works to enable services
(it enables anything that defaults to being enabled), it is tempting to
use it all the time by reflex, and then get irritated when it doesn't
work.
(The theoretical correct way to enable a service is 'chkconfig
<service> on
'. Notice how this is a completely different method of
operation from chkconfig --add <service>
, so you have to remember not
just a different command-line option but a different syntax.)
Another chkconfig
problem is that right now, init.d scripts overload
the 'what runlevels this should be enabled in' field to say whether or
not they should default to being enabled. This means that a service that
defaults to being disabled can't say what runlevels are appropriate
for it, with the result that to be correct you cannot just 'chkconfig
<service> on
', because that may enable it in inappropriate runlevels.
(The common case is enabling network services in runlevel 2. Of course, I doubt anyone really uses runlevel 2 so in practice this doesn't really matter. But it irritates me, because sometimes I'm a nit-picker.)