== _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.)