执行rc.sysinit的流程非常复杂(若有兴趣，可以直接打开/etc/rc.d/rc.sysinit文件研究一下)，里面包含非常多额外的script file，从主机名称一直到文件系统信息都有关联，笔者将Fedora Core 6中rc.sysinit会执行到的重要文件，依执行的先后顺序整理成表5-1（表5-1.doc）。

　　以上就是Linux在开机时的第一个script文件，内容不只是如此，笔者已经去掉没有太大关系或默认不会执行的部分，整个Linux通过init找到inittab后，就直接将rc.sysinit从头执行到最后，再来就换rc.sysinit之后的步骤了。

　　在这些步骤中所要注意的，最好是可以在每一段开机时的信息中找到对应的步骤，或许您会好奇为何要知道这些信息的由来?相信只要使用Linux一段时间的用户都会知道，当Linux产生非服务(service)导致的系统问题时，最有可能找到问题症结的办法就是观察开机信息(或dmesg)，但往往不知道该段信息所描述的问题点在哪里，这也是为何笔者希望通过本书将这些流程完整地呈现在所有Linux玩家的面前，这样不论问题是发生在哪一阶段，都可以非常轻松且快速地找到真正问题之所在。

　　5.3 /etc/rc.d/rcX.d

　　在inittab中，继rc.sysinit之后所要执行的，就是rcX.d的目录，X是当初开机设置的initdefault值，若将initdefault 设置为3，则会转而执行/etc/rc.d/rc3.d/下的所有文件，本节将以rc3.d为例进行说明。

　　首先看一下rc3.d中的文件有多少(如图5-6所示)。在目录中最简单的区分方式就是看文件名，文件名都是由两个英文字母开头的，不是K就是S。K代表的是Kill，而S代表的是Start。意思很简单，默认为开机要执行的服务，其文件名的开头就是S，若用户将某个服务关闭(不论是用哪一种工具程序)，该文件名就会由S开头变为K开头。反之亦然，若将某服务关闭，则文件名便会是K开头。
　

　　设置服务激活状态的另一个做法是将文件名的第一个字母直接由S变为K(如图5-7所示)，或是将K变为S，这样开机默认激活状态就会从开启变为关闭，或是由关闭变为激活，是非常方便的一种做法。

　　紧跟着英文字母后面的是一个两位数的数字，这个数字代表了执行的先后顺序，但请不要随意地更改数字，因为某些服务是有相关性的，若不小心将数字改掉，有可能会让某些服务无法正常被激活。
    

当然这目录中的文件多寡和当初安装操作系统时所选择的项目有关，绝大部分都是服务程序，眼尖的读者应该也发现这些文件的颜色都是属于link文件的颜色。没错，在rcX.d目录中其实都是link，以link方式的做法弹性比较大，其中绝大部分的文件都是连接到/etc/rc.d/init.d/下的实体执行程序，唯独一个例外，就是S99local 这个文件。

　　从文件名就可以知道S99local 是最后一个执行的程序，因此，才会将数字部分以99来命名，等所有服务执行完之后才会轮到它。该文件连接到的是/etc/rc.d/rc.local，若把该文件打开会发现什么都没有，里面只有一行指到/var/lock/subsys下(其中存放的是代表正在执行的daemon 文件，都是空文件，只是为了记录是否有哪一个服务被无预警地突然中止)。

    rc.local最主要的目的其实就是帮助用户建立自行准备的script file或是个性化的设置，当然这里所指的个性化设置是以一个系统为单位，或是指root的设置，若要设置其他user，则必须从user目录下的文件来着手。

　　但这个文件并不是每一个Linux Distribution都有的，像SuSE就不被叫做rc.local，而是使用在/etc/rc.d/下的boot.local文件来设置。因此，每一套操作系统都应该会有自定的个性化设置文件，只是必须要用户自己找出来，在不靠任何使用手册或口耳相传的方式下，最好的方法就是从开机的script 文件中慢慢过滤出来，顺便也可以培养对Linux 的熟悉程度。

　　再来要看的是/etc/rc.d/rc3.d/目录中有哪些文件是和系统开机有关系的，server所用的服务或较偏功能面的程序在此会先被省略掉，因为这些文件和开机是比较没有直接关系的，比较重要的部分会在第二篇“管理系统”中说明，现在就把将提到的开机默认激活的相关服务依执行的先后顺序说明如下。

　　◆readahead_early

　　readahead是一个聪明的机制，大家都知道目前计算机的执行速度大部分都是被实体硬盘的访问速度所拖慢的，因此，为了加速操作系统的使用速度，readahead_early 这个daemon 在系统加载时，干脆直接将日常所需要的一些文件，全部都先载入到硬盘的高速缓存(cache)中，让文件直接通过cache访问。若要查看硬盘中可支持操作系统的cache大小，可用hdparm这个程序来检查(如图5-9所示)。

    虽然图5-9中显示的大小是256，但要切记这是指有多少个sector，也就是说，一般sector的大小是512 Byte，而硬盘提供给操作系统使用的cache大小就是“512 Byte* 256=128K”。至于规定要把哪些文件在开机时加载到硬盘cache中，就要参考在/etc/readahead.d/目录中的custom.early(默认只会有default.early范例文件)。

   ◆kudzu

　　kudzu是最容易遇到的程序，只要有新的硬件加入到主板，kudzu就会帮用户检测出来，以安装最适用的module，有点像是plug and play的概念，只是在Linux下没办法像Windows那样方便且支持得那么广泛。

　　kudzu在开机时会依据/etc/sysconfig/hwconf已列出的硬件，以决定检测到的硬件为新加入或是已存在的。若是新加入的，会再参考/etc/sysconfig/kudz中所定义的规则以决定是否要忽略，最后确定要加进新的硬件后，就会加载适当的module，并将其记录在/etc/modprobe.conf文件中(这个文件应该是最容易使用到的)，这样当往后开机时，系统便会自动加载列在modprobe.conf中的设备。

    旧的Linux版本并不会以modprobe.conf为文件名，而是将其称为modules.conf。这倒是Linux的缺点，光是Red Hat一个系统厂商就已经无法在每个版本保持文件名的一致性，而且Linux kenrel 版本更新的速度太快，对不是很熟悉的用户而言，还真的是有点麻烦的;但相反地，Linux 也就是因为这样才越来越稳定、安全、强大。

　　◆network

　　不用多说，大家应该都知道这就是将网卡激活的程序，但要记得在/etc/sysconfig/network-scripts/目录下一定要有ifcfg-ethX的文件存在，否则是无法正常运行的。既然在此谈到有关network的设置，就一并解释一下ifconfig与ifup这两个指令的差别(很多人以为是一样的)。

　　ifconfig是一个设置IP等相关信息的程序，可将网卡激活、设置IP、设置MTU大小等，只要实体的网卡存在就可以。但ifup则不同，这个指令一定要有/etc/sysconfig/networkscripts/ifcfg-ethX 设置文件的存在才能使用，如果没有，就会出现错误信息。所以在用法上，其实是有着一段差距的，另外ifconfig的设置也要注意，设置完成后并不会存入网卡的设置文件中。

　　既然有ifup，当然就会有ifdown，用法都一样，使用ifdown就是把该网卡停用，和网络设置相关的程序多不胜数，我们将在第二篇“管理系统”中提到网卡相关的管理技巧。

    ◆restorecond

　　这个程序的目的是要还原某些文件的SELinux权限，需要还原的清单列在/etc/selinux/ 目录中的restorecond.conf文件里。在2.6 kernel中，SELinux是一个新加入的机制，但它非常重要，因为SELinux所控管的是每一个文件的执行权限，与之前的PAM、Kerberos、TCP Wrapper各机制相比各有所长，在相互配合管控之下，这几种机制将Linux的安全性大幅提高。

    Fedora从Core 2版本开始引进SELinux的机制，这对有些用户来说将造成困扰，因为在SELinux激活的条件下，某些服务会存在执行上的问题，像SAMBA。因为该服务分享出来的文件或目录，有可能是被SELinux默认值所限制住的，导致无法正常分享，因此，笔者在测试时期会将大部分SELinux都关闭。

　　◆syslog

　　这个服务程序太重要了，大部分的系统维护都会用到它，也就是网络或系统管理员经常用到的log 文件。daemon在执行时其实是执行两个程序：syslogd和klogd，介绍如下，其分别负责不同种类的log，但全部的信息在系统刚开完机之后，会全部存放在/var/log/message。

　　? klogd

　　先介绍klogd是因为当一开始写入/var/log/message时，klogd所记录的信息会比syslogd 的顺序优先，原因是klogd所记录的是尚未进入操作系统的信息，但其实一开始的这些信息并不是由klogd所记录的，而是自加载kernel 时，就已经开始记录的。在系统尚未进入操作系统阶段，还在加载kernel及执行initrd时，会将信息先记录在/proc/kmsg文件中(因为在initrd阶段没有实体硬盘可供记录)，等进入操作系统执行完klogd后，klogd再将/proc/kmsg的所有内容全数填入/var/log/message文件中，这也是为何在/var/log/message文件的一开始，依然可以看到刚开机在加载kernel以及initrd阶段的信息(如图5-13中连CPU的启用都看得到，信息中也注明了是kernel的信息)。

    常用到的dmesg指令其实也就是将klogd检测出来的kernel信息，它直接通过console呈现在用户面前。在进入操作系统之后，kernel当然还在运行，而此时的kernel若检测到内部错误发生，klogd则会通过/boot/System.map文件找到kernel所在，如此一来，kernel就可以直接通过klogd的管道将信息再度呈现在用户面前。
  

    ? syslogd

　　在klogd填入所有kernel加载及initrd阶段的信息之后，接着执行的就是这一节所提到的服务级程序，而这些程序所产生的信息，就由syslogd负责整理，所以，这些信息会直接加在刚刚klogd的信息后面。在进入操作系统后就没有依照klogd或syslogd的顺序，只要产生信息，就直接依/etc/syslog.conf文件的定义，写入/var/log/message信息文件。

　　图5-14 的方框就是在kernel信息结束后其中一个xinetd服务激活的信息，从图中的第一行可以看出kernel信息结束后，紧跟着就是服务软件的信息。

    从/etc/syslog.conf文件可以找出所有目前系统通过syslogd所记录的信息，有时候在找某软件的信息时，也可以从这个文件中看出要以哪一个信息文件为主，当然前提是该软件必须支持syslogd的信息记录格式。

　　◆irqbalance

　　在硬件信息都已经齐全后，irqbalance程序的主要目的就是平均分散所有CPU或实体core 之间的interrupts，以往计算机只有一颗CPU，所以都是由某一特定的CPU来负责，但现在的CPU越来越多核心(core)，管理方式也越趋复杂化，加入Linux提供的这一个daemon，就是希望可以在多核心的条件下，将IRQ的性能再加强，让每个设备能多省一些电源，以达到更经济实用的目的。目前已有很多软件朝此方向努力，如第9章将介绍的XEN技术，或是Intel及AMD推广的省电技术，其实也是为此而诞生的。

　　往后CPU的走向将朝多核心的方式进行，核心越多，应该要越来越快才对，但在不同核心之间会衍生出许多性能的问题，irqbalance就可以解决其中之一。另外值得一提的是NUMA的机制(kernel内置的一种机制)，和irqbalance某些部分有点相似，但NUMA是为了让各CPU之间分配内存的性能可以再提升，和irqbalance有异曲同工之妙，两者存在的目的都是为了应付在不同CPU间的处理性能问题。

　　为何会有CPU之间分配内存的性能问题?这就要看一下Intel与AMD目前的架构，在图5-15中虚线以上是差异最大的部分，可以看到Intel 仍是由单一北桥负责各CPU与内存的管理，但AMD已经将北桥崁进CPU里面，内存的管理也就全数交给CPU，造成两种完全不同的硬件架构。

　　从图5-15中可以看出，在用户通过CPU访问内存时是很有机会重叠到的(Intel 架构为共享，因此一定会重叠;而AMD 则是当CPU1 要访问到CPU2 的内存之类的情形)，若重叠情况发生而处理方式不当时，可想见其速度会降低。在两者架构完全不同的情况下，自然管理方式会造成使用的性能差异更大，而NUMA机制就是为了解决CPU与内存之间的平衡问题，但目前一般PC的BIOS大部分却都没有支持NUMA的功能。

    回到irqbalance，这个服务可以平衡多核心(或多个)CPU时的IRQ协调工作，在多个CPU时也会因为不只一个CPU，导致系统当发IRQ中断信号时，怕偏重到某一个CPU，这样会让特定的CPU 性能降低，因此，虽然买到多核心的CPU，但相信在性能上，目前的硬件与系统的配合还没做到最佳时，还是无法形成最佳的管理方式，这还有待各厂商的改进。

◆crond

　　相信各位对crond都不陌生，它有点像是Windows的schedule软件，可以让用户定义年、月、日、时、分、秒，以解决周期性运行软件的问题，设置方式简单明了，也有很多软件默认使用crond来执行。crond默认会执行的文件可以参考/etc/crontab文件中所列的清单(如图5-16所示)，从图5-16中可以看到其实周期性执行的是在/etc目录下的cron.hourly、cron.daily、cron.weekly，以及cron.monthly 目录中的所有文件，设置方式也很简单，只要依照分、时、日、月、周的顺序设置就可以排出用户想要的任务计划。

    ◆xfs

　　xfs其实只适用在进入runlevel 5，也就是图形接口的情况下。这是一个较少人会用到但又不可缺少的daemon，为何会这样说?因为在使用上很少会感觉到xfs的存在，默认也都是激活的，如果在runlevel 3的阶段，停用是不会有任何影响的。但如果停用后要再进入XWindow，将会发现无法进入，原因是xfs所负责的就是X-Window 的所有字型管理。xfs的全名是X-Window Font Service，在未激活的状态下，X-Window会因为无字型可用而导致激活失败(如图5-17所示)，若用户曾看到过一个错误信息是有关IPAddress:7100的问题，大多是因为xfs被关掉所导致的，解决办法其实只要把xfs激活就可以了。

    但这个老问题其实在Fedora Core 7中已经不存在了，因为在Fedora Core 7的/etc/X11/xorg.conf文件已经不再使用xfs的设置，就算将xfs直接关掉再激活X Window，也不会停在上述的错误信息。

　　◆anacron

　　这个软件和crond其实有点相辅相成，crond负责任务计划，而anacron 则是负责以“间隔多久”为主要的诉求，刚好可以补足crond所做的周期性安排。其间隔的判断方式是以存放在/var/spool/anacron/目录中的时间戳记(timestamp)为主要的依据，来决定是否要开始执行。

　　anacron与crond最大的差别在于，若以crond为主要的任务计划方式，会有一个小问题，如果我们先假设用户以crond设置每周六、日凌晨12点到3点要进行更新软件的操作，但刚好却在假日或计划时间内停电，计算机在未开机的状态下度过排程时间，这些更新的操作就会持续延到下星期，这对有些系统管理人员来说将是很大的困扰，尤其像是备份之类的工作，因此，若以anacron补足这方面的缺点，就会比较完整，而crond与anacron是可以并行的。

　　anacron的主要设置文件在/etc/anacrontab，其设置方式和crontab的形式很像，主要是设置两个数字：周期天数和延迟时间(以cron.daily为例，为1天和65 分钟)。当周期天数到了，anacron会判断该程序是否已执行过(1天)，若没有，则会等待一段时间再执行，这段时间就是设置好的延迟时间(65分钟)。

    ◆local

　　这个最后执行的script文件稍早我们曾提到过，也就是在所有daemon执行完毕之后，让用户自定义要执行的程序或设置，在此便不再赘述。