RHEL6.0 init（UpStart）
1）SysV init的优缺点
SysV init是最早的解决方案，依靠划分不同的运行级别，启动不同的服务集，服务依靠脚本控制，并且是顺序执行的。
SysV init优点是：原理简单，易于理解；依靠shell脚本控制，编写服务脚本门槛比较低。
SysV init缺点是：服务顺序启动，启动过程比较慢；不能做到根据需要来启动服务，比如通常希望插入U盘的时候，再启动USB控制的服务，这样可以更好的节省系统资源。
2）Upstart的改进
近年来，Linux系统的 init 进程经历了两次重大的演进，传统的 sysvinit 已经逐渐淡出历史舞台，新的 UpStart 和 systemd 各有特点。
SysV init服务启动慢，在以前并不是一个问题，尤其是Linux系统以前主要是在服务器系统上，常年也难得重启一次。有的服务器光硬件检测都需要5分钟以上，相对来说系统启动已经很快了。但是随着移动互联网的到来，SysV init服务启动慢的问题显得越来越突出，许多移动设备都是基于Linux内核，比如安卓。移动设备启动比较频繁，每次启动都要等待服务顺序启动，显然难以接受。
随之UpStart应运而生，UpStart试图实现这两个目标。
1）尽可能的快速启动服务；
2）尽可能的减少系统资源占用；
UpStart 采用事件驱动机制，服务可以暂不启动，当需要的时候才通过事件触发其启动，这符合第一个设计目标；此外，不相干的服务可以并行启动，这也实现了第二个目标。在CentOS6系统中，SysV init和UpStart是并存的，UpStart主要解决了服务的即插即用。服务顺序启动慢的问题，UpStart的解决办法是把相关的服务分组，组内的服务是顺序启动，组之间是并行启动。但UpsStart对CentOS6并不是支持的特别好。下面的图形演示了UpStart相对于SysV Init在并发启动这个方面的改进：
假设有7个不同的启动项目，比如JobA、Job B 等等。在SysVInit 中，每一个启动项目都由一个独立的脚本负责，它们由sysVinit顺序地，串行地调用。因此总的启动时间为 T1+T2+T3+T4+T5+T6+T7。其中一些任务有依赖关系，比如 A,B,C,D。
而 Job E 和 F 却和 A,B,C,D 无关。这种情况下，UpStart 能够并发地运行任务{E，F，(A,B,C,D)}，使得总的启动时间减少为 T1+T2+T3。
这无疑增加了系统启动的并行性，从而提高了系统启动速度。但是在UpStart中，有依赖关系的服务还是必须先后启动。比如任务 A,B,(C,D)因为存在依赖关系，所以在这个局部，还是串行执行。
让我们例举一些例子， Avahi服务需要D-Bus 提供的功能，因此Avahi的启动依赖于D-Bus，UpStart中，Avahi 必须等到D-Bus 启动就绪之后才开始启动。类似的，livirtd和X11都需要HAL服务先启动，而所有这些服务都需要 syslog 服务记录日志，因此它们都必须等待syslog 服务先启动起来。然而httpd和他们都没有关系，因此httpd可以和Avahi等服务并发启动。
3）CentOS6查看init程序
|
1 2 3 4 5 |
[root@www ~]# cat /etc/redhat-release CentOS release 6.5 (Final) [root@www ~]# init --version init (upstart 0.6.5) Copyright (C) 2010 Canonical Ltd. |
所以既然是并存，那么就不可能沿用CentOS5那套init模式了。所以在CentOS6中，从运行/sbin/init程序开始后其它相对的文件都有些变化。
初始化系统运行/sbin/init执行/etc/init/rcS.conf脚本。
/etc/init/rcS.conf首先调用/etc/rc.d/rc.sysinit对系统做初始化
最后会执行/etc/inittab（RHEL6.0中inittab中只有这一行指令）来设定系统运行的默认级别id:3:initdefault: 根据默认级别执行/etc/rc.d/rc*启用需要的服务，之后的跟RHEL5.0没有什么区别了。
