Remove the section on old-style startup scripts from the "Starting Services"
section. We don't want any new examples of these kinds of scripts. While I'm here, tune up the example rc.d script a bit, and tweak the text in that section a bit for readability.
This commit is contained in:
Doug Barton
parent
36f83ff4f6
commit
7abbc5958a
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=34347
1 changed files with 12 additions and 76 deletions
|
|
@ -359,67 +359,6 @@
|
|||
important aspect to consider is that their start up configuration
|
||||
can be handled through simple startup scripts.</para>
|
||||
|
||||
<para>Before the advent of <filename>rc.d</filename>, applications would drop a
|
||||
simple start up script into the
|
||||
<filename class="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>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 <filename>rc.d</filename> is being used. Prior
|
||||
to &os; 5.1 the old configuration style is used and in
|
||||
almost all cases a new style 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 be executable by the system; this is
|
||||
typically achieved by using the <command>chmod</command> command and
|
||||
setting the unique permissions of <literal>555</literal>. There should
|
||||
also be, at minimal, options to <literal>start</literal> and <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 ' utility'
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
/usr/local/bin/utility
|
||||
;;
|
||||
stop)
|
||||
kill -9 `cat /var/run/utility.pid`
|
||||
;;
|
||||
*)
|
||||
echo "Usage: `basename $0` {start|stop}" >&2
|
||||
exit 64
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0</programlisting>
|
||||
|
||||
<para>This script provides for a <literal>stop</literal> and
|
||||
<literal>start</literal> option for
|
||||
the application hereto referred simply as
|
||||
<literal>utility</literal>.</para>
|
||||
|
||||
<para>Could be started manually with:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput><filename>/usr/local/etc/rc.d/utility</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
|
||||
<filename>rc.d</filename>; although, this will be discussed in the next section.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Extended Application Configuration</title>
|
||||
|
||||
|
|
@ -439,14 +378,6 @@ exit 0</programlisting>
|
|||
# REQUIRE: DAEMON
|
||||
# KEYWORD: 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"
|
||||
|
|
@ -455,15 +386,20 @@ command="/usr/local/sbin/utility"
|
|||
|
||||
load_rc_config $name
|
||||
|
||||
pidfile="${utility_pidfile}"
|
||||
#
|
||||
# DO NOT CHANGE THESE DEFAULT VALUES HERE
|
||||
# SET THEM IN THE /etc/rc.conf FILE
|
||||
#
|
||||
utility_enable=${utility_enable-"NO"}
|
||||
utility_pidfile=${utility_pidfile-"/var/run/utility.pid"}
|
||||
|
||||
start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utility_flags} ${command_args}"
|
||||
pidfile="${utility_pidfile}"
|
||||
|
||||
run_rc_command "$1"</programlisting>
|
||||
|
||||
<para>This script will ensure that the provided
|
||||
<application>utility</application> will be started after the
|
||||
<literal>daemon</literal> service. It also provides a method
|
||||
<literal>DAEMON</literal> pseudo-service. It also provides a method
|
||||
for setting and tracking the <acronym>PID</acronym>, or process
|
||||
<acronym>ID</acronym> file.</para>
|
||||
|
||||
|
|
@ -484,15 +420,15 @@ run_rc_command "$1"</programlisting>
|
|||
|
||||
<para>Other services, such as <acronym>POP</acronym>3 server
|
||||
daemons, <acronym>IMAP</acronym>, etc. could be started using
|
||||
the &man.inetd.8;. This involves installing the service
|
||||
&man.inetd.8;. This involves installing the service
|
||||
utility from the Ports Collection with a configuration line
|
||||
appended to the <filename>/etc/inetd.conf</filename> file,
|
||||
or uncommenting one of the current configuration lines. Working
|
||||
added to the <filename>/etc/inetd.conf</filename> file,
|
||||
or by uncommenting one of the current configuration lines. Working
|
||||
with <application>inetd</application> and its configuration is
|
||||
described in depth in the
|
||||
<link linkend="network-inetd">inetd</link> section.</para>
|
||||
|
||||
<para>In some cases, it may be more plausible to use the
|
||||
<para>In some cases it may make more sense to use the
|
||||
&man.cron.8; daemon to start system services. This approach
|
||||
has a number of advantages because <command>cron</command> runs
|
||||
these processes as the <filename>crontab</filename>'s file
|
||||
|
|
|
|||
Loading…
Reference in a new issue