BSD 中的实用 rc.d 脚本编程

最后更新于23天前

BSD 中的实用 rc.d 脚本编程

原文：

摘要

初学者可能会觉得很难将来自正式文档中关于 BSD rc.d 框架的事实与实际的 rc.d 脚本任务联系起来。本文将考虑几个典型的、逐渐复杂的案例，展示适用于每个案例的 rc.d 特性，并讨论它们如何工作。这样的探讨应该为进一步研究 rc.d 的设计和高效应用提供参考点。

1. 引言

历史上的 BSD 系统有一个单一的启动脚本 /etc/rc。它在系统启动时由调用，并执行所有多用户操作所需的用户空间任务：检查和挂载文件系统、设置网络、启动守护进程等。具体的任务列表在不同的系统中有所不同；管理员需要根据需要进行定制。除少数例外，/etc/rc 必须进行修改，真正的黑客对此感到满意。

单一脚本方法的真正问题在于，它无法控制从 /etc/rc 启动的各个组件。例如，/etc/rc 无法重新启动单个守护进程。系统管理员必须手动找到守护进程，终止它，等待它实际退出，然后浏览 /etc/rc 查找标志，最后输入完整的命令行来重新启动守护进程。如果要重新启动的服务包含多个守护进程或需要其他操作，这项任务会变得更加困难且容易出错。简而言之，单一脚本未能实现脚本的基本目的：使系统管理员的工作更轻松。

后来，为了单独启动最重要的子系统，曾试图将一些 /etc/rc 的部分内容拆分出来。著名的例子是 /etc/netstart 用于启动网络。它确实允许从单用户模式访问网络，但由于其代码的一些部分需要与本质上与网络无关的操作交织在一起，因此未能很好地融入自动启动过程。这就是为什么 /etc/netstart 最终变成了 /etc/rc.network 的原因。后者不再是一个普通的脚本；它由大型、复杂的函数组成，这些函数在系统启动的不同阶段由 /etc/rc 调用。然而，随着启动任务的多样化和复杂化，这种“准模块化”方法变得比单一的 /etc/rc 更加繁琐。

在没有干净且设计良好的框架的情况下，启动脚本不得不竭尽全力满足快速发展的基于 BSD 的操作系统的需求。最终，越来越明显的是，要实现一个细粒度且可扩展的 rc 系统，还需要更多的步骤。于是，BSD rc.d 应运而生。它的公认创始人是 Luke Mewburn 和 NetBSD 社区。后来它被引入到 FreeBSD。它的名称来源于系统脚本的位置，这些脚本用于单独的服务，位于 /etc/rc.d。很快我们将了解 rc.d 系统的更多组件，并查看如何调用单个脚本。

BSD rc.d 背后的基本思想是 细粒度模块化 和 代码重用。细粒度模块化 意味着每个基本的“服务”如系统守护进程或基本启动任务都有自己的脚本，能够启动服务、停止它、重新加载它、检查其状态。特定的操作通过脚本的命令行参数来选择。/etc/rc 脚本仍然负责系统启动，但它现在只是依次调用这些小脚本，并传递 start 参数。通过用 stop 参数运行同一组脚本，执行关闭任务变得也很容易，这由 /etc/rc.shutdown 完成。请注意，这与 Unix 系统的方式非常接近，Unix 系统有一组小型的专用工具，每个工具尽可能地完成其任务。代码重用 意味着常见操作通过函数实现，并集中在 /etc/rc.subr 中。现在，典型的脚本可能只是几行代码。最后，rc.d 框架的一个重要部分是，它帮助 /etc/rc 按照它们之间的依赖关系有序地运行这些小脚本。它也可以帮助 /etc/rc.shutdown，因为关闭顺序的正确顺序与启动顺序相反。

BSD rc.d 的设计在中有所描述，rc.d 组件在中得到了详细的文档说明。然而，对于一个 rc.d 新手来说，如何将众多的片段和组件结合起来，创建一个风格良好的特定任务脚本，可能并不显而易见。因此，本文将采用一种不同的方法来描述 rc.d。它将展示在一些典型情况下应该使用哪些特性，以及为什么。请注意，这不是一份操作指南，因为我们的目标不是提供现成的配方，而是展示一些进入 rc.d 领域的简单入口。这篇文章也不是相关手册页的替代品。在阅读本文时，遇到需要正式和完整文档的部分，应该随时参考手册页。

理解本文有一些前提条件。首先，你应该熟悉脚本语言，以掌握 rc.d。此外，你应该了解系统如何执行用户空间的启动和关闭任务，这在中有所描述。

本文侧重于 FreeBSD 分支的 rc.d。尽管如此，它对于 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" ⑧

需要注意的事项如下：

① 一个解释型脚本应该以魔法的“shebang”行开始。该行指定脚本的解释器程序。由于 shebang 行，脚本可以像二进制程序一样被调用，只要设置了执行位。例如，系统管理员可以从命令行手动运行我们的脚本：

# /etc/rc.d/dummy start

注意

技巧

注意
有关网络的某些有用函数由另一个包含文件 /etc/network.subr 提供。

注意

注意
为了使 rc.d 代码更统一，通常在适当的地方使用 ${name}。这样，许多行可以直接从一个脚本复制到另一个脚本。

⑥ 一个复杂方法的主体可以作为函数来实现。为函数命名时最好有意义。

重要

4. 可配置的虚拟脚本

#!/bin/sh

. /etc/rc.subr

name=dummy
rcvar=dummy_enable ①

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

load_rc_config $name ②
: ${dummy_enable:=no} ③
: ${dummy_msg="Nothing started."} ④

dummy_start()
{
	echo "$dummy_msg" ⑤
}

run_rc_command "$1"

在这个例子中有什么变化呢？

① 变量 rcvar 指定了 ON/OFF 开关变量的名称。

注意

注意
# /etc/rc.d/dummy onestart

重要

注意

⑤ 现在我们使用 dummy_msg 来控制脚本，即显示一个变量消息。这里使用 shell 函数是多余的，因为它只运行一条命令；一个同样有效的替代方法是：

start_cmd="echo \"$dummy_msg\""

5. 简单守护进程的启动与关闭

#!/bin/sh

. /etc/rc.subr

name=mumbled
rcvar=mumbled_enable

command="/usr/sbin/${name}" ①

load_rc_config $name
run_rc_command "$1"

这个脚本看起来简单而又简洁，不是吗？让我们分析一下这个小脚本。唯一需要注意的新事物是：

注意

6. 启动和关闭一个高级守护进程

让我们为之前的脚本增加一些内容，使其变得更加复杂和功能丰富。默认方法对我们来说已经足够好，但有时我们可能需要调整它们的一些方面。现在我们将学习如何根据我们的需求来调整默认方法。

#!/bin/sh

. /etc/rc.subr

name=mumbled
rcvar=mumbled_enable

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"

① 除了 $command 外，还可以通过 command_args 传递额外的参数。这些参数将添加到 $mumbled_flags 后面。由于最终的命令行会通过 eval 执行，因此可以在 command_args 中指定输入输出重定向。

注意

注意
可以通过在命令行中使用 forcestart 参数来强制跳过这些前置检查。

④ 如果守护进程需要的信号与默认的不同，我们可以自定义信号。例如，sig_reload 指定了用于重新加载守护进程配置的信号，默认是 SIGHUP。另一个信号是用于停止守护进程的，默认是 SIGTERM，但也可以通过设置 sig_stop 来改变它。

注意

注意
即使我们重写了默认方法并定义了自定义的 argument_cmd，也可以使用 argument_precmd 或 argument_postcmd。特别地，前者非常适合用来检查自定义的复杂条件，只有在条件满足时才执行命令本身。结合使用 argument_precmd 和 argument_cmd 可以将检查与动作逻辑上分开。

⑦ 如果我们想实现自定义的命令（也可以称为命令），只需将它们列在 extra_commands 中，并提供相应的处理方法。

注意

⑧⑭ 我们的脚本支持两个非标准命令，plugh 和 xyzzy。它们在 extra_commands 中列出，现在是时候为它们提供方法了。xyzzy 的方法就是内联定义的，而 plugh 则由 mumbled_plugh 函数实现。

# /etc/rc.d/mumbled
Usage: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll)

重要
checkyesno 函数接受的是 变量名。不要将变量的展开值传给它；那样不会按预期工作。
下面是 checkyesno 的正确用法：
if checkyesno mumbled_enable; then
       foo
fi
相反，如下所示调用 checkyesno 将不起作用 —— 至少不会按预期工作：
if checkyesno "${mumbled_enable}"; then
       foo
fi

⑩ 我们可以通过在 $start_precmd 中修改 rc_flags 来影响传递给 $command 的参数。

⑫ 方法及其 pre-command 返回的退出码默认不会被忽略。如果 argument_precmd 返回一个非零的退出码，则主方法将不会被执行。反过来，除非主方法返回零退出码，argument_postcmd 也不会被调用。

注意
不过，可以通过在命令行参数前加上 force，如 forcestart，来指示 [rc.subr(8)] 忽略这些退出码并无论如何执行所有命令。

7. 将脚本接入 rc.d 框架

不过，在此之前，我们应该先考虑脚本在系统启动序列中的位置。脚本所管理的服务很可能依赖于其他服务。例如，一个网络守护进程在网络接口和路由尚未启动之前是无法工作的。即使某个服务看似不依赖其他内容，它也不可能在基本文件系统被检查和挂载之前启动。

它所提供的“条件”（即我们所说的服务）；
它所需要的“条件”；
它应该在其前运行的“条件”；
额外的 关键字，这些关键字可用于从整个文件集中选择子集（可以通过参数告知 [rcorder(8)] 包括或排除含特定关键字的文件）。

了解了以上这些基础知识之后，我们来看一个添加了依赖信息的简单守护进程脚本示例：

#!/bin/sh

# PROVIDE: mumbled oldmumble ①
# REQUIRE: DAEMON cleanvar frotz ②
# BEFORE:  LOGIN ③
# KEYWORD: nojail shutdown ④

. /etc/rc.subr

name=mumbled
rcvar=mumbled_enable

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"

如前所述，接下来是详细分析：

① 这一行声明了我们的脚本所提供的“条件”名称。现在其他脚本就可以通过这些名称来记录对我们脚本的依赖关系。

注意
通常，一个脚本只会声明一个所提供的条件。不过，并没有什么限制我们在此列出多个条件，例如为了兼容性原因。
无论如何，主要的（或唯一的）PROVIDE: 条件名称应当与 ${name} 相同。

注意
BEFORE: 行不应被滥用于绕过其他脚本中不完整的依赖列表。使用 BEFORE: 的合理情形是：另一个脚本并不关心我们的脚本是否存在，但如果我们的脚本能在它之前运行，则可以更好地完成任务。一个典型的现实示例是网络接口与防火墙：虽然接口在工作时并不依赖防火墙，但若防火墙在网络流量出现前就已就绪，系统安全性将受益。

nostart 该服务应由手动启动，或根本不启动。自动启动流程将忽略此脚本。若与 shutdown 关键字同时使用，可用于编写仅在系统关机时执行操作的脚本。

shutdown 若服务需要在系统关机前被停止，必须显式列出此关键字。

注意

⑤ 首先，force_depend 应当谨慎使用。通常情况下，如果你的 rc.d 脚本之间有依赖关系，最好是重新审视它们的配置变量层次结构。

8. 给 rc.d 脚本提供更多灵活性

为了说明这个机会，让我们修改这个原始的虚拟脚本，使得其消息依赖于传递的额外参数。我们来看一下：

#!/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 "$@" ③

我们可以注意到脚本中的哪些关键变化？

# /etc/rc.d/dummy start
Nothing started.

# /etc/rc.d/dummy start Hello world!
Greeting message: Hello world!

② 同样的方式适用于脚本提供的任何方法，而不仅仅是标准方法。我们添加了一个名为 kiss 的自定义方法，它同样可以利用额外的参数，就像 start 方法那样。例如：

# /etc/rc.d/dummy kiss
A ghost gives you a kiss.

# /etc/rc.d/dummy kiss Once I was Etaoin Shrdlu...
A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu...

③ 如果我们只想将所有额外的参数传递给某个方法，我们可以简单地在脚本的最后一行将 "$@" 替换为 "$1"，在该行调用 run_rc_command。

重要

注意
当前 run_rc_command 可能存在一个 bug，导致它无法保持参数之间的原始边界。也就是说，包含空格的参数可能无法正确处理。该 bug 源于 $* 的误用。

9. 使脚本准备好用于服务 Jail

启动长期运行服务的脚本适合用于服务 Jail，并应配有适当的服务 Jail 配置。

以下是一些不适合在服务 Jail 中运行的脚本示例：

仅在 start 命令中更改程序或内核的运行时设置的任何脚本，
尝试挂载某些内容的脚本，
查找并删除文件的脚本。

不适合在服务 Jail 中运行的脚本需要防止在服务 Jail 中使用。

如果一个脚本具有长期运行的服务，在启动或停止之前需要执行上述操作中的某些操作，则可以将其拆分为两个有依赖关系的脚本，或使用脚本的 precommand 和 postcommand 部分来执行该操作。

默认情况下，只有脚本的 start 和 stop 部分会在服务 Jail 中运行，其余部分则在 Jail 外部运行。因此，任何在 start/stop 部分中使用的设置不能通过例如 precommand 来设置。

#!/bin/sh

. /etc/rc.subr

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

: ${dummy_svcj_options:=""} ①

dummy_start()
{
        echo "Nothing started."
}

load_rc_config $name
run_rc_command "$1"

① 如果脚本需要在 Jail 中运行，它必须具有可覆盖的服务 Jail 配置。如果它不需要网络访问或访问 Jail 中受限的任何其他资源，则像显示的那样使用空配置即可。

如果出于某种原因，脚本无法在服务 Jail 中运行，例如因为无法运行或在 Jail 中运行没有意义，则使用以下方法：

#!/bin/sh

. /etc/rc.subr

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

dummy_start()
{
        echo "Nothing started."
}

load_rc_config $name
dummy_svcj="NO"		# 在 svcj 中运行没有意义 ①
run_rc_command "$1"

10. 高级 rc 脚本：实例化

有时需要运行多个实例的服务。通常，你希望能够独立启动/停止这些实例，并且希望每个实例有一个单独的配置文件。每个实例应在启动时启动，能够在更新后存活，并受益于更新。

以下是支持此功能的 rc 脚本示例：

#!/bin/sh

#
# PROVIDE: dummy
# REQUIRE: NETWORKING SERVERS
# KEYWORD: shutdown
#
# 将以下行添加到 /etc/rc.conf.local 或 /etc/rc.conf
# 以启用此服务：
#
# dummy_enable (bool):	设置为 YES 以在启动时启用 dummy。
#			默认值：NO
# dummy_user (string):	运行时使用的用户账户。
#			默认值：www
#

. /etc/rc.subr

case $0 in ①
/etc/rc*)
	# 在启动（关机）时，$0 是 /etc/rc (/etc/rc.shutdown)，
	# 所以从 $_file 获取脚本的名称
	name=$_file
	;;
*)
	name=$0
	;;
esac

name=${name##*/} ②
rcvar="${name}_enable" ③
desc="该服务的简短描述"
command="/usr/local/sbin/dummy"

load_rc_config "$name"

eval "${rcvar}=\${${rcvar}:-'NO'}" ④
eval "${name}_svcj_options=\${${name}_svcj_options:-'net_basic'}" ⑤
eval "_dummy_user=\${${name}_user:-'www'}" ⑥

_dummy_configname=/usr/local/etc/${name}.cfg ⑦
pidfile=/var/run/dummy/${name}.pid
required_files ${_dummy_configname}
command_args="-u ${_dummy_user} -c ${_dummy_configfile} -p ${pidfile}"

run_rc_command "$1"

③ 指定用于 rc.conf 中启用该服务的变量名，基于此脚本的文件名。在此示例中，它解析为 dummy_enable。

④ 确保 _enable 变量的默认值为 NO。

⑤ 是为服务特定的框架变量提供一些默认值的示例，在此示例中是服务监狱选项。

⑥ 和 ⑦ 设置脚本内部的变量（注意在 _dummy_user 前的下划线，它使其与可以在 rc.conf 中设置的 dummy_user 区分开）。

⑤ 部分用于脚本内部未使用但在 rc 框架中使用的变量。所有在脚本中作为参数使用的变量都分配给一个通用变量，如⑦所示，以便更容易引用它们（不需要在每个使用位置重新评估它们）。

现在，如果启动脚本有不同的名称，此脚本将表现不同。这允许创建它的符号链接：

# ln -s dummy /usr/local/etc/rc.d/dummy_foo
# sysrc dummy_foo_enable=YES
# service dummy_foo start

上述命令创建了一个名为 dummy_foo 的 dummy 服务实例。它不会使用配置文件 /usr/local/etc/dummy.cfg，而是使用配置文件 /usr/local/etc/dummy_foo.cfg（⑦），并且它使用 /var/run/dummy/dummy_foo.pid 作为 PID 文件，而不是 /var/run/dummy/dummy.pid。

dummy 和 dummy_foo 服务可以独立管理，而启动脚本会在包更新时自动更新（由于符号链接）。这不会更新 REQUIRE 行，因此没有简单的方法依赖特定的实例。为了在启动顺序中依赖特定实例，必须进行复制，而不是使用符号链接。这将防止在安装更新时自动拾取启动脚本的更改。

11. 深入阅读

上一页Port 导师指南下一页问题报告处理指南

最后更新于23天前