For my RE task: rewrite about 90% of the starting services section purposely
leaving 3 paragraphs. The paragraphs should be reworded and get a kick with the whitespace boot but I would rather not affect translators that much.
This commit is contained in:
Tom Rhodes
parent
9002ead5ea
commit
9f3929188c
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=22293
1 changed files with 136 additions and 47 deletions
|
|
@ -320,38 +320,77 @@
|
|||
</sect1>
|
||||
|
||||
<sect1 id="configtuning-starting-services">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Tom</firstname>
|
||||
<surname>Rhodes</surname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect1info>
|
||||
|
||||
<title>Starting Services</title>
|
||||
|
||||
<indexterm><primary>services</primary></indexterm>
|
||||
|
||||
<para>It is common for a system to host a number of services.
|
||||
These may be started in several different fashions, each having
|
||||
different advantages.</para>
|
||||
<para>Many users choose to install third party software on &os;
|
||||
from the ports collection. In many of these situations it
|
||||
may be necessary to configure the software in a manner which
|
||||
will allow it to be started upon system initialization. Services,
|
||||
such as <filename role="package">mail/postfix</filename> or
|
||||
<filename role="package">www/apache13</filename> are just two
|
||||
of the many software packages which may be started during system
|
||||
initialization. Thus it is only fair that an explanation be
|
||||
provided on the procedures available for working with third
|
||||
party software, in the rare cases something goes wrong and the
|
||||
application does not start up properly.</para>
|
||||
|
||||
<indexterm><primary>/usr/local/etc/rc.d</primary></indexterm>
|
||||
<para>In &os;, most included services, such as &man.cron.8;, are
|
||||
started through the system start up scripts. These scripts may
|
||||
different depending on &os; or vendor version; however, the most
|
||||
important aspect to consider is that their start up configuration
|
||||
can be handled through simple startup scripts.</para>
|
||||
|
||||
<para>Software installed from a port or the packages collection
|
||||
will often place a script in
|
||||
<filename>/usr/local/etc/rc.d</filename> which is invoked at
|
||||
system startup with a <option>start</option> argument, and at
|
||||
system shutdown with a <option>stop</option> argument.
|
||||
This is the recommended way for
|
||||
starting system-wide services that are to be run as
|
||||
<username>root</username>, or that
|
||||
expect to be started as <username>root</username>.</para>
|
||||
<para>Since the advent of rcNG, it became clear that system
|
||||
initialization for third party utilities could be simplified.
|
||||
For years applications would drop a simple start up script into
|
||||
the <filename role="directory">/usr/local/etc/rc.d</filename>
|
||||
directory which would be read by the system initialization
|
||||
scripts. These scripts would then be executed during the latter
|
||||
stages of system start up.</para>
|
||||
|
||||
<para>A generic startup script in
|
||||
<filename>/usr/local/etc/rc.d</filename> looks similar to:</para>
|
||||
<para>While many individuals have spent hours trying to merge the
|
||||
old configuration style into the new system, the fact remains
|
||||
that some third party utilities still require a script simply
|
||||
dropped into the aforementioned directory. The subtle differences
|
||||
in the scripts depend whether or not rcNG is being used. Any
|
||||
version of &os; prior to 5.1 will not require the extra bit of
|
||||
configuration; indeed, in almost all cases the soon to be
|
||||
recognized script would do just fine.</para>
|
||||
|
||||
<para>While every script must meet some minimal requirements, most
|
||||
of the time these requirements are &os; version
|
||||
agnostic. Each script must have a <filename>.sh</filename>
|
||||
extension appended to the end and every script must be
|
||||
executable by the system. The latter may be achieved by using
|
||||
the <command>chmod</command> and setting the unique permissions
|
||||
of <literal>755</literal>. There should also be, at minimal,
|
||||
an option to <literal>start</literal> the application and an
|
||||
option to <literal>stop</literal> the application.</para>
|
||||
|
||||
<para>The simplest start up script would probably look a little
|
||||
bit like this one:</para>
|
||||
|
||||
<programlisting>#!/bin/sh
|
||||
echo -n ' FooBar'
|
||||
echo -n ' utility'
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
/usr/local/bin/foobar
|
||||
/usr/local/bin/utility
|
||||
;;
|
||||
stop)
|
||||
kill -9 `cat /var/run/foobar.pid`
|
||||
kill -9 `cat /var/run/utility.pid`
|
||||
;;
|
||||
*)
|
||||
echo "Usage: `basename $0` {start|stop}" >&2
|
||||
|
|
@ -359,33 +398,87 @@ stop)
|
|||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
</programlisting>
|
||||
exit 0</programlisting>
|
||||
|
||||
<para>The startup scripts of &os; will look in
|
||||
<filename>/usr/local/etc/rc.d</filename> for scripts that have an
|
||||
<literal>.sh</literal> extension and are executable by
|
||||
<username>root</username>. Those scripts that are found are called with
|
||||
an option <option>start</option> at startup, and <option>stop</option>
|
||||
at shutdown to allow them to carry out their purpose. So if you wanted
|
||||
the above sample script to be picked up and run at the proper time during
|
||||
system startup, you should save it to a file called
|
||||
<filename>FooBar.sh</filename> in
|
||||
<filename>/usr/local/etc/rc.d</filename> and make sure it is
|
||||
executable. You can make a shell script executable with &man.chmod.1;
|
||||
as shown below:</para>
|
||||
<para>This script provides for a <literal>stop</literal> and
|
||||
<literal>start</literal> option for
|
||||
the application hereto referred simply as
|
||||
<literal>utility</literal>. This application
|
||||
could then have the following lines placed in
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>chmod 755 <replaceable>FooBar.sh</replaceable></userinput></screen>
|
||||
<programlisting>utility_enable="YES"</programlisting>
|
||||
|
||||
<para>This convention does not always apply; however, as
|
||||
&os; 5.X progresses, the method of starting software has
|
||||
slowly been merged into the <filename>rc.conf</filename> file.
|
||||
For instance, to start the
|
||||
<filename role="port">www/apache13</filename> web server during
|
||||
system initialization, append the following line to the
|
||||
<filename>rc.conf</filename> file:</para>
|
||||
<para>Could be started manually with:</para>
|
||||
|
||||
<programlisting>apache_enable="YES"</programlisting>
|
||||
<screen>&prompt.root; <userinput><filename>/usr/local/etc/rc.d/utility.sh</filename> start</userinput></screen>
|
||||
|
||||
<para>While not all third party software requires the line in
|
||||
<filename>rc.conf</filename>, almost every day a new port will
|
||||
be modified to accept this configuration. Check the final output
|
||||
of the installation for more information on a specific
|
||||
application. Some third party software will provide start up
|
||||
scripts which permit the application to be used with
|
||||
rcNG; although, this will be discussed in the next section.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Extended Application Configuration</title>
|
||||
|
||||
<para>Now that &os; includes rcNG, configuration of application
|
||||
start up has become more optimal; indeed, it has become a bit
|
||||
more in depth. Using the key words discussed in the
|
||||
<link linkend="configtuning-rcNG">rcNG</link> section,
|
||||
applications may now be set to start after certain other
|
||||
services for example <acronym>DNS</acronym>; may permit extra
|
||||
flags to be passed through <filename>rc.conf</filename> in
|
||||
place of hard coded flags in the start up script, etc. A
|
||||
basic script may look similar to the following:</para>
|
||||
|
||||
<programlisting>#!/bin/sh
|
||||
#
|
||||
# PROVIDE: utility
|
||||
# REQUIRE: DAEMON
|
||||
# BEFORE: LOGIN
|
||||
# KEYWORD: FreeBSD shutdown
|
||||
|
||||
#
|
||||
# DO NOT CHANGE THESE DEFAULT VALUES HERE
|
||||
# SET THEM IN THE /etc/rc.conf FILE
|
||||
#
|
||||
utility_enable=${utility_enable-"NO"}
|
||||
utility_flags=${utility_flags-""}
|
||||
utility_pidfile=${utility_pidfile-"/var/run/utility.pid"}
|
||||
|
||||
. /etc/rc.subr
|
||||
|
||||
name="utility"
|
||||
rcvar=`set_rcvar`
|
||||
command="/usr/local/sbin/utility"
|
||||
|
||||
load_rc_config $name
|
||||
|
||||
pidfile="${utility_pidfile}"
|
||||
|
||||
start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utility_flags} ${command_args}"
|
||||
|
||||
run_rc_command "$1"</programlisting>
|
||||
|
||||
<para>This script will ensure that the provided
|
||||
<application>utility</application> will be started before the
|
||||
<literal>login</literal> service but after the
|
||||
<literal>daemon</literal> service. It also provides a method
|
||||
for setting and tracking the <acronym>PID</acronym>, or process
|
||||
<acronym>ID</acronym> file.</para>
|
||||
|
||||
<para>This new method also allows for easier manipulation of the
|
||||
command line arguments, inclusion of the default functions
|
||||
provided in <filename>/etc/rc.subr</filename>, compatibility
|
||||
with the &man.rcorder.8; utility and provide for easier
|
||||
configuration via the <filename>rc.conf</filename> file. In
|
||||
essence, this script could even be placed in
|
||||
<filename role="directory">/etc/rc.d</filename> directory.
|
||||
Yet, that has the potential to upset the &man.mergemaster.8;
|
||||
utility when used in conjunction with software upgrades.</para>
|
||||
|
||||
<para>Some services expect to be invoked by &man.inetd.8; when a
|
||||
connection is received on a suitable port. This is common for
|
||||
|
|
@ -393,12 +486,6 @@ exit 0
|
|||
enabled by editing the file <filename>/etc/inetd.conf</filename>.
|
||||
See &man.inetd.8; for details on editing this file.</para>
|
||||
|
||||
<note><para>Do <emphasis>not</emphasis> place any commands in
|
||||
<filename>/etc/rc.conf</filename>. To start daemons, or
|
||||
run any commands at boot time, place a script in
|
||||
<filename>/usr/local/etc/rc.d</filename> or <filename role="directory">/etc/rc.d</filename> instead.</para>
|
||||
</note>
|
||||
|
||||
<para>It is also possible to use the &man.cron.8; daemon to start
|
||||
system services. This approach has a number of advantages, not
|
||||
least being that because &man.cron.8; runs these processes as the
|
||||
|
|
@ -410,6 +497,8 @@ exit 0
|
|||
which will
|
||||
cause the job to be run when &man.cron.8; is started shortly after
|
||||
system boot.</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="configtuning-cron">
|
||||
|
|
|
|||
Loading…
Reference in a new issue