Source string Read only

(itstool) path: sect1/para
109/1090
Context English State
if checkyesno "${mumbled_enable}"; then
foo
fi
<anchor xml:id="rc-flags"/>We can affect the flags to be passed to <envar>$command</envar> by modifying <envar>rc_flags</envar> in <envar>$start_precmd</envar>.
In certain cases we may need to emit an important message that should go to <application>syslog</application> as well. This can be done easily with the following <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> functions: <function>debug</function>, <function>info</function>, <function>warn</function>, and <function>err</function>. The latter function then exits the script with the code specified.
The exit codes from methods and their pre-commands are not just ignored by default. If <envar><replaceable>argument</replaceable>_precmd</envar> returns a non-zero exit code, the main method will not be performed. In turn, <envar><replaceable>argument</replaceable>_postcmd</envar> will not be invoked unless the main method returns a zero exit code.
However, <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> can be instructed from the command line to ignore those exit codes and invoke all commands anyway by prefixing an argument with <literal>force</literal>, as in <option>forcestart</option>.
Connecting a script to the rc.d framework
After a script has been written, it needs to be integrated into <filename>rc.d</filename>. The crucial step is to install the script in <filename>/etc/rc.d</filename> (for the base system) or <filename>/usr/local/etc/rc.d</filename> (for ports). Both &lt;<filename>bsd.prog.mk</filename>&gt; and &lt;<filename>bsd.port.mk</filename>&gt; provide convenient hooks for that, and usually you do not have to worry about the proper ownership and mode. System scripts should be installed from <filename>src/etc/rc.d</filename> through the <filename>Makefile</filename> found there. Port scripts can be installed using <varname>USE_RC_SUBR</varname> as described <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html">in the Porter's Handbook</link>.
However, we should consider beforehand the place of our script in the system startup sequence. The service handled by our script is likely to depend on other services. For instance, a network daemon cannot function without the network interfaces and routing up and running. Even if a service seems to demand nothing, it can hardly start before the basic filesystems have been checked and mounted.
We mentioned <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> already. Now it is time to have a close look at it. In a nutshell, <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> takes a set of files, examines their contents, and prints a dependency-ordered list of files from the set to <varname>stdout</varname>. The point is to keep dependency information <emphasis>inside</emphasis> the files so that each file can speak for itself only. A file can specify the following information:
the names of the <quote>conditions</quote> (which means services to us) it <emphasis>provides</emphasis>;
the names of the <quote>conditions</quote> it <emphasis>requires</emphasis>;
the names of the <quote>conditions</quote> this file should run <emphasis>before</emphasis>;
additional <emphasis>keywords</emphasis> that can be used to select a subset from the whole set of files (<citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> can be instructed via options to include or omit the files having particular keywords listed.)
It is no surprise that <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> can handle only text files with a syntax close to that of <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. That is, special lines understood by <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> look like <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> comments. The syntax of such special lines is rather rigid to simplify their processing. See <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details.
Besides using <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> special lines, a script can insist on its dependency upon another service by just starting it forcibly. This can be needed when the other service is optional and will not start by itself because the system admin has disabled it mistakenly in <citerefentry><refentrytitle>rc.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
With this general knowledge in mind, let us consider the simple daemon script enhanced with dependency stuff:
#!/bin/sh

# PROVIDE: mumbled oldmumble <co xml:id="rcng-hookup-provide"/>
# REQUIRE: DAEMON cleanvar frotz<co xml:id="rcng-hookup-require"/>
# BEFORE: LOGIN<co xml:id="rcng-hookup-before"/>
# KEYWORD: nojail shutdown<co xml:id="rcng-hookup-keyword"/>

. /etc/rc.subr

name=mumbled
rcvar=mumbled_enable

command="/usr/sbin/${name}"
start_precmd="${name}_prestart"

mumbled_prestart()
{
if ! checkyesno frotz_enable &amp;&amp; \
! /etc/rc.d/frotz forcestatus 1&gt;/dev/null 2&gt;&amp;1; then
force_depend frotz || return 1<co xml:id="rcng-hookup-force"/>
fi
return 0
}

load_rc_config $name
run_rc_command "$1"
As before, detailed analysis follows:
That line declares the names of <quote>conditions</quote> our script provides. Now other scripts can record a dependency on our script by those names.
Usually a script specifies a single condition provided. However, nothing prevents us from listing several conditions there, e.g., for compatibility reasons.
In any case, the name of the main, or the only, <literal>PROVIDE:</literal> condition should be the same as <envar>${name}</envar>.
So our script indicates which <quote>conditions</quote> provided by other scripts it depends on. According to the lines, our script asks <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> to put it after the script(s) providing <filename>DAEMON</filename> and <filename>cleanvar</filename>, but before that providing <filename>LOGIN</filename>.
The <literal>BEFORE:</literal> line should not be abused to work around an incomplete dependency list in the other script. The appropriate case for using <literal>BEFORE:</literal> is when the other script does not care about ours, but our script can do its task better if run before the other one. A typical real-life example is the network interfaces vs. the firewall: While the interfaces do not depend on the firewall in doing their job, the system security will benefit from the firewall being ready before there is any network traffic.
Besides conditions corresponding to a single service each, there are meta-conditions and their <quote>placeholder</quote> scripts used to ensure that certain groups of operations are performed before others. These are denoted by <filename><replaceable>UPPERCASE</replaceable></filename> names. Their list and purposes can be found in <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
Keep in mind that putting a service name in the <literal>REQUIRE:</literal> line does not guarantee that the service will actually be running by the time our script starts. The required service may fail to start or just be disabled in <citerefentry><refentrytitle>rc.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Obviously, <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> cannot track such details, and <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry> will not do that either. Consequently, the application started by our script should be able to cope with any required services being unavailable. In certain cases, we can help it as discussed <link linkend="forcedep">below.</link>
<anchor xml:id="keywords"/>As we remember from the above text, <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> keywords can be used to select or leave out some scripts. Namely any <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> consumer can specify through <option>-k</option> and <option>-s</option> options which keywords are on the <quote>keep list</quote> and <quote>skip list</quote>, respectively. From all the files to be dependency sorted, <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> will pick only those having a keyword from the keep list (unless empty) and not having a keyword from the skip list.
In FreeBSD, <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry> is used by <filename>/etc/rc</filename> and <filename>/etc/rc.shutdown</filename>. These two scripts define the standard list of FreeBSD <filename>rc.d</filename> keywords and their meanings as follows:
<literal>nojail</literal>
The service is not for <citerefentry><refentrytitle>jail</refentrytitle><manvolnum>8</manvolnum></citerefentry> environment. The automatic startup and shutdown procedures will ignore the script if inside a jail.
<literal>nostart</literal>
The service is to be started manually or not started at all. The automatic startup procedure will ignore the script. In conjunction with the <literal>shutdown</literal> keyword, this can be used to write scripts that do something only at system shutdown.

Loading…

No matching activity found.

Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Flags
read-only
Source string location
article.translate.xml:990
String age
a year ago
Source string age
a year ago
Translation file
articles/rc-scripting.pot, string 116