NetBSD rc.d系统的设计与实现概述

需积分: 10 143 浏览量更新于2024-11-03 收藏 108KB PDF 举报

"对BSD rc.d系统的详细介绍，包括其设计、实现和历史背景" BSD系统中的rc.d机制是启动过程管理的重要部分，它在NetBSD 1.5版本中替代了原先从4.4BSD继承的单一/etc/rc启动脚本。这个转变引入了一个更加模块化的方法，每个服务或守护进程都有独立的脚本来管理，并按照特定的顺序在系统启动时执行。 1. 历史背景 rc.d系统的起源可以追溯到各种UNIX启动机制的历史。在NetBSD之前，包括4.4BSD在内的许多系统都使用一个单一的/etc/rc脚本来处理所有的启动任务。这种集中式的方法随着时间的发展显得越来越不灵活，难以维护，尤其是在系统服务日益复杂的情况下。 2. 设计考虑 rc.d的设计过程经历了六年的讨论，主要目标是提高可读性、可维护性和灵活性。每个服务单独的脚本使得调试和更新更容易，同时允许系统管理员根据需要启用或禁用特定的服务，而不影响其他服务的启动流程。 3. 实现细节 rc.d机制由一系列位于/etc/rc.d目录下的脚本组成，这些脚本负责启动、停止和检查服务的状态。它们通过执行顺序（由/etc/rc.order或类似文件定义）来确保正确的启动顺序。此外，rc.d还包括了对环境变量的管理，以及服务依赖性的处理，以确保依赖于其他服务的服务能够正确启动。 4. 人性化问题在设计和实施rc.d的过程中，遇到了一些人性化的问题，比如如何平衡系统的易用性和灵活性，以及如何让系统管理员能快速理解和适应新的启动机制。这需要提供清晰的文档和简单的接口，以便用户可以方便地定制启动配置。 5. 未来发展方向尽管rc.d系统在NetBSD 1.5中已经取得了显著的改进，但它的进化并未停止。未来的方向可能包括进一步优化服务的启动时间，增强服务管理的自动化，以及可能的集成到更现代的初始化系统，如sysvinit或systemd，以保持与现代操作系统发展趋势的一致性。 BSD的rc.d系统是系统启动过程管理的一个重要里程碑，它提高了系统的可管理和可扩展性，为管理员提供了更多的控制权。随着技术的发展，rc.d将继续演进以满足不断变化的需求。

are some services that should be shut down in order

(e.g., database-using applications before their databases)

and some services that require more than SIGHUP for a

clean shutdown.

/etc/rc.wscons was added to control how the wscons

console driver was configured at boot time, and to allow

manual reconfiguration. /etc/wscons.conf controls this

behavior.

2.3.3. Summary prior to NetBSD 1.5

At multiuser boot, init calls /etc/rc to initialize the

system. /etc/rc calls /etc/netstart to setup network ser-

vices, /etc/rc.local for local services, /etc/rc.lkm to ini-

tialize load-able kernel modules, and /etc/rc.wscons to

configure the wscons console driver. The start-up of ser-

vices is controlled by variables in /etc/rc.conf.

At system shutdown time, shutdown calls /etc/rc.shut-

down to shut down specific services which have to be

shut down before the global SIGHUP that init sends.

3. Design considerations

Over a six year period, various ideas on how to enhance

the start-up system were floated on the public NetBSD

mailing lists ‘current-users’ and ‘tech-userlevel’, as well

as on the NetBSD developer-only mailing list.

There was no consensus on ‘OneTrueDesign’; there

was too much contention for that. What is described

below is an amalgamation of what a few developers felt

was a reasonable analysis of the problems and feedback

as well as the most reasonable solution to support the

widest variety of circumstances.

3.1. Problems with the old system

The old system was perceived to suffer from the follow-

ing problems:

• There was no control over the dependency ordering,

except by manually editing /etc/rc (and other

scripts) and moving parts around.

This caused problems at various times, in situations

such as workstations with remotely mounted /usr

partitions, and these problems weren’t completely

resolved as was seen by observing various mailing

discussions and a flurry of CVS commits to the

source tree.

• It was difficult to manually control an individual

service after the system booted (e.g., restart

dhcpd, shut down a database, etc).

Whilst some people suggested that a system admin-

istrator who couldn’t manually restart a service was

incompetent, this doesn’t resolve the issue that typ-

ing “/etc/rc.d/amd restart” is signifi-

cantly easier that finding the process identifier of

amd, killing it, examining /etc/rc for the syntax that

amd is invoked with, searching /etc/rc.conf for any

site-specific options, and manually typing in the

resulting command.

Unfortunately, there was a slight tendency during

some of the mailing list discussions to resort to

attacks on people’s competency in this manner. I

consider this a form of computer based intellectual

snobbery, and an unreasonable justification for why

that person disliked a feature.

• It didn’t easily cater for addition of local or third

party start-up mechanisms, especially addition into

arbitrary points in the boot sequence, including

those installed by (semi-)automated procedures

such as the NetBSD ‘pkg’ tools.

3.2. Requirements of the new system

Given the problems in the old system, and observations

of what other systems have done, including those

described in section 2, the following design consider-

ations were defined.

Some of these considerations were not determined dur-

ing discussion prior to implementation, but were identi-

fied once users were actively using the implementation.

3.2.1. Dependency ordering

Dependency ordering is a strong requirement.

The following dependency ordering requirements were

determined:

• Independence from lexicographical ordering of file-

names.

Some other systems (e.g., System V init.d) use an

existing lexicographical ordering of filenames in a

given directory, such as /etc/rc2.d/S69inet occurring

before /etc/rc2.d/S70uucp, but experience has

shown that this doesn’t necessarily scale cleanly

when adding local or third-party services into the

剩余10页未读，继续阅读

deanetg

粉丝: 0
资源: 12

NetBSD rc.d系统的设计与实现概述

锐起BSD5.0企业无盘安装包

FreeBSD_rc.d脚本程序_中文手册

rc

free bsd 源代码

BSD-Asterisk:在FreeBSD中创建一个星号VoIP服务器

OpenSSL-1_0_0d_Win32

etc目录文件介绍

服务基础之服务简单介绍（systemd）

linux学习笔记.docx

FreeBSD使用大全.第2版

最新资源