Let us add some meat onto the bones of the previous script and make it more complex and featureful. The default methods can do a good job for us, but we may need some of their aspects tweaked. Now we will learn how to tune the default methods to our needs.
Additional arguments to Note:Never include dashed options,
like | |
A good-mannered daemon should create a
pidfile so that its process can be
found more easily and reliably. The variable
Note:In fact, rc.subr(8) will also use the pidfile
to see if the daemon is already running before starting
it. This check can be skipped by using the
| |
If the daemon cannot run unless certain files exist,
just list them in Note:The default method from rc.subr(8) can be
forced to skip the prerequisite checks by using
| |
We can customize signals to send to the daemon in
case they differ from the well-known ones. In particular,
Note:The signal names should be specified to rc.subr(8)
without the | |
Performing additional tasks before or after the default
methods is easy. For each command-argument supported by
our script, we can define
Note:Overriding a default method with a custom
Do not forget that you can cram any valid sh(1) expressions into the methods, pre-, and post-commands you define. Just invoking a function that makes the real job is a good style in most cases, but never let style limit your understanding of what is going on behind the curtain. | |
If we would like to implement custom arguments, which
can also be thought of as commands
to our script, we need to list them in
Note:The What do we get from the default method for
| |
Our script supports two non-standard commands,
Non-standard commands are not invoked during startup or shutdown. Usually they are for the system admin's convenience. They can also be used from other subsystems, e.g., devd(8) if specified in devd.conf(5). The full list of available commands can be found in the usage line printed by rc.subr(8) when the script is invoked without arguments. For example, here is the usage line from the script under study: # /etc/rc.d/mumbled
Usage: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll) | |
A script can invoke its own standard or non-standard
commands if needed. This may look similar to calling
functions, but we know that commands and shell functions
are not always the same thing. For instance,
| |
A handy function named Keep in mind that for sh(1) a zero exit code means true and a non-zero exit code means false. Important:The The following is the correct usage of
if checkyesno mumbled_enable; then
foo
fi On the contrary, calling if checkyesno "${mumbled_enable}"; then
foo
fi | |
We can affect the flags to be
passed to | |
In certain cases we may need to emit an important
message that should go to syslog
as well. This can be done easily with the following
rc.subr(8) functions: | |
The exit codes from methods and their pre-commands
are not just ignored by default. If
Note:However, rc.subr(8) can be instructed from the
command line to ignore those exit codes and invoke all
commands anyway by prefixing an argument with
|
This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/
For questions about FreeBSD, read the
documentation before
contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.