本文向您描述了如何在不影响可用性的前提下加快 Linux 操作系统的引导速度。当然,这种方法要求您对系统服务及服务之间的依赖关系有所理解,如果它们可以并行启动,就让它们并行启动而不是串行启动。
毫无疑问 Linux 是一个优秀的系统,但仍然无法摆脱一个常见的责难(尤其是来自具有 Microsoft Windows 背景的人),那就是 Linux 系统从按下“on”键开始到可以使用,需要的时间太长。其实他们说的没错,Linux 确实需要比较长的引导时间。
在这里我所描述的加快 Linux 引导速度的技术虽然理解起来很简单,但真正实现却需要谨慎行事。我希望 Linux 的发行商能采用这种方法,这样用户就可以省去那些配置任务。不过如果您喜欢冒险,请继续阅读本文。
我强烈建议您在考虑用我所建议的方法修改一个正式的系统之前,先去修改一个无关紧要的测试系统。如果您只有一台机器,那么您可以使用 UML (User Mode Linux) 这一非常有用的工具。UML是一个内核补丁,它可以将Linux内核编译成为一个二进制文件,然后您可以像运行一个普通的程序一样去运行这个内核。也就是说,您可以在您的正常的系统之上以一个进程的方式来运行一个完整的 Linux 系统。您可以将其想象为在一个正常的系统 中运行一个 Linux 系统。(请参阅本文末尾的 参考资料,可以找到可以下载UML的站点以及 developerWorks网站上关于UML的教程)。
使用UML您可以工作于一个测试系统,哪怕把这个测试系统完全破坏掉,也不会影响您正常的系统。
概述
本文的第一部分介绍当 Linux 内核(Linux 机器的的“核心”)加载后,一个 Linux 系统怎样在后台启动。然后介绍加快您的系统引导速度的技术。
如果您对运行级和服务启动脚本已经熟悉,您可能希望直接跳转到 传统服务框架的局限。
一个 Linux 系统的引导过程可以分为几个阶段。本文并不会解释所有的不同阶段,因为我们所关心只是当内核加载后的那一个阶段。
您可以运行 /sbin/runlevel 命令来确定您的系统当前的运行级。(更多详细信息请查阅 man runlevel)。
当内核被加载并开始运行时会调用 /sbin/init 程序。这个程序以 root 身份运行,并且在开始引导时按照要求设定为“运行级”。(更多关于 init 程序的详细信息,请参考 man init)
一个 运行级仅仅是一个数字,Linux根据这个数字来区分不同类型的高层次配置,系统将按照不同的高层次配置来进行引导。由于绝大部分运行级数字都定义了明确的含义,因而它们基本上是“众所周知”的。Red Hat Linux 系统的主要运行级见表1。
表 1. Red Hat Linux运行级
运行级 | 说明 |
0 | 关闭 |
1 | 单一用户模式(一般仅用于管理目的) |
2 | 多用户模式,不允许使用网络 |
3 | 多用户模式,允许使用网络 |
4 | 没有用到的运行级 |
5 | 多用户模式,允许使用网络,X-Windows 方式(图形登录界面) |
6 | 重新引导 |
|
系统服务
rc 脚本负责启动用户需要的所有服务。就像名字所描述的一样,所谓服务就是系统提供的有用的工具。可能会有很多服务需要启动。大部分的 Linux 系统会启动 sshd(安全Shell服务)、syslog(系统日志工具)和 lpd(打印服务),但还会有更多的服务需要启动。比如,我的 Red Hat 9 系统现在运行着29个服务,但如果我把所有的服务都启动,那么我的系统中将会有近50服务在运行。
|
通常在 /etc/rc.d/init.d/ 目录下可以找到服务程序。
如果你浏览一下这个目录,你就会发现相当多的(如果不是全部都是的话)服务程序实际上都是 shell 脚本,用于调用其他程序完成实际的工作。
rc 脚本如何知道在每个运行级下去运行哪些脚本?
回顾一下,如果我们不希望在某个运行级下运行某个脚本,我们如何告诉系统这样去做?答案是在 /etc/rc.d/ 目录下,在这个目录下,除了我们已经讨论过的 init.d/ 目录以外,还有一组目录,每一个目录对应一个运行级。这些目录以 rc<runlevel>.d 的形式来命名,比如,对应运行级5的目录为 /etc/rc.d/rc5.d/ 。在这些rc.d目录中,每一个目录下都有一组符号链接,指向 /etc/rc.d/init.d 中的真正的服务程序。实际上,后边我们会发现,每个服务事实上有两个符号链接。
服务链接名
这些指向实际服务程序的符号链接的名字很重要,它们遵循严格的命名约定,这样 rc 脚本就知道如何处理它们。
为了便于标识,每个链接的名字都以它们所指向的服务的名字做为后缀。
前缀由两部分构成:一个大写字母,紧跟着是一个两位的十进制数。前缀中的大写字母是“S”(表示“启动”),或者“K”(表示“杀死”,或者停止)。两位数的大小范围是自00到99。
|
启动和停止服务
如果我们决定让 Linux 机器引导到图形模式(运行级5),当 init 调用 rc 脚本并传递给它运行级数字时,rc 脚本将到 /etc/rc.d/rc5.d/ 中查找,并且去运行它所能找到的所有符号链接(也就是说,它将运行每个链接指向的程序/脚本)。它将在两个截然不同的阶段来运行这些链接;首先它会执行所有以“K”开头的链接,同时传递给它们参数“stop”。执行完以后,所有这些链接指向的服务都被停止。
rc 把参数“tart”或者“stop”传递给每一个服务程序,这样做是为了只用一个服务程序可以启动或停止那个服务——服务程序根据传递给它的参数值分辨系统是正在引导还是正在关闭。
清单 1. 运行级5的指向服务程序的链接
|
这看起来好象是非常复杂的系统,但实际上它提供了极好的灵活性,因为如果您想临时禁止某个特定运行级中的服务,只要把适当的符号链接删除即可。不过,手工管理这些链接可能会让人感觉厌烦,并且容易出错(尤其当您累了的时候),所以可以采用一个相对好一些的方法,使用 chkconfig 命令。
|
如何找出激活的服务
想查看您已经激活了多少服务,运行这个命令:
chkconfig 命令还可以用来切换任何一个服务的开或关。详细信息请参考手册页(man chkconfig)。
清单 2. chkconfig --list|sort的输出
|
清单 2中第一列是服务的名字,接下来的列是运行级和每一个运行级中服务的状态。例如,ntpd (Network time daemon)服务被配置为只在运行级3中(多用户,无图形)和运行级5(多用户,有图形)中启动,sshd 服务在运行级2,3,4和5中都被切换到开的状态。
注意在运行级0和6中没有一个服务要启动。回顾表 1,原因显而易见。运行级1表示要关闭或停止系统,因此在机器将要“关闭”时,您不会想要 启动任何服务。运行级6中也是如此。
运行级1——“单一用户模式”——是一个特别的运行级,一般在系统出问题的时候使用。一直以来,在运行级1中运行的唯一一个应用程序是 shell,允许超级用户来修复系统或者让超级用户在一个安全的环境中修改系统。这样是安全的——就像它的名字“单一用户模式”的含意一样——只有超级用户可以访问系统。并且,联网是禁用的,所以没有人可以远程登录。如表 1所示,单一用户模式中运行的唯一一个服务是keytable,这样使得超级用户的键盘可以正常使用。
激活服务与运行服务的对比
有时服务会由于某种原因无法启动,用下面这个命令查看当前有哪些服务正在运行:
关键的是,只有当配置中的所有服务都启动以后,您才可以登录进入您的 Linux 系统。等待50个服务启动可能会需要若干分钟,而这本来应该是您享用Linux系统的时间。
我已经找到了一个加速这个过程的方法。注意这种方法不会停止任何服务。不管怎样,停掉那些不用的服务是很明智的,不仅是因为这样可以加快引导的速度(在机器可以登录之前需要运行的服务少了),而且,由于很多服务要以 root 用户身份来运行,停掉不用的服务会减少您的安全隐患。
扼要重述一下,当一个 Linux 系统引导时,它以一种连续的方式来运行所有的某个运行级所配置的所有服务—— 一个接一个地。这是一个耗时的操作。
或许一个很明显的加快服务启动速度的方法是并行地启动所有的服务,这样它们就可以同时启动。不幸的是,虽然这听起来很吸引人,却不可行。原因是各个服务之间存在依赖的关系。Linux没有把这些依赖关系完全显式地表示出来,但是事实上这些依赖关系是存在的。还记得我们先前讨论的关于链接名字格式的问题吗?在 “S”和“K”之后的两位数决定了链接(也就是它们指向的服务)的运行顺序。这些数字确定了一个硬性的顺序,这样一定程度上也强化了服务之间的依赖关系。
回顾 清单 1,我们可以看到 network 服务(S10network)将在ntpd服务(S58ntpd)之前运行。这是我们所期望的,因为 ntpd 服务要求网络可达,以使它可以连接一个本地时间服务器。不幸的是,这个硬性的顺序并不能告诉我们足够的信息,并且会让人误解。例如,在 清单 1中我们可以看到 lpd 服务(S60lpd)将在 network 服务之后运行。虽然这样对那些连接到网络并且使用网络打印机的 Linux 系统来说是正确的,但是这并不说明当背板上有一个 inkjet 打印机连接到本地系统时,lpd 服务还是必须要在 network 服务之后运行。实际上,在这种情况下,在启动 network 之前先启动 lpd 会更好一些。
再来看另外一个例子:crond (cron daemon)服务 (在 清单 1中的 S90crond)也是在 network 启动之后运行。可是,如果您没有使用远程机器文件的 cron 文件,那么就应该让 crond 在 network 之前启动。
由于我刚才介绍的 Linux 下启动服务的传统方法有一定的局限性,往往倾向于“安全第一",让所有的重要的服务先启动,然后再启动余下的那些。
所以,尽管我们不能并行地启动 所有的服务,但我们可以并行地启动那些 相互间没有依赖关系的服务。当这些相互间无依赖的服务启动以后,我们可以启动那些所有依赖条件已经满足(也就是说,那些服务所依赖的服务已经启动)的服务。然后重复这一过程,直到所有服务全部启动。
这个看起来是一个复杂的问题,不过幸运的是,已经有一个现成的可以用来解决这个问题的程序。这个程序不是别的,正是 make。
通常当编译软件时,make 会提供我们所需要的严密的框架。所有我们要做的就是告诉 make 什么是服务之间的依赖;它可以去做所有的计算交叉依赖的艰难工作,并且,使用它的鲜为人知的标记 -j ,它可以作为许多"作业"而 同步运行。
|
现在,我们来做一个简单的实例。我们都知道,ntpd 服务需要网络,这说明 ntpd 服务依赖于network 服务。在 make 语法中这个依赖关系这样表示:
|
这看起来没什么,但是您知道这意味着什么吗?这意味着一旦 network 服务启动完成,我们可以 并行地启动 ntpd,netfs 和 autofs 服务。
为什么会这样?好了请看,network 服务启动需要10秒时间,但是(因为当 rc 脚本在运行时,机器处于完全多任务的状态)其余三个服务可以 同时启动,所以这三个服务 合起来的启动时间是10秒。
事实上,大部分服务需要的启动时间可能不是10秒,但是既然每一个服务要做一些完全不同的事情,启动它们所需要的时间会很可观。
样例实现
我在 参考资料部分提供的压缩文件中有一个使用上述技术的样例实现。包括一个修改过的用于调用 make 命令的 rc 脚本,以及样例GNU makefile文件,分别是 runlevel.mk,start5.mk和stop5.mk。makefile 文件 runlevel.mk 是控制程序,start5.mk 文件和stop5.mk 文件分别是运行级5时启动和停止服务时的服务依赖描述文件。
注意所给出的启动和停止 makefile 文件提供的不是完全的服务间依赖关系列表,而仅仅是一个例子。同时也要注意,如果您不修改这些文件就在您的系统上使用,几乎不可能成功,因为您的服务列表可能和我的并不一样。
- 一些服务程序仅仅是在后台运行一个程序,它们自己就退出了(也就是说,服务程序结束了,但是真实的工作仍然在后台进行)。这说明了一个事实,那就是传统的系统是不完善的,这种服务程序编写者试图在现有框架的界限内减少一些时钟周期。采用本文描述的这种方法将会使依赖关系更加显式化,不需要服务编写者再去“欺骗”。这种方法考虑到在这些服务程序之外建立一个更为高效的框架。
- 当您希望“交互式”引导您的系统时,这里所提到的技术不再适用,因为您通常是当系统某些地方出错的时候才会这样去做;在这种情况下,您可能希望串行地去启动所有的服务以找出出错的原因。不过,修改系统的启动过程,来让用户在系统引导来选择是以串行的方式(允许交互的服务启动)或者“并行”的服务启动方式,是容易实现的。
- 采用这种方法可能还需要更深入的考虑,因为如果传统的系统和新的系统都提供给用户,将需要同步维持两组关于服务如何启动的信息(有序的 rc.d/ 链接文件和运行级 make 文件)。一个更好一些的解决方案是 Linux 发行版本能从 makefile 文件自动生成链接文件,因为 makefile 文件比链接文件记录了更多的关于服务的信息。
- 这个系统可能对一个专用的服务器来说并不适合,因为当一个服务发生错误时,管理员希望能在错误发生时在控制台中马上可以看到这个错误。不过,对于普通的终端用户来说,并行化的方法可以在允许用户查看是否有问题发生的前提下显著地加快引导速度。
- 有趣的是,尽管我提出的这种方法从传统观点来看不是“类似Linux的”,但 Linux 基础标准 (LSB,Linux Standards Base)看起来并没有要指定 init.d 脚本的运行顺序,所以这种方法有可能被 Linux 发行商所采用,而且使之仍然符合 LSB。这对用户来说是一个好消息,如前面所提到的,因为发行商可以为我们计算出所有的软件包之间的依赖关系。
- 有一种方法可能更为大胆,那就是 /etc/inittab 文件中的“action field”的“wait”修改为“once”。这样用户在服务启动完成之前就可以登录。不过,这已经超出了本文的范围。要得到更详细的信息请查阅 man inittab,并且请记住,UML是您的好帮手。
文章来源于领测软件测试网 https://www.ltesting.net/
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073