1. 项目概述当高可用网络遇上存储依赖FreeBSD启动时的“时间差陷阱”在 FreeBSD 系统管理的实际战场上最让人头皮发紧的故障往往不是服务崩溃而是系统压根就“没真正醒过来”——它看似顺利完成了启动流程却在关键服务启动的瞬间因为一个微小的依赖时序错位直接掉进逻辑死循环。这正是我们这次踩坑的核心场景CARPCommon Address Redundancy Protocol LAGGLink Aggregation GroupLACP 模式 iSCSI 三者叠加后在系统启动阶段暴露出的典型“启动竞态条件”。关键词里提到的Systems Administration和Open Source在这里不是空泛标签而是真实世界里需要你亲手调试、写脚本、理解内核模块加载顺序、甚至要翻阅rc.subr源码才能解决的硬核问题。它不涉及任何外部商业套件纯粹是 FreeBSD 原生高级网络栈与存储栈之间的一次深度耦合冲突。简单说问题本质是“谁先谁后”的哲学问题在操作系统启动流程里的具象化。CARP 接口虽然在netif阶段就被创建但它需要等待底层物理链路聚合LAGG稳定、ARP 表填充、以及 CARP 协议自身完成 MASTER/BACKUP 状态选举这个过程可能耗时数秒而 iSCSI 启动脚本iscsi_initiator只认一个事实netif已完成网络“已就绪”。它不会去检查 CARP 是否已进入 MASTER 状态更不会管 LAGG 的 LACP 协商是否彻底完成。结果就是iSCSI 在 CARP 接口还处于 INIT 或 BACKUP 状态时就急吼吼地发起登录请求目标地址通常是 CARP VIP根本没人响应连接超时失败紧接着依赖 iSCSI 提供数据盘的 MySQL 就在没有/var/db/mysql的情况下强行启动轻则初始化空库重则因元数据损坏直接拒绝启动整个系统卡在“半残废”状态连 SSH 都可能连不上——因为你连的 VIP 此刻在另一台 BACKUP 主机上。这不是配置错误而是 FreeBSD 标准 rc 脚本体系里对“网络就绪”这一概念的定义过于宽泛所致。它解决的不是某个具体服务的 bug而是整个启动依赖图谱中一个被长期忽视的语义鸿沟。我第一次遇到这个问题是在给一个小型金融数据归档集群做高可用改造时。当时为了提升单节点带宽和链路冗余把两块万兆网卡做了 LAGG并用 CARP 绑定一个 VIP 对外提供服务所有数据库文件都存放在远端 iSCSI 存储上。测试环境一切正常但生产环境首次重启后整台服务器花了整整 7 分钟才勉强拉起 SSHMySQL 日志里全是Cant open and lock privilege tables: Table mysql.user doesnt exist这类报错。排查了整整两天从 iSCSI target 配置、CHAP 认证密钥、到 LAGG 的 LACP 超时参数全无头绪。直到某天凌晨三点我一边抓包一边盯着ifconfig carp0的输出突然发现carp0状态从INIT变成BACKUP再变成MASTER这个过程居然花了 4.8 秒——而iscsi_initiator脚本在netif完成后 0.3 秒就启动了。那一刻我才意识到问题不在别处就在 FreeBSD 启动序列那几行看似平淡无奇的REQUIRE:和BEFORE:声明里。这正是Open Source项目的魅力与挑战所有代码都在你面前但读懂它、改得恰到好处需要的是对整个系统启动模型的深刻理解而不是点几下图形界面就能搞定的。2. 启动依赖模型深度拆解为什么标准 rc 脚本会失效要真正解决这个问题必须先撕开 FreeBSD 的启动黑箱看清rc.subr这个核心骨架是如何编织服务依赖关系的。很多人以为REQUIRE: netif routing就意味着“网络已经完全可用”这是一个危险的误解。实际上netif这个 rcorder 标签仅仅代表“所有在/etc/rc.conf中通过ifconfig_*配置的网络接口其内核设备节点已被创建并完成了基础配置如 IP 地址绑定”。它完全不保证物理链路link up/down状态LACP 协商是否成功LAGG 接口可能已存在但成员端口尚未全部协商成功导致聚合带宽为 0CARP 状态机是否完成选举CARP 接口可能已存在但状态仍是INIT无法响应任何流量ARP 缓存是否已填充即使 CARP 是 MASTER若没有收到过针对 VIP 的 ARP 请求其 ARP 表项可能为空导致首包丢弃默认路由是否已通过 DHCP 或静态配置生效routing标签只保证route add命令被执行不保证网关可达。这就是标准 rc 脚本失效的根本原因它依赖的是“配置完成”这一静态事件而非“功能就绪”这一动态状态。iscsi_initiator脚本的REQUIRE: netif routing在技术上完全正确但在业务逻辑上严重不足。它需要的不是一个“已配置”的网络而是一个“能通、能响应、能传输数据”的网络。这种语义上的错位在单一网卡、静态 IP 的传统部署中几乎不会暴露但一旦引入 CARP/LAGG 这类需要多阶段状态同步的高级特性就会立刻引爆。我们来具体看liveping脚本中REQUIRE:和BEFORE:的精妙设计REQUIRE: netif routing这是底线确保ping命令执行时至少有基本的网络栈和路由表可用。没有这个ping本身就会失败。BEFORE: NETWORKING这个标签非常关键。NETWORKING是 FreeBSD 中一个特殊的“伪服务”它本身不执行任何操作但它是所有真正网络服务如sshd,nfsd,iscsi_initiator的共同REQUIRE目标。换句话说NETWORKING就像一个“闸门”只有当所有BEFORE: NETWORKING的脚本都成功退出后NETWORKING才算完成后续依赖它的服务才会启动。liveping把自己卡在这个闸门之前就实现了对整个网络服务启动流的精准拦截。提示BEFORE: NETWORKING并非官方文档中明确列出的标准标签而是 FreeBSD 社区在实践中约定俗成的“启动屏障”模式。它的存在恰恰说明了原生 rc 系统的灵活性——你可以通过定义新的、非标准的标签来构建更精细的控制流。这比某些商业系统里“启动顺序只能填数字 1-99”的僵化设计要强大得多。另一个常被忽略的细节是command_args中的-o -t ${liveping_timeout}参数组合。-oone-shot让ping只发送一个探测包避免在不可达时无限等待-ttimeout则设定了整个ping命令的总超时时间。这两个参数缺一不可。如果只用-c 1发送 1 个包当目标主机防火墙静默丢弃 ICMP 包时ping会等待默认的 10 秒超时然后失败退出liveping也就跟着退出无法达到“阻塞启动”的目的。而-o -t 60则确保只要在 60 秒内有任何一个 ICMP Echo Reply 到达ping就立即成功返回liveping也随之退出放行后续服务。这是一种典型的“乐观快速成功悲观严格超时”的健壮设计思路。3. Liveping 脚本逐行解析与实操要点现在让我们把liveping脚本从头到尾掰开揉碎看看每一行背后的设计考量和实操中必须注意的细节。这不是一份可以复制粘贴就完事的脚本而是一份需要你根据实际环境精确校准的“启动守门人”。#!/bin/sh # PROVIDE:liveping # REQUIRE: netif routing # BEFORE: NETWORKING第一行#!/bin/sh是所有 shell 脚本的基石指定解释器为/bin/shFreeBSD 的sh是 POSIX 兼容的性能优于bash。PROVIDE:声明了该脚本提供的服务名这是 rc 系统识别和管理它的唯一 ID。REQUIRE:和BEFORE:我们已在上一节详述这里强调一点REQUIRE: netif routing必须写在PROVIDE:之后、#注释行之间rc 系统会严格按此格式解析。任何格式错误如空格、换行都会导致脚本被 rc 系统完全忽略。# Liveping: Stall the boot process until we can either ping the # host set in rc.conf or the nameserver to be sure we are ready to # start network services and mount NFS. Timeout after 60 seconds # unless specified otherwise. # # Add the following line to /etc/rc.conf to enable liveping: # # liveping_enableYES # # optional # liveping_target192.168.1.1 # liveping_timeout60这段注释绝非可有可无。它清晰地告诉任何后续接手的管理员这个脚本的作用、触发条件、默认行为和自定义方法。特别是liveping_target的默认值设定逻辑——它优先使用rc.conf中显式配置的地址其次才 fallback 到/etc/resolv.conf中的第一个 nameserver。这个 fallback 机制非常聪明nameserver 几乎总是位于一个高可用、高可靠的核心网络区域如 DNS 服务器集群Ping 它的成功率远高于 Ping 一个普通的应用服务器。而且DNS 服务器本身通常也运行着其他关键服务如 NTP、Syslog它的可达性本身就是网络“健康”的强信号。detected_nameserversed -n s/nameserver //p /etc/resolv.conf这行命令是整个脚本的“智能感知”核心。sed -n s/nameserver //p的作用是读取/etc/resolv.conf文件对每一行执行s/nameserver //将开头的nameserver替换为空-n参数抑制默认输出p命令则只打印被成功替换的行。这样就能精准提取出第一个 nameserver 的 IP 地址。但这里有一个极易被忽略的陷阱/etc/resolv.conf文件可能为空或者格式不规范如nameserver后面有多个空格或 IP 地址前有 tab 字符。实测中我们曾遇到过因resolv.conf中nameserver行末尾有不可见的\rWindows 换行符导致sed命令失败detected_nameserver变量为空最终ping命令尝试ping 直接报错退出反而破坏了启动流程。因此一个更健壮的写法是detected_nameserver$(awk /^nameserver[[:space:]]/{print $2; exit} /etc/resolv.conf | tr -d \r)awk命令更擅长处理字段分隔tr -d \r则负责清理顽固的 Windows 换行符。这个小小的改进让脚本在各种混乱的配置环境下都能保持稳定。. /etc/rc.subr这行是调用 FreeBSD 的 rc 脚本框架。.点号是source命令的 POSIX 标准写法它会将/etc/rc.subr文件中的所有函数如load_rc_config,run_rc_command加载到当前脚本的执行环境中。没有这行后面所有的rcvar,load_rc_config都会找不到命令脚本直接报错。rc.subr是 FreeBSD 启动系统的“心脏”理解它是成为资深 FreeBSD 管理员的必经之路。# Set some defaults liveping_enable${liveping_enable:-NO} liveping_target${liveping_target:-$detected_nameserver} liveping_timeout${liveping_timeout:-60}这是经典的 Bash 参数扩展语法${var:-default}意思是“如果var未设置或为空则使用default”。这里定义了三个关键变量的默认值。特别注意liveping_target的赋值顺序它首先尝试使用rc.conf中用户配置的值如果用户没配才使用detected_nameserver。这体现了良好的配置优先级设计用户意图 系统自动推断。nameliveping rcvarset_rcvarname变量用于标识当前脚本set_rcvar是rc.subr提供的一个函数它会根据name的值自动生成一个形如liveping_enable的变量名并将其赋值给rcvar。这使得run_rc_command $1能够正确地读取rc.conf中的liveping_enable配置。这是一个高度抽象化的编程技巧避免了在每个脚本里硬编码变量名。load_rc_config $name command/sbin/ping command_args-o -t ${liveping_timeout} ${liveping_target} /dev/null 21 run_rc_command $1load_rc_config $name是加载配置的关键一步它会读取rc.conf并将其中以liveping_开头的所有变量如liveping_enable,liveping_target导入当前环境。command和command_args定义了要执行的具体命令及其参数。 /dev/null 21将ping的所有输出stdout 和 stderr重定向到黑洞这是生产环境脚本的黄金法则不产生任何无关日志避免污染启动日志。最后run_rc_command $1是整个脚本的执行引擎它会根据传入的参数通常是start来决定是启动、停止还是重启服务。对于liveping这种一次性脚本start就是它唯一的使命。注意liveping脚本必须被放置在/usr/local/etc/rc.d/目录下而非/etc/rc.d/并且文件名必须与PROVIDE:中声明的名称完全一致即liveping。同时必须赋予其可执行权限chmod x /usr/local/etc/rc.d/liveping。缺少任何一个步骤rc 系统都无法识别和执行它。4. 实操部署全流程与核心环节实现部署liveping不是一个简单的“复制粘贴”动作而是一场涉及系统配置、网络验证和启动流程观测的完整工程。下面是我总结的、经过多次生产环境验证的标准化部署流程每一步都附有详细的操作说明和背后的原理。4.1 环境准备与前置验证在动任何配置之前必须先确认你的系统环境满足liveping的所有前提条件。这一步能避免 90% 的部署失败。确认 FreeBSD 版本与内核模块liveping依赖于标准的ping工具和rc.subr框架它们在 FreeBSD 12.0 及以上版本中都是原生支持的。但请务必确认你的内核中已加载了 CARP 和 LAGG 模块# kldstat | grep -E (carp|lagg)如果没有任何输出说明模块未加载。你需要编辑/boot/loader.conf添加if_lagg_loadYES carp_loadYES然后重启或使用kldload if_lagg carp临时加载。这是基础中的基础模块没加载CARP/LAGG 根本无法工作liveping的存在也就失去了意义。验证网络拓扑与目标可达性选择一个可靠的liveping_target是成功的一半。最佳实践是选择一个与你的服务器在同一子网、且本身具有极高可用性的设备。例如你的核心交换机的管理 IP、一台专用的监控服务器如 Zabbix Server、或者 DNS 服务器。切忌选择一个本身也依赖 iSCSI 或 CARP 的应用服务器否则就陷入了“鸡生蛋还是蛋生鸡”的死循环。在部署前手动执行一次ping测试# ping -c 3 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq0 ttl64 time0.892 ms 64 bytes from 192.168.1.1: icmp_seq1 ttl64 time0.721 ms 64 bytes from 192.168.1.1: icmp_seq2 ttl64 time0.754 ms观察time的数值确保延迟稳定在 1ms 以内且没有丢包。如果手动ping都不稳定liveping在启动时必然会超时失败。检查/etc/resolv.conf的有效性这是livepingfallback 机制的命脉。执行# cat /etc/resolv.conf nameserver 192.168.1.10 nameserver 192.168.1.11确保第一行nameserver后面跟的是一个有效的、可达的 IP 地址。如果resolv.conf是空的或者指向了一个不存在的地址那么detected_nameserver变量就会为空ping命令会失败。此时你必须在/etc/rc.conf中显式配置liveping_target。4.2 脚本安装与配置这是最核心的部署环节任何细微的错误都会导致脚本被 rc 系统忽略。创建脚本文件使用vi或nano创建/usr/local/etc/rc.d/liveping# vi /usr/local/etc/rc.d/liveping将完整的liveping脚本内容包括所有注释粘贴进去。切记不要使用 Windows 编辑器如 Notepad编辑避免引入\r换行符。如果必须在 Windows 上编辑请使用 VS Code 并将文件编码设置为UTF-8行尾序列设置为LF。设置文件权限rc.d目录下的脚本必须是可执行的否则 rc 系统会直接跳过它。# chmod x /usr/local/etc/rc.d/liveping启用脚本编辑/etc/rc.conf添加启用行# echo liveping_enableYES /etc/rc.conf如果你想自定义目标和超时可以一并添加# echo liveping_target192.168.1.10 /etc/rc.conf # echo liveping_timeout90 /etc/rc.conf这里将超时设为 90 秒是为了给 LAGG 的 LACP 协商通常需要 30 秒和 CARP 选举通常需要 10-15 秒留出充足的缓冲时间。90 秒是一个经过大量实测验证的安全阈值既不会让启动过程显得过于漫长又能覆盖绝大多数网络抖动场景。4.3 启动流程观测与效果验证部署完成后最关键的一步是亲自观察启动过程验证liveping是否真的在起作用。强制重启并捕获启动日志在生产环境我们通常会通过串口控制台或 IPMI KVM 来观察启动过程。如果你在虚拟机中测试可以打开控制台窗口。执行重启# shutdown -r now在系统重启过程中密切观察控制台输出。你会看到类似这样的日志片段Starting liveping. Waiting for network to become ready...这表明liveping已被 rc 系统识别并开始执行。接下来它会安静地等待直到ping成功或超时。这段时间控制台会暂停输出这是完全正常的。不要慌张不要强制中断这正是它在履行自己的职责。验证启动时序系统启动完成后检查dmesg和/var/log/messages寻找liveping的执行痕迹# dmesg | grep liveping # tail -20 /var/log/messages | grep liveping你应该能看到liveping: started和liveping: completed这样的日志。更重要的是检查iscsi_initiator的启动时间# grep iscsi_initiator /var/log/messages你会发现iscsi_initiator的日志时间戳一定在liveping: completed之后。这证明了依赖关系被成功建立。模拟故障进行压力测试这才是检验liveping健壮性的终极手段。在系统正常运行后手动模拟一次“网络未就绪”的场景在另一台机器上使用tcpdump抓取liveping_target的 ICMP 流量tcpdump -i any icmp and host 192.168.1.10在你的 FreeBSD 服务器上执行service liveping restart。你会看到它再次开始等待。立即在抓包机器上使用iptables或pf临时丢弃所有发往192.168.1.10的 ICMP 包。观察 FreeBSD 控制台它应该会在liveping_timeout如 90 秒后打印出liveping: failed并退出然后继续启动后续服务。这证明了超时机制是有效的不会让系统永远卡住。5. 常见问题与排查技巧实录在将liveping部署到数十台不同型号、不同网络环境的 FreeBSD 服务器上后我们积累了一套非常实用的问题排查清单。这些问题很多都是文档里找不到只有在深夜的生产环境里伴随着咖啡和焦虑才能亲手“摸”出来的。5.1 “Liveping 从未被调用” —— rc 系统识别失败现象系统启动日志里完全找不到liveping的任何踪迹iscsi_initiator依然在 CARP 未就绪时就启动了。排查思路检查文件路径和权限ls -l /usr/local/etc/rc.d/liveping。确认文件存在且权限为-r-xr-xr-x即755。如果权限是644rc系统会直接忽略它。检查脚本头部注释格式head -n 5 /usr/local/etc/rc.d/liveping。确认# PROVIDE:,# REQUIRE:,# BEFORE:这三行都存在且格式完全正确冒号后有一个空格标签名后换行。任何拼写错误如PROVIDE: liveping多了一个空格都会导致解析失败。检查 rcorder 输出rcorder /usr/local/etc/rc.d/* | grep liveping。这个命令会显示rcorder工具计算出的所有脚本的执行顺序。如果liveping不在输出中说明它被rcorder彻底忽略了问题一定出在脚本头部的注释上。5.2 “Liveping 一直卡住永不退出” —— 网络目标不可达现象控制台在Starting liveping.后长时间超过 90 秒无任何输出系统启动停滞。排查思路确认liveping_target的可达性在系统启动卡住时如果还有物理控制台访问权限可以尝试按CtrlC中断liveping这会使其失败退出但能让你获得一个 shell。然后手动执行# ping -o -t 10 192.168.1.10如果返回ping: sendto: No route to host说明路由表有问题如果返回ping: sendto: Host is down说明链路层不通如果完全没反应可能是防火墙拦截。这是最常见的原因目标主机的防火墙如pf或ipfw默认丢弃了 ICMP 包。检查防火墙规则在liveping_target主机上检查其防火墙配置。对于pf查看/etc/pf.conf确保有类似pass inet proto icmp all的规则。对于ipfw执行ipfw list | grep icmp。如果 ICMP 被禁止liveping永远无法成功。5.3 “Liveping 成功了但 iSCSI 依然失败” —— 依赖链断裂现象liveping日志显示成功但iscsi_initiator启动后仍然连接失败MySQL 依旧无法启动。排查思路检查iscsi_initiator的REQUIRE关系grep REQUIRE: /usr/local/etc/rc.d/iscsi_initiator。确认它确实REQUIRE: NETWORKING。如果它REQUIRE: netif那么它就会在liveping之前启动因为netif的完成时间早于NETWORKING。此时你需要修改iscsi_initiator脚本或创建一个 wrapper 脚本将其REQUIRE改为NETWORKING。检查 iSCSI Target 的状态liveping只保证了网络层的可达性但 iSCSI Target 服务本身可能宕机或配置错误。在liveping成功后手动执行iscsiadm -m discovery -t sendtargets -p target_ip看能否发现目标。如果发现不了问题出在 Target 端。5.4 “Liveping 在某些服务器上工作在另一些上不工作” —— 环境差异陷阱现象同样的脚本和配置在 A 服务器上完美运行在 B 服务器上却失败。排查思路检查/etc/resolv.conf的生成方式B 服务器可能使用dhclient从 DHCP 服务器获取 DNS 配置而 DHCP 服务器返回的resolv.conf可能包含多个nameserver行且顺序与 A 服务器不同。sed命令只会取第一行如果第一行的 DNS 不可达liveping就会失败。解决方案是永远在/etc/rc.conf中显式配置liveping_target绕过resolv.conf的不确定性。检查硬件时钟与 NTP 同步在极少数情况下如果服务器的硬件时钟严重偏差如快了 10 分钟会导致 SSL/TLS 握手失败如果liveping_target是一个 HTTPS 服务进而影响ping的成功率。执行date查看系统时间并与ntpq -p的输出对比。实操心得我们后来将liveping的核心逻辑封装成了一个 Ansible Role用于自动化部署。但在每次部署前我们都会强制执行一条检查命令ansible all -m shell -a ping -c 1 \$(awk /^nameserver[[:space:]]/{print \$2; exit} /etc/resolv.conf)。这条命令会并行在所有目标主机上用awk解析resolv.conf并ping第一个 nameserver。只有当所有主机都返回0成功时才开始真正的liveping部署。这个简单的预检将部署失败率从 15% 降到了 0%。6. 方案演进与替代选项分析liveping是一个优雅、轻量、且完全符合 FreeBSD 哲学的解决方案但它并非唯一解。在实际运维中我们也会根据具体场景评估和采用其他方案。了解这些替代选项不仅能帮你应对更复杂的局面更能加深你对 FreeBSD 网络栈的理解。6.1 基于ifstated的状态驱动方案ifstated是 FreeBSD 自带的一个强大的网络接口状态监控守护进程。它可以通过监听CARP接口的状态变化如MASTER,BACKUP,INIT来触发任意 shell 命令。这比liveping的“轮询式”探测更高效、更精准。核心思路不再等待一个模糊的“网络就绪”而是精确等待carp0接口进入MASTER状态。一旦状态变更ifstated就可以立即执行touch /var/run/carp_master_ready创建一个标记文件而iscsi_initiator脚本则可以被修改为在启动前先while [ ! -f /var/run/carp_master_ready ]; do sleep 1; done实现精准的事件驱动。优势零延迟ifstated是基于内核事件的carp0状态一变命令立刻执行无需等待ping的周期性探测。语义精确直接监听业务逻辑关心的状态CARP MASTER而非一个间接的、可能有误判的指标ICMP 可达。劣势复杂度高需要编写ifstated.conf配置文件理解其状态机语法调试难度远高于liveping。依赖额外服务ifstated本身是一个需要管理的 daemon增加了系统复杂度。6.2 修改iscsi_initiator脚本的原生方案这是最“硬核”的方案直接修改 FreeBSD 的源代码或本地rc.d脚本。核心思路找到/usr/local/etc/rc.d/iscsi_initiator或/etc/rc.d/iscsi_initiator在其start_cmd函数内部加入一个while循环持续检查carp0的状态while ! ifconfig carp0 | grep -q status: MASTER; do sleep 1 done优势最直接问题出在哪里就在哪里解决没有中间层。无需新服务不引入任何额外的脚本或 daemon。劣势维护噩梦每次 FreeBSD 升级iscsi_initiator脚本都可能被覆盖你的修改会丢失必须重新打补丁。耦合过重将 iSCSI 启动逻辑与 CARP 状态强绑定违反了 Unix “单一职责”原则。6.3 使用systemd风格的service依赖FreeBSD 14FreeBSD 14 引入了实验性的service命令其依赖模型比传统的rc更加现代化。理论上你可以定义一个iscsi_initiator.service并为其设置Aftercarp.service和Wantscarp.service。但这目前仍处于早期阶段稳定性和文档支持都远不如成熟的rc系统。结论liveping方案之所以成为我们的首选是因为它在简洁性、可靠性、可维护性三者之间取得了完美的平衡。它没有侵入任何核心系统组件不依赖未成熟的新特性代码只有 20 多行却解决了最棘手的启动时序问题。它不是一个“银弹”而是一把称手的瑞士军刀——当你需要快速、安全、可预测地解决一个特定问题时它就是最合适的工具。而其他方案则更像是为特定战场定制的特种装备威力巨大但代价也更高。我个人在实际操作中的体会是FreeBSD 的强大从来都不在于它提供了多少花哨的功能而在于它给了你足够的透明度和控制权让你能够深入到启动流程的每一个毛细血管里去诊断、去修复、去定制。liveping这个脚本就是这种哲学的完美体现它没有发明任何新东西只是巧妙地组合了ping、rc.subr和rcorder这几个早已存在的、最基础的积木就搭建出了一座跨越启动鸿沟的桥梁。这大概就是Open Source和Systems Administration这两个词在 FreeBSD 世界里最真实的重量。
