原文

upstart homepage

现行的Linux distros主流的有两种init方式:一种是广为流传的System V initialization,它来源于Unix并且至今仍被各种Linux distros所采用;另一种是近几年提出的Upstart方式,基于事件机制,系统的所有服务,任务都是由事件驱动的。据我所知,采用后一种方式的目前有Ubuntu(6.10 and later),Fedora(9.10 and later),Debian(optional)。虽然采用Upstart的发行版并不多,但它旨在取代旧式的System V initialization。

  作为知识梳理,我现在就先在这里总结一下这两种方式各自的初始化流程,这也是为了方便整理思路:

  之前在查找Linux系统init流程的相关资料时总是能够看到inittab的身影,但是在我的Ubuntu上是没有这个文件的,到后来才知道采用 Upstart方式的Ubuntu上是没有inittab这个文件的。在旧式的System V initialization中,/etc/inittab可是个相当重要的文件。init进程启动后第一时间找的就是它!inittab负责初始化系统,设置系统runlevel及进 入各runlevel对应要执行的命令。假设当前inittab中设置的默认runlevle是5,则init会运行/etc/init.d/rc 5命令,该命令会依据系统服务的依赖关系遍历执行/etc/rc5.d中的脚本/程序。进入/etc/rc5.d目录可以发现里面的文件都是到/etc /init.d/下对应的脚本/程序的软链接。以S开头的为启动的意思,以K开头的为停止。并且S/K后面的两位数数字代表了服务的启动顺序(由服务依赖关系决定)。

  那么Upstart job是怎么样的呢?我们知道,System V initializaiton是以runlevel为核心,依据服务间依赖关系的init方式,但在Upstart job,runlevel虽说对于服务的启动也有影响但已不是关键所在。Upstart job是事件驱动的,系统服务的启动、停止等等均是由事件决定的,反过来,系统服务的启动、停止也可以作为事件源触发其他服务。并且事件并不一定得由系统内部产生,用户可以手工的键入start/stop [Service]产生事件来启动/终止服务。man upstart-evnets查看upstart job所定义的事件,可以发现,runlevel也被当作事件来对待(因runlevel的改变而产生的事件),诸如此类还有其他如 startup,started,filesystem等等。那么系统服务又是如何知道自己应该什么时候启动,什么时候终止的呢?答案就在于/etc /init中(有的distros可能是在/etc/event.d)。进入/etc/init目录下一看,均是系统服务的配置文件,或者说,是job definition files。(实际上Upstart init只需要/etc/init这么一个目录,不像System V init,“拐弯抹脚”转好多圈才到达目的地,在性能上不如前者)。随便打开一个文件,比如cron.conf:

# cron - regular background program processing daemon
#
# cron is a standard UNIX program that runs user-specified programs at # periodic scheduled times description "regular background program processing daemon" start on runlevel [2345]
stop on runlevel [!2345] expect fork respawn exec cron

  相信敏锐的程序猿们都发现了:start on runlevel [2345];stop on runlevel [!2345]

  没错,配置文件就是通过这个来设置服务何时启动,何时终止的。

  实际上并不仅仅在系统启动初期,在系统运转的任何时期都可以通过发送事件来启动或终止服务。这便是Upstart job的优点之一,除了用于系统初始化,还可以在系统运行阶段发挥作用。相比之下System V initialization方式下的配置文件一般只用于系统初始化阶段,当然系统运行阶段我们可以通过/etc/init.d/Service start/stop/otherCommand来操作服务,但很明显不如Upstart方式简洁明白。

  好,介绍完System V initialization和Upstart,那么现在就能介绍Ubuntu init系统初始化流程。前面提过Ubuntu使用的是Upstart方式的initialization,其实不全然,考虑到6.10之前的版本采用的System V init及某些服务的需要,Ubuntu采用的是兼容模式,即:系统中既有System V-style启动的服务,也有Upstart启动的服务。如果你使用的是Ubuntu11.04(我目前PC上的系统),那么你可以看到系统中有这么几个目录:

/etc/init
/etc/init.d
/etc/rc${runlevel}.d

  作为两种init方式各自特征的/etc/init.d,/etc/rc${runlevel}.d目录和/etc/init目录在Ubuntu中都有了,那么Ubuntu是如何实现兼容的?实际上,Ubuntu中并没有直接采用System V-style启动服务,要知道,Ubuntu中的init已被替换为Upstart init,而System V-style的服务是存放于/etc/rc${runlevel}.d目录中的,(而/etc/rc${runlevle}.d/下的文件是到/etc/init.d的软链接)可Upstart init并不会直接跑到这里面去启动服务。它是通过间接调用来启动这类服务的。换句话说,Ubuntu中的init并不会直接奔着/etc/init.d或者/etc/rc${runlevel}.d/而去,它采用了折衷的办法,通过/etc/init下的某些配置文件调用/etc/rc${runlevel}.d/中的脚本以启动采用旧式System V-style的服务。唉,说的我自己都觉得好绕,还是见实例吧,看下面。

  进入/etc/init目录(Upstart init会到该目录下读取配置文件),会发现几个跟rc有关的配置文件:

rc.conf
rc-sysinit.conf
rcS.conf

  rc-sysinit在startup事件发生时被启动,rc在系统runlevel变化时被启动,rcS在系统runlevel为S时启动。在配置文件的注释中说明了,这几个文件,正是Upstart init处理System V-style服务的关键。

  rc-sysinit在startup事件发生时被启动,即,Upstart init会首先读取rc-sysinit.conf并执行相关配置和脚本。rc-sysinit.conf的主要工作是设置系统默认runlevel,检测是否存在/etc/inittab或内核命令行,若存在,则按内核命令行>/etc/inittab>默认runlevel的顺序设置系统 runlevel。最后,调用telinit进入设置的runlevel。

  由于调用了telinit进入了设定的runlevel,runlevel改变的事件发生,此时rc服务启动(当然其他服务也会)。那么,我们就有必要来看看rc.conf中到底有什么东西。打开rc.conf,注意到最后一行:

exec /etc/init.d/rc $RUNLEVEL

  是不是感觉/etc/init.d/rc很熟悉,没错,在System V initialization中,/etc/inittab中的各runlevel对应的命令行就是通过这种形式设置的。

  很明显,/etc/init.d/rc被调用了,并且传入了早前设置好的系统runlevel作为参数。而/etc/init.d/rc会根据传入 的runlevel参数调用/etc/rc${runlevel}.d/下的脚本(以S开头)以启动服务,终止在前次runlevel启动而当前在 runlevel需要终止的服务。至此,Ubuntu处理System V-style服务的流程是不是渐渐明朗了。通过rc-sysinit和rc间接的调用/etc/init.d/rc从而启动System V-style服务,Ubuntu在采用新式Upstart init照顾了旧式的System V init。

  采用Upstart方式启动的服务则在/etc/init/目录中有属于自己的一份配置文件,终端下键入:initctl list,看看列出的服务是否同/etc/init/下的服务完全一致!

  Over!!!

  另:上面的内容很多是我个人的理解,大方向应该没错,但细节处的理解就不敢保证拉。看官发现了别忘了给出建议哟!

  btw,rc这东西代表的是Run Commands不?看了wiki好似是这样子的:It is used for any file that contains startup information for a command。曾经有段时间分不清是Run Commands还是Runtime Configuration~_~!

  祝大家圣诞快乐!新年快乐!

(转)Ubuntu init启动流程分析的更多相关文章

  1. ubuntu为什么没有/etc/inittab文件? 深究ubuntu的启动流程分析

    Linux 内核启动 init ,init进程ID是1,是所有进程的父进程,所有进程由它控制. Ubuntu 的启动由upstart控制,自9.10后不再使用/etc/event.d目录的配置文件,改 ...

  2. ubuntu upstart启动流程分析

    ubuntu自从6.10版本之后就使用了较新的upstart机制来进行系统的初始化. upstart是一种基于事件驱动的服务启动机制,可以使多个系统任务在保持依赖关系的前提下并发启动(据说这样这样启动 ...

  3. ubuntu init启动流程

    ubuntu的init方式有两种:一种是System V initialization,一种是Upstart.ubuntu6.10以前的版本是第一种方式,之后的版本是第二种方式. 在旧式的System ...

  4. u-boot启动流程分析(2)_板级(board)部分

    转自:http://www.wowotech.net/u-boot/boot_flow_2.html 目录: 1. 前言 2. Generic Board 3. _main 4. global dat ...

  5. u-boot启动流程分析(1)_平台相关部分

    转自:http://www.wowotech.net/u-boot/boot_flow_1.html 1. 前言 本文将结合u-boot的“board—>machine—>arch—> ...

  6. Cocos2d-x3.3RC0的Android编译Activity启动流程分析

    本文将从引擎源代码Jni分析Cocos2d-x3.3RC0的Android Activity的启动流程,以下是具体分析. 1.引擎源代码Jni.部分Java层和C++层代码分析 watermark/2 ...

  7. Netty 拆包粘包和服务启动流程分析

    Netty 拆包粘包和服务启动流程分析 通过本章学习,笔者希望你能掌握EventLoopGroup的工作流程,ServerBootstrap的启动流程,ChannelPipeline是如何操作管理Ch ...

  8. 【转】Netty 拆包粘包和服务启动流程分析

    原文:https://www.cnblogs.com/itdragon/archive/2018/01/29/8365694.html Netty 拆包粘包和服务启动流程分析 通过本章学习,笔者希望你 ...

  9. SpringBoot启动流程分析(六):IoC容器依赖注入

    SpringBoot系列文章简介 SpringBoot源码阅读辅助篇: Spring IoC容器与应用上下文的设计与实现 SpringBoot启动流程源码分析: SpringBoot启动流程分析(一) ...

随机推荐

  1. CO配置步骤清单 - 2004

    SAP配置步骤清单 SAP版本:2004 模块:CO(CCA/CEA/PCA) Note:大洋电机的SAP版本和此文档版本不同,少数配置路径有所变化,请参考使用. No. 配置对象 事务代码 配置内容 ...

  2. LinkedHashMap

    LinkedHashMap既是一个HashMap,也是一个链表 package java.util; import java.util.function.Consumer; import java.u ...

  3. Python之SGDRegressor

    实现: # -*- coding: UTF-8 -*- import numpy as npfrom sklearn.linear_model import SGDRegressor __author ...

  4. [20171115]ZEROCONF ROUTE.txt

    [20171115]ZEROCONF ROUTE.txt --//如果你检查linux服务器的网络配置,就可以发现如下一条路由: #  route -n | egrep "169.254|D ...

  5. 洗礼灵魂,修炼python(53)--爬虫篇—urllib模块

    urllib 1.简介: urllib 模块是python的最基础的爬虫模块,其核心功能就是模仿web浏览器等客户端,去请求相应的资源,并返回一个类文件对象.urllib 支持各种 web 协议,例如 ...

  6. 洗礼灵魂,修炼python(26)--编程核心之“递归”

    递归 1.什么是递归: 其实前面都提过,但没有详细讲.多次调用自身就叫递归 看图,这种就叫递归 看过盗梦空间没?其实也是递归 2.递归需要满足条件: 有调用函数自身 有一个正确的返回条件来结束 在使用 ...

  7. iOS 多线程之GCD的简单使用

    在iOS开发中,遇到耗时操作,我们经常用到多线程技术.Grand Central Dispatch (GCD)是Apple开发的一个多核编程的解决方法,只需定义想要执行的任务,然后添加到适当的调度队列 ...

  8. python socket 套接字编程 单进程服务器 实现多客户端访问

    服务器: import socket #单进程服务器 实现多客户端访问 IO复用 #吧所有的客户端套接字 放在一个列表里面,一次又一次的便利过滤 server = socket.socket(sock ...

  9. sqlserver 拆分

    有表tb, 如下:id value----------- -----------1 aa,bb2 aaa,bbb,ccc欲按id,分拆value列, 分拆后结果如下:id value--------- ...

  10. python之列表的常用操作

    Python list 常用方法总结   一,创建列表  只要把逗号分隔的不同的数据项使用方括号([ ])括起来即可 下标(角标,索引)从0开始,最后一个元素的下标可以写-1 list  =  ['1 ...