Subject: Cosmetic changes to rc.d scripts
To: None <tech-userlevel@NetBSD.org>
From: Julio M. Merino Vidal <firstname.lastname@example.org>
Date: 10/12/2004 21:30:36
I've been doing some cosmetic changes to the rc.d scripts, based on what I've
seen lately on multiple Linux distributions.
The first one is the addition of a "comment" variable; this holds a string
describing the purpose of the service handled by the rc.d script.
This comment is used in start/stop messages instead of the daemon name.
I think this is useful because you can see what's going on more easily;
specially, it will make novice's life easier (less criptic stuff).
For example, the inetd script includes 'comment="Internet superserver"',
so that, instead of "Starting inetd.", you'll see "Starting Internet
superserver (inetd)." (yeah, the real name is kept at the end).
The changes I've done make the comment variable optional, so that old
scripts (those installed from pkgsrc, for example, don't break until they
The second change is the addition of a prefix to "important" messages.
For example, consider the dhclient script: a typical run shows a
"Starting dhclient." message followed by the output of the command. This
is confusing, because it's hard to associate all that output to a given
rc.d script (ok, ok, in this case it's easy, but there are other situations
where it's not).
Adding a prefix to the start/stop messages, you can think of the output
as several "groups". Ideally, each script should print a single prefixed
message at the very beginning, followed by multiple extra non-prefixed
messages. For example, in the previous case you'd see "=> Starting DHCP
client (dhclient)." followed by all dhclient messages. In this case, you
can easily see that all extra information belongs to the dhclient script
because it's in a "subsection".
I've chosen '=> ' as the prefix inspired by the '===>' style of headings
we print from src and pkgsrc. Note that this prefix is customizable by
setting the rc_msg_prefix variable from rc.conf (i.e., setting it to
the null string should keep the previous behavior, but with more verbose
The patch (~45kb) is at:
What do you think about this?
Julio M. Merino Vidal <email@example.com>
The NetBSD Project - http://www.NetBSD.org/