Many of the init scripts are inconsistent with each other. Watch the
startup and shutdown, and you'll notice that, for example, some scripts say
"Shutting down <service>" while others say "Stopping <service>", and there
are similar problems with startup.
Long-term, it'll present a more coherent interface if all scripts
standardize on one consistent boilerplate.
While I'm complaining, some scripts are named by the daemon, while others are
named by the service provided, and still others are named by the package. For
example, apache's init script is httpd (daemon), postfix's init script is
postfix (package name), and samba's init script is smb (service provided). It'd
help usability to pick a standard name and stick with it so users always know
what to expect....
All this is still true of RC1 for the upcoming 7.2 release.
All this is still true with 7.3 gold.
When 8.0 development starts, is there any chance this will be fixed? These
aren't major bugs, obviously, but these sorts of minor nits are what distinguish
quality, easy-to-use software from thrown-together, inconsistent software. The
devil really is in the details and all that....
If someone sez what the standard should be (I'd think it would have to be naming
init scripts by package; naming by service won't work b/c multiple packages
provide the same service), I'll start submitting patches against packages for
Renaming the scripts is an impossibility; it will destroy all saved
configuration of whether they're enabled or disabled across upgrades.
There are a couple of ways to work around that (here using the case of changing
httpd to apache as a common example) that I can think of:
1. make /etc/init.d/httpd a symlink to /etc/init.d/apache
(ugly as sin, but guaranteed correct)
2. %post script looking at chkconfig line in /etc/init.d/apache to see
defaults, then looking in /etc/rc?.d/ dirs for symlinks, then changing those to
point to /etc/init.d/apache
(much cleaner, but also much more fragile)
and then there's always
3. say screw it and have a flag day
Whether it's worth any of those (except maybe #2), I really don't know. On the
other hand, I do know that when I'm introducing people to RH administration, the
inconsistencies [eg, "why is Samba's smb (one of the protocols it provides),
while BIND's is named (the binary which implements it), while PostgreSQL's is
postgresql (the name of the software), while....]are frequently noticed and
Closing out bugs on older, no longer supported releases. Apologies for any lack
As listed, I'd state that #1 is too ugly, #2 is too fragile, and #3, while nice,
is impractical. Not sure that breaking compatibility with upstream is worth it.