BSD rc.d脚本编程实战

1 简介

　　历史上 BSD 曾有过一个单一的启动脚本， /etc/rc。 该脚本在系统启动的时候被 init(8) 程序所引导，并执行所有多用户操作所需求的用户级任务： 检查并挂载文件系统，设置网络，启动守护进程，等等。 在每个系统中实际的任务清单也并不相同； 管理员需要根据需求自定义这样的任务清单。在一些特殊的情况中， 还不得不去修改 /etc/rc 文件， 一些真正的黑客乐此不疲。

　　单一脚本启动方法的真正问题是它没有提供对从 /etc/rc 启动的单个组件的控制。 拿一个例子来说吧，/etc/rc 不能够重新启动某个单独的守护进程。 系统管理员不得不手动找出守护进程，并杀掉它， 等待它真正退出后，再通过浏览 /etc/rc 得到该守护进程的标识，最终输入全部命令来再次启动守护进程。 如果重新启动的服务包括不止一个守护进程或需要更多动作的话， 该任务将变得更加困难以及容易出错。简而言之， 单一脚本在实现我们这样的目的上是不成功的： 让系统管理员的生活更轻松。

　　再后来，为了将最重要的一些子系统独立出来， 便尝试将部分的内容从 /etc/rc 分离出来了。 最广为人知的例子就是用来启动联网的 /etc/netstart 文件。它容许从单用户模式访问网络， 但由于它的部分代码需要和一些与联网完全无关的动作交互， 所以它并没有完美地结合到自启动的进程中。那便是为何 /etc/netstart 被演变成 /etc/rc.network 的原因了。 后者不再是一个普通的脚本；它包括了庞大的，由 /etc/rc 在不同的系统启动级别中调用的凌乱的 sh(1) 函数。然而，当启动任务变得多样化以及久经更改， “类模块化” 方法变得比曾经的整体 /etc/rc 更缓慢费事。

　　由于没有一个干净和易于设计的框架， 启动脚本不得不全力更改以满足飞速开发中基于 BSD 的操作系统的需求。 它逐渐变得明朗并经过许多必要的步骤最终变成一个具有细密性和扩展性的 rc 系统。BSD rc.d 就这样诞生了。Luke Mewburn 和 NetBSD 社区是公认的 rc.d 之父。再之后它被引入到了 FreeBSD 中。 它的名字引用为系统单独的服务脚本的位置，也就是 /etc/rc.d下面的那些脚本。 之后我们将学习到更多的 rc.d 系统的组件并看看单个脚本是如何被调用的。

　　BSD rc.d 背后的基本理念是 良好 的模块化和代码重用性。 良好 的模块化意味着每个基本 “服务” 就象系统守护进程或原始启动任务那样， 通过属于它们的可启动该服务的 sh(1) 脚本，来停止服务， 重载服务，检查服务的状态。具体动作由脚本的命令行参数所决定。 /etc/rc 脚本仍然掌管着系统的启动， 但现在它仅仅是使用 start 参数来一个个调用那些小的脚本。 这便于用 stop 来对运行中的同样的脚本很好地执行停止任务， 这是被 /etc/rc.shutdown 脚本所完成的。看，这是多么好地体现了 Unix 的哲学： 拥有一组小的专用的工具，每个工具尽可能好地完成自己的任务。 代码重用 意味着所有的通用操作由 /etc/rc.subr 中的一些 sh(1) 函数所实现。 现在一个典型的脚本只需要寥寥几行的 sh(1) 代码。最终， rcorder(8) 成为了 rc.d 框架中重要的一部分， 它用来帮助 /etc/rc 处理小脚本之间的依赖关系并有次序地运行它们。它同样帮助 /etc/rc.shutdown 做类似的事情， 因为正确的关闭次序是相对于启动的次序的。

　　BSD rc.d 的设计在 Luke Mewburn 的原文 中有记录， 以及 rc.d 组件也被充分详细地记录在各自的 联机手册 中。然而， 它可能没能清晰展现给一个 rc.d 新手，如何将无数的块和片进行关联来为具体的任务创建一个好风格的脚本。 因此本文将试着以不同的方式来讲述 rc.d。 它将展示在某些典型情况中应该使用哪些特性，并阐述了为何如此。 注意这并不是一篇 how-to 文档，我们的目的不是给出现成的配方， 而是在展示一些简单的进入 rc.d 的范围的门路。 本文也不是相关联机手册的替代品。 阅读本文时记得同时参考联机手册以获取更完整正规的文档。

　　理解本文需要一些先决条件。首先，你需要熟悉 sh(1) 脚本编程语言以掌握 rc.d， 还有，你需要知道系统是如何执行用户级的启动和停止任务，这些在 rc(8) 中都有说明。

　　本文关注的是 rc.d 的 FreeBSD 分支。 不过，它可能对 NetBSD 的开发者也同样有用，因为 BSD rc.d 的两个分支不只是共享了同样的设计， 还保留了对脚本编写者都可见的类似观点。

2 任务描述

　　在开始打开 $EDITOR（编辑器） 之前进行小小的思考不是坏事。为了给一个系统服务写一个 “听话的” rc.d 脚本， 我们首先应该能回答以下问题：

• 该服务是必须性的还是可选性的？

• 脚本将为单个程序服务，如一个守护进程，还是执行更复杂的动作？

• 我们的服务依赖哪些服务？反过来哪些服务依赖我们的服务？

　　从下面的例子中我们将看到，为什么说知道这些问题的答案是很重要的。

3 虚拟的脚本

　　下面的脚本是用来在每次系统启动时发出一个信息：

#!/bin/sh

. /etc/rc.subr

name="dummy"
start_cmd="${name}_start"
stop_cmd=":"

dummy_start()
{
    echo "Nothing started."
}

load_rc_config $name
run_rc_command "$1"

　　需要注意的是：

4 可配置的虚拟脚本

　　现在我们来给我们的虚拟脚本增加一些控制参数吧。正如你所知， rc.d 脚本是由 rc.conf(5) 所控制的。 幸运的是，rc.subr(8) 隐藏了所有复杂化的东西。 下面这个脚本使用 rc.conf(5) 通过 rc.subr(8) 来查看它是否在第一个地方被启用，并获取一条信息在启动时显示。 事实上这两个任务是相互独立的。一方面，rc.d 脚本要能够支持启动和禁用它的服务。另一方面， rc.d 脚本必须能具备配置信息变量。 我们将通过下面同一脚本来演示这两方面的内容：

#!/bin/sh

. /etc/rc.subr

name="dummy"
rcvar=`set_rcvar`
start_cmd="${name}_start"
stop_cmd=":"

load_rc_config $name
eval "${rcvar}=\${${rcvar}:-'NO'}"
dummy_msg=${dummy_msg:-"Nothing started."}

dummy_start()
{
    echo "$dummy_msg"
}

run_rc_command "$1"

　　在这个样例中改变了什么？

5 启动并停止简单守护进程

　　我们早先说过 rc.subr(8) 是能够提供默认方法的。 显然，这些默认方法并不是太通用的。 它们都是适用于大多数情况下来启动和停止一个简单的守护进程况。 我们来假设现在需要为一个叫做 mumbled 的守护进程编写一个 rc.d脚本， 在这里：/para>

#!/bin/sh

. /etc/rc.subr

name="mumbled"
rcvar=`set_rcvar`
command="/usr/sbin/${name}"

load_rc_config $name
run_rc_command "$1"

　　感到很简单吧，不是么？我们来检查下我们这个小脚本。 只需要注意下面的这些新知识点：

6 启动并停止高级守护进程

　　我们来给之前的 “骨架” 脚本加点 “血肉”，并让它更复杂更富有特性吧。 默认的方法已能够为我们做很好的工作了， 但是我们可能会需要它们一些方面的调整。 现在我们将学习如何调整默认方法来符合我们的需要。

#!/bin/sh

. /etc/rc.subr

name="mumbled"
rcvar=`set_rcvar`

command="/usr/sbin/${name}"
command_args="mock arguments > /dev/null 2>&1"

pidfile="/var/run/${name}.pid"

required_files="/etc/${name}.conf /usr/share/misc/${name}.rules"

sig_reload="USR1"

start_precmd="${name}_prestart"
stop_postcmd="echo Bye-bye"

extra_commands="reload plugh xyzzy"

plugh_cmd="mumbled_plugh"
xyzzy_cmd="echo 'Nothing happens.'"

mumbled_prestart()
{
    if checkyesno mumbled_smart; then
        rc_flags="-o smart ${rc_flags}"
    fi
    case "$mumbled_mode" in
    foo)
        rc_flags="-frotz ${rc_flags}"
        ;;
    bar)
        rc_flags="-baz ${rc_flags}"
        ;;
    *)
        warn "Invalid value for mumbled_mode"
        return 1
        ;;
    esac
    run_rc_command xyzzy
    return 0
}

mumbled_plugh()
{
    echo 'A hollow voice says "plugh".'
}

load_rc_config $name
run_rc_command "$1"

7 链接脚本到 rc.d 框架

　　当编写好了一个脚本，它需要被整合到 rc.d 中去。 一个重要的步骤就是安装脚本到 /etc/rc.d （对基本系统而言）或 /usr/local/etc/rc.d （对ports而言）中去。在 <bsd.prog.mk> 和 <bsd.port.mk> 中都为此提供了方便的接口， 通常你不必担心适当的所有权限和模式。系统脚本应当是通过可以在 src/etc/rc.d 找到的 Makefile 安装的。Port 脚本可以像 Porter's Handbook 中描述那样通过使用 USE_RC_SUBR 来被安装。

　　不过，我们应该预先考虑到我们脚本在系统启动顺序中的位置。 我们的脚本所处理的服务可能依赖于其它的服务。举个例子， 没有网络接口和路由选择的启用运行的话，一个网络守护进程是不起作用的。 即使一个服务看似什么都不需要，在基本文件系统检查挂载完毕之前也很难启动。

　　之前我们曾提到过 rcorder(8)。现在是时候来密切地关注下它了。 笼统地说，rcorder(8) 处理一组文件，检验它们的内容， 并从文件集合打印一个文件列表的依赖顺序到 stdout 标准输出。这点是用于保持文件内部的依赖信息， 而每个文件只能说明自己的依赖。一个文件可以指定如下信息：

• 它 提供 的 “条件” 的名字（意味着我们服务的名字）；

• 它 需求 的 “条件” 的名字；

• 应该 先 运行的文件的 “条件”的名字；

• 能用于从全部文件集合中选择一个子集的额外 关键字（ rcorder(8) 可通过选项而被指定来包括或省去由特殊关键字所列出的文件。）

　　并不奇怪的是，rcorder(8) 只能处理接近 sh(1) 语法的文本文件。rcorder(8) 所解读的特殊行看起来类似 sh(1) 的注释。这种特殊文本行的语法相当严格地简化了其处理。 请查阅 rcorder(8) 以获取更详细的信息。

　　除使用 rcorder(8) 的特殊行以外， 脚本可以坚持将其依赖的其它服务强制性启动。当其它服务是可选的， 并因系统管理员错误地在 rc.conf(5) 中禁用掉该服务而使其不能自行启动时，会需要这一点。

　　将这些谨记在心，我们来考虑下简单结合了依赖信息增强的守护进程脚本：

#!/bin/sh

# PROVIDE: mumbled oldmumble 
# REQUIRE: DAEMON cleanvar frotz
# BEFORE:  LOGIN
# KEYWORD: nojail shutdown

. /etc/rc.subr

name="mumbled"
rcvar=`set_rcvar`
command="/usr/sbin/${name}"
start_precmd="${name}_prestart"

mumbled_prestart()
{
    if ! checkyesno frotz_enable && \
        ! /etc/rc.d/frotz forcestatus 1>/dev/null 2>&1; then
        force_depend frotz || return 1
    fi
    return 0
}

load_rc_config $name
run_rc_command "$1"

　　跟前面一样，做如下详细分析：

8 给予 rc.d 脚本更多的灵活性

　　当进行启动或停止的调用时，rc.d 脚本应该作用于其所负责的整个子系统。例如， /etc/rc.d/netif 应该启动或停止 rc.conf(5) 中所描述的全部网络接口。每个任务都唯一地听从一个如 start 或 stop 这样的单独命令参数的指示。在启动和停止之间的时间， rc.d 脚本帮助管理员控制运行中的系统， 并其在需要的时候它将产生更多的灵活性和精确性。举个例子， 管理员可能想在 rc.conf(5) 中添加一个新网络接口的配置信息， 然后在不妨碍其它已存在接口的情况下将其启动。 在下次管理员可能需要关闭一个单独的网络接口。在魔幻的命令行中， 对应的 rc.d 脚本调用一个额外的参数， 网络接口名即可。

　　幸运的是，rc.subr(8) 允许传递任意多（取决于系统限制）的参数给脚本的方法。 由于这个原因，脚本自身的改变可以说是微乎其微。

　　rc.subr(8) 如何访问到附加的命令行参数呢？直接获取么？ 并非是无所不用其极的。首先，sh(1) 函数没有访问到调用者的定位参数，而 rc.subr(8) 只是这些函数的容器。其次，rc.d 指令的一个好的风格是由主函数来决定将哪些参数传递给它的方法。

　　所以 rc.subr(8) 提供了如下的方法： run_rc_command 传递其所有参数但将第一个参数逐字传递到各自的方法。首先， 发出以方法自身为名字的参数：start， stop，等等。这会被 run_rc_command 移出， 这样命令行中原本 $2 的内容将作为 $1 来提供给方法，等等。

　　为了说明这点，我们来修改原来的虚拟脚本， 这样它的信息将取决于所提供的附加参数。从这里出发：

#!/bin/sh

. /etc/rc.subr

name="dummy"
start_cmd="${name}_start"
stop_cmd=":"
kiss_cmd="${name}_kiss"
extra_commands="kiss"

dummy_start()
{
        if [ $# -gt 0 ]; then
                echo "Greeting message: $*"
        else
                echo "Nothing started."
        fi
}

dummy_kiss()
{
        echo -n "A ghost gives you a kiss"
        if [ $# -gt 0 ]; then
                echo -n " and whispers: $*"
        fi
        case "$*" in
        *[.!?])
                echo
                ;;
        *)
                echo .
                ;;
        esac
}

load_rc_config $name
run_rc_command "$@"

　　能注意到脚本里发生了那些实质性改变么？

9 进一步阅读

　　 Luke Mewburn 的原始文章 中讲述了 rc.d 的基本概要， 并详细阐述了其设计方案的原理。该文章提供了深入了解整个 rc.d 框架以及其所在的现代 BSD 操作系统的内容。

　　在 rc(8)，rc.subr(8)， 还有 rcorder(8) 的联机手册中，对 rc.d 组件做了非常详细的记载。 在你写脚本时，如果不去学习和参考这些联机手册的话， 你是无法完全发挥出 rc.d 的能量的。

　　工作中实际范例的主要来源就是运行的系统中的 /etc/rc.d 目录。 它的内容可读性非常好，因为大部分的枯燥的内容都深藏在 rc.subr(8) 中了。切记 /etc/rc.d 的脚本也不是神仙写出来的， 所以它们可能也存在着代码缺陷以及低级的设计方案。 但现在你可以来改进它们了！