Wandering Thoughts archives

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