Linux在内核态启动完成后,调用用户态的“init”程序开始布置整个用户态的应用环境,init在随后根据配置文件调用文件系统中的初始化脚本。在这里,唯一可以肯定的是任何linux发行版本第一个应用程序都是会去调用init程序,且init程序解析配置文件的方法都是一致的。而关于启动脚本的组织形式和风格,在多个发行版本之间是各不相同、多种多样的。
所以如果需要修改启动脚本以用来加入一些自定义的模块,需要先理解该linux文件系统的脚本架构。
Linux脚本的启动顺序大概如下图所示:
Linux下为什么会要有个init?用过windows 9.x的人应该知道有个批处理文件autoexec.bat,用过windows NT/2000系统的人应该在控制面板中见过system service工具,它们的目的是相同的。只是比较起来windows下的这些东西功能太弱(当然用法也更简单)。
init是Linux启动的最后一步,它帮助用户完成每次启动系统都必须完成的一些重复性任务,如加载文件系统、各类网络服务等等程序;它还有一个重要用途,让用户自定义系统运行环境,只启动需要的进程,关闭不用的进程,释放内存和处理器资源,让系统运行得更快更稳。
常见的init用户程序有两种:一种完整版的init程序sysvinit,sysvinit软件包提供了一系列开关机的命令,常见的有:hutdown、reboot、halt、poweroff、telinit、init。它们都可以达到关机或重启的目的,但是每个命令的工作流程并不一样。
另一种是busybox提供的精简版init :
init会按任务表执行我们下的命令,这个任务表就是/etc/inittab文件。下面查看一个inittab文件的例子:
“/etc/inittab”文件每一行定义一个指令,其基本格式为:id:runlevels:action:command。各字段的详解如下:
id:是任意一个名称(具体是什么并不重要);
runlevels:是一个数字串(代表运行等级);
一条命令可以是一个等级下执行,也可以是多个等级下执行,例如:“1:2345:respawn:/sbin/getty 38400 tty1 “,该命令在等级2345下都会被执行。
根据Linux的定义,Init 可以启动到8个不同的运行级别上:0-6 和 S 或 s。
运行级别可以由超级用户通过 telinit 命令来转换,此命令可以将转换信号传递给 init,告诉它切换到哪个运行级别。
运行级别 0,1,和 6为系统保留的专用运行级别。
运行级别 0 用来关机,运行级别 6 用来重启,运行级别 1 用来使计算机进入单用户模式。
运行级别 S 不是给我们直接使用的,更多是为进入运行级别 1 时运行某些可执行脚本时被调用。下面是几个运行级的简单介绍:
# 0 - 关机(千万不要把initdefault 设置为0 )
# 1 - 单用户模式
# 2 - 多用户,但是没有 NFS
# 3 - 完全多用户模式
# 4 - 没有用到
# 5 - X11
# 6 - 重启(千万不要把initdefault 设置为6 )
action:描述何时执行命令;
action,告诉init执行的动作,即如何处理process字段指定的进程。action字段允许的值及对应的动作分别为:
1)respawn:如果process字段指定的进程没有运行,则启动该进程,init不等待处理结束,而是继续扫描inittab文件中的后续进程,当这样的进程终止时,init会重新启动它,如果这样的进程已经运行,则什么也不做。
2)wait:启动process字段指定的进程,并等到处理结束才去处理inittab中的下一记录项。
3)once:启动process字段指定的进程,不等待处理结束就去处理下一记录项。当这样的进程终止时,也不再重新启动它,在进入新的运行级别时,如果这样的进程仍在运行,init也不重新启动它。
4)boot:只有在系统启动时,init才处理这样的记录项,启动相应进程,并不等待处理结束就去处理下一个记录项。当这样的进程终止时,系统也不重启它。
5)bootwait:系统启动后,当第一次从单用户模式进入多用户模式时处理这样的记录项,init启动这样的进程,并且等待它的处理结束,然后再进行下一个记录项的处理,当这样的进程终止时,系统也不重启它。
6)powerfail:当init接到断电的信号(SIGPWR)时,处理指定的进程。
7)powerwait:当init接到断电的信号(SIGPWR)时,处理指定的进程,并且等到处理结束才去检查其他的记录项。
8)off:如果指定的进程正在运行,init就给它发SIGTERM警告信号,在向它发出信号SIGKILL强制其结束之前等待5秒,如果这样的进程不存在,则忽略这一项。
9)ondemand:功能通respawn,不同的是,与具体的运行级别无关,只用于runlevel字段是a、b、c的那些记录项。
10)sysinit:指定的进程在访问控制台之前执行,这样的记录项仅用于对某些设备的初始化,目的是为了使init在这样的设备上向用户提问有关运行级别的问题,init需要等待进程运行结束后才继续。
11)initdefault:指定一个默认的运行级别,只有当init一开始被调用时才扫描这一项,如果rstate字段指定了多个运行级别,其中最大的数字是默认的运行级别,如果runlevel字段是空的,init认为字段是0123456,于是进入级别6,这样便陷入了一个循环,如果inittab文件中没有包含initdefault的记录项,则在系统启动时请求用户为它指定一个初始运行级别。
command:指定执行的实际命令。该字段中进程可以是任意的守候进程、可执行脚本或程序,后面可以带参数。
Inittab是所有启动脚本的总入口,各种版本linux的启动脚本组织风格虽然不同,从这里都能找到它的入口。
虽然不同linux版本启动脚本的组织风格是不一样,你也可以自定义出一套风格来,但是普遍来说/etc/rc.d/rcN.d是一种最常见的风格。如在/etc/inittab文件中,N运行级别调用/etc/rc.d/rc N的命令:
以运行级别5为例,init将执行配置文件inittab中的以下这行:l5:5:wait:/etc/rc.d/rc 5 这一行表示以5为参数运行/etc/rc.d/rc,/etc/rc.d/rc是一个Shell脚本,它接受5作为参数,去执行/etc/rc.d /rc5.d/目录下的所有的rc启动脚本,/etc/rc.d/rc5.d/目录中的这些启动脚本实际上都是一些链接文件,而不是真正的rc启动脚本,真正的rc启动脚本实际上都是放在/etc/rc.d/init.d/目录下。而这些rc启动脚本有着类似的用法,它们一般能接受start、stop、 restart、status等参数。
/etc/rc.d/rc5.d/中的rc启动脚本通常是K或S开头的链接文件,对于以以S开头的启动脚本,将以start参数来运行。而如果发现存在相应的脚本也存在K打头的链接,而且已经处于运行态了(以/var/lock/subsys/下的文件作为标志),则将首先以stop为参数停止这些已经启动了的守护进程,然后再重新运行。这样做是为了保证是当init改变运行级别时,所有相关的守护进程都将重启。
root@am57xx-evm:~# ls /etc/rc
rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/ rcS.d/
root@am57xx-evm:~# ls /etc/rc3.d/
S01networking S08rc.pvr S10tiipclad-daemon.sh S19nfscommon S20thttpd S30rng-tools S97matrix-gui-2.0 S99rmnologin.sh
S02dbus-1 S10dropbear S12rpcbind S20hwclock.sh S21avahi-daemon S70lighttpd S98thermal-zone-init
S03uim-sysfs S10telnetd S15mountnfs.sh S20syslog S22ofono S95gdbserverproxy S99gplv3-notice
root@am57xx-evm:~# ls -l /etc/rc3.d/
lrwxrwxrwx 1 root root 20 Oct 3 21:07 S01networking -> ../init.d/networking
lrwxrwxrwx 1 root root 16 Oct 3 21:07 S02dbus-1 -> ../init.d/dbus-1
lrwxrwxrwx 1 root root 19 Oct 3 21:07 S03uim-sysfs -> ../init.d/uim-sysfs
lrwxrwxrwx 1 root root 16 Oct 3 21:07 S08rc.pvr -> ../init.d/rc.pvr
lrwxrwxrwx 1 root root 18 Oct 3 21:07 S10dropbear -> ../init.d/dropbear
lrwxrwxrwx 1 root root 17 Oct 3 21:07 S10telnetd -> ../init.d/telnetd
lrwxrwxrwx 1 root root 28 Oct 3 21:07 S10tiipclad-daemon.sh -> ../init.d/tiipclad-daemon.sh
lrwxrwxrwx 1 root root 17 Oct 3 21:07 S12rpcbind -> ../init.d/rpcbind
lrwxrwxrwx 1 root root 21 Oct 3 21:07 S15mountnfs.sh -> ../init.d/mountnfs.sh
lrwxrwxrwx 1 root root 19 Oct 3 21:07 S19nfscommon -> ../init.d/nfscommon
lrwxrwxrwx 1 root root 20 Oct 3 21:07 S20hwclock.sh -> ../init.d/hwclock.sh
lrwxrwxrwx 1 root root 16 Oct 3 21:07 S20syslog -> ../init.d/syslog
lrwxrwxrwx 1 root root 16 Oct 3 21:07 S20thttpd -> ../init.d/thttpd
lrwxrwxrwx 1 root root 22 Oct 3 21:07 S21avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 15 Oct 3 21:07 S22ofono -> ../init.d/ofono
lrwxrwxrwx 1 root root 19 Oct 3 21:07 S30rng-tools -> ../init.d/rng-tools
lrwxrwxrwx 1 root root 18 Oct 3 21:07 S70lighttpd -> ../init.d/lighttpd
lrwxrwxrwx 1 root root 24 Oct 3 21:07 S95gdbserverproxy -> ../init.d/gdbserverproxy
lrwxrwxrwx 1 root root 24 Oct 3 21:07 S97matrix-gui-2.0 -> ../init.d/matrix-gui-2.0
lrwxrwxrwx 1 root root 27 Oct 3 21:07 S98thermal-zone-init -> ../init.d/thermal-zone-init
lrwxrwxrwx 1 root root 22 Oct 3 21:07 S99gplv3-notice -> ../init.d/gplv3-notice
lrwxrwxrwx 1 root root 22 Oct 3 21:07 S99rmnologin.sh -> ../init.d/rmnologin.sh
sysvinit 就是 System V 风格的 init 系统,顾名思义,它源于 System V 系列的 UNIX。最初的 linux 发行版几乎都是采用 sysvinit 作为 init 系统。sysvinit 用术语 runlevel 来定义 “预订的运行模式”。比如 runlevel 3 是命令行模式,runlevel 5 是图形界面模式,runlevel 0 是关机,runlevel 6 是重启。sysvinit 会按照下面的顺序按部就班的初始化系统:
激活 udev 和 selinux
设置定义在 /etc/sysctl.conf 中的内核参数
设置系统时钟
加载 keymaps
启用交换分区
设置主机名(hostname)
根分区检查和 remount
激活 RAID 和 LVM 设备
开启磁盘配额
检查并挂载所有文件系统
清除过期的 locks 和 PID 文件
最后找到指定 runlevel 下的脚本并执行,其实就是启动服务。
除了负责初始化系 统,sysvinit 还要负责关闭系统,主要是在系统关闭是为了保证数据的一致性,需要小心地按照顺序进行任务的结束和清理工作。另外,sysvinit 还提供了很多管理和控制系统的命令,比如 halt、init、mesg、shutdown、reboot 等等。
sysvinit 的优点是概念简单。特别是服务(service)的配置,只需要把启动/停止服务的脚本链接接到合适的目录就可以了。sysvinit 的另一个重要优点是确定的执行顺序,脚本严格按照顺序执行(sysvinit 靠脚本来初始化系统),一个执行完毕再执行下一个,这非常有益于错误排查。
同时,完全顺序执行任务也是 sysvinit 最致命的缺陷。如果 linux 系统只用于服务器系统,那么漫长的启动过程可能并不是什么问题,毕竟我们是不会经常重启服务器的。但是现在 linux 被越来越多的用在了桌面系统中,漫长的启动过程对桌面用户来说是不能接受的。除了启动慢,sysvinit 还有一些其它的缺陷,比如不能很好的处理即插即用的设备,对网络共享磁盘的挂载也存在一定的问题,于是 init 系统开始了它的进化之旅。
systemd 的主要优点:
systemd 提供了和 sysvinit 兼容的特性。系统中已经存在的服务和进程无需修改。这降低了系统向 systemd 迁移的成本,使得 systemd 替换现有初始化系统成为可能。
root@am57xx-evm:~# ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Oct 3 21:08 /sbin/init -> /lib/systemd/systemd
root@am57xx-evm:~#
为了与传统的 SysV 兼容,如果将 systemd 以 init 名称启动,并且"PID≠1",那么它将执行 telinit 命令并将所有命令行参数原封不动的传递过去。这样对于普通的登录会话来说,无论是调用 init 还是调用 telinit 都是等价的。
当作为系统实例运行时,systemd将会按照system.conf配置文件以及system.conf.d配置目录中的指令工作;当作为用户实例运行时,systemd 将会按照user.conf配置文件 以及 user.conf.d配置目录中的指令工作。
systemd 提供了比 upstart 更激进的并行启动能力,采用了 socket / D-Bus activation 等技术启动服务。一个显而易见的结果就是:更快的启动速度。
为了减少系统启动时间,systemd 的目标是:尽可能启动更少的进程 尽可能将更多进程并行启动
upstart 的并行方式:
upstart 增加了系统启动的并行性,从而提高了系统启动速度。但是在 upstart 中,有依赖关系的服务还是必须先后启动。比如任务 A,B,(C,D)因为存在依赖关系,所以在这个局部,还是串行执行。
systemd 的并行方式:
systemd 能够更进一步提高并发性,即便对于那些 upstart 认为存在相互依赖而必须串行的服务,比如 Avahi 和 D-Bus 也可以并发启动。在 systemd 中,所有的任务都同时并发执行,总的启动时间被进一步降低为 T1。可见 systemd 比 upstart 更进一步提高了并行启动能力,极大地加速了系统启动时间。
当 sysvinit 系统初始化的时候,它会将所有可能用到的后台服务进程全部启动运行。并且系统必须等待所有的服务都启动就绪之后,才允许用户登录。这种做法有两个缺点:首先是启动时间过长,其次是系统资源浪费。
某些服务很可能在 很长一段时间内,甚至整个服务器运行期间都没有被使用过。比如 CUPS,打印服务在多数服务器上很少被真正使用到。您可能没有想到,在很多服务器上 SSHD 也是很少被真正访问到的。花费在启动这些服务上的时间是不必要的;同样,花费在这些服务上的系统资源也是一种浪费。
systemd 可以提供按需启动的能力,只有在某个服务被真正请求的时候才启动它。当该服务结束,systemd 可以关闭它,等待下次需要时再次启动它。这有点类似于以前系统中的 inetd,并且有很多文章介绍如何把过去 inetd 管理的服务迁移到 systemd。
systemd 利用了 Linux 内核的特性即 cgroups 来完成跟踪的任务。当停止服务时,通过查询 cgroups,systemd 可以确保找到所有的相关进程,从而干净地停止服务。
cgroups 已经出现了很久,它主要用来实现系统资源配额管理。cgroups 提供了类似文件系统的接口,使用方便。当进程创建子进程时,子进程会继承父进程的 cgroups 。因此无论服务如何启动新的子进程,所有的这些相关进程都会属于同一个 cgroups ,systemd 只需要简单地遍历指定的 cgroups 即可正确地找到所有的相关进程,将它们一一停止即可。
启动挂载点:
传统的 linux 系统中,用户可以用 /etc/fstab 文件来维护固定的文件系统挂载点。这些挂载点在系统启动过程中被自动挂载,一旦启动过程结束,这些挂载点就会确保存在。这些挂载点都是对系统运行至关重要 的文件系统,比如 HOME 目录。和 sysvinit 一样,Systemd 管理这些挂载点,以便能够在系统启动时自动挂载它们。systemd 还兼容 /etc/fstab 文件,您可以继续使用该文件管理挂载点。
自动挂载:
有时候用户还需要动态挂载点,比如打算访问 DVD 或者 NFS 共享的内容时,才临时执行挂载以便访问其中的内容,而不访问光盘时该挂载点被取消(umount),以便节约资源。传统地,人们依赖 autofs 服务来实现这种功能。systemd 内建了自动挂载服务,无需另外安装 autofs 服务,可以直接使用 systemd 提供的自动挂载管理能力来实现 autofs 的功能。
系统启动过程是由 很多的独立工作共同组成的,这些工作之间可能存在依赖关系,比如挂载一个 NFS 文件系统必须依赖网络能够正常工作。systemd 虽然能够最大限度地并发执行很多有依赖关系的工作,但是类似"挂载 NFS"和"启动网络"这样的工作还是存在天生的先后依赖关系,无法并发执行。对于这些任务,systemd 维护一个"事务一致性"的概念,保证所有相关的服务都可以正常启动而不会出现互相依赖,以至于死锁的情况。
systemd 把初始化过程中需要需要做的每件事都抽象成了配置单元,即unit。
系统初始化需要做的事情非常多。需要启动后台服务,比如启动 ssh 服务;需要做配置工作,比如挂载文件系统。这个过程中的每一步都被 systemd 抽象为一个配置单元,即 unit。可 以认为一个服务是一个配置单元,一个挂载点是一个配置单元,一个交换分区的配置是一个配置单元等等。systemd 将配置单元归纳为以下一些不同的类型。然而,systemd 正在快速发展,新功能不断增加。所以配置单元类型可能在不久的将来继续增加。
下面是一些常见的 unit 类型:
service :代表一个后台服务进程,比如 mysqld。这是最常用的一类。
socket :此类配置单元封装系统和互联网中的一个套接字 。当下,systemd 支持流式、数据报和连续包的 AF_INET、AF_INET6、AF_UNIX socket 。
每一个套接字配置单元都有一个相应的服务配置单元 。
相应的服务在第一个"连接"进入套接字时就会启动(例如:nscd.socket 在有新连接后便启动 nscd.service)。
device :此类配置单元封装一个存在于 Linux 设备树中的设备。
每一个使用 udev 规则标记的设备都将会在 systemd 中作为一个设备配置单元出现。
mount :此类配置单元封装文件系统结构层次中的一个挂载点。Systemd 将对这个挂载点进行监控和管理。
比如可以在启动时自动将其挂载;可以在某些条件下自动卸载。
Systemd 会将 /etc/fstab 中的条目都转换为挂载点,并在开机时处理。
automount :此类配置单元封装系统结构层次中的一个自挂载点。
每一个自挂载配置单元对应一个挂载配置单元 ,当该自动挂载点被访问时,systemd 执行挂载点中定义的挂载行为。
swap:和挂载配置单元类似,交换配置单元用来管理交换分区。
用户可以用交换配置单元来定义系统中的交换分区,可以让这些交换分区在启动时被激活。
target :此类配置单元为其他配置单元进行逻辑分组。它们本身实际上并不做什么,只是引用其他配置单元而已。
这样便可以对配置单元做一个统一的控制。这样就可以实 现大家都已经非常熟悉的运行级别概念。
比如想让系统进入图形化模式,需要运行许多服务和配置命令,这些操作都由一个个的配置单元表示,将所有这些配置单元 组合为一个目标(target),就表示需要将这些配置单元全部执行一遍以便进入目标所代表的系统运行状态。
(例如:multi-user.target 相当于在传统使用 SysV 的系统中运行级别 5)
timer:定时器配置单元用来定时触发用户定义的操作,这类配置单元取代了 atd、crond 等传统的定时服务。
snapshot :与 target 配置单元相似,快照是一组配置单元。它保存了系统当前的运行状态。
path:文件系统中的一个文件或目录。
scope:用于 cgroups,表示从 systemd 外部创建的进程。
slice:用于 cgroups,表示一组按层级排列的单位。slice 并不包含进程,但会组建一个层级,并将 scope 和 service 都放置其中。
每个配置单元都有一个对应的配置文件,系统管理员的任务就是编写和维护这些不同的配置文件,比如一个 MySQL 服务对应一个 mysql.service 文件。这种配置文件的语法非常简单,用户不需要再编写和维护复杂的系统脚本了。
unit的配置文件一般在/lib/systemd/system/、/usr/lib/systemd/user/和/run/systemd/generator/:
root@am57xx-evm:~# ls /lib/systemd/system/
-.slice emergency.target nfs-statd.service runlevel2.target systemd-backlight@.service systemd-remount-fs.service
alsa-restore.service exit.target nss-lookup.target runlevel2.target.wants systemd-bootchart.service systemd-resolved.service
alsa-state.service final.target nss-user-lookup.target runlevel3.target systemd-exit.service systemd-rfkill.service
root@am57xx-evm:~#
root@am57xx-evm:~# ls /usr/lib/systemd/user/
basic.target busnames.target exit.target printer.target pulseaudio.socket smartcard.target sound.target timers.target
bluetooth.target default.target paths.target pulseaudio.service shutdown.target sockets.target systemd-exit.service
可以通过下面的指令查询systemd配置目录:
root@am57xx-evm:~# pkg-config systemd --print-variables
binfmtdir
catalogdir
modulesloaddir
pcfiledir
prefix
sysctldir
systemdshutdowndir
systemdsleepdir
systemdsystemconfdir
systemdsystemgeneratordir
systemdsystempresetdir
systemdsystemunitdir
systemdsystemunitpath
systemduserconfdir
systemdusergeneratordir
systemduserpresetdir
systemduserunitdir
systemduserunitpath
systemdutildir
systemgidmax
systemuidmax
sysusersdir
tmpfilesdir
root@am57xx-evm:~# pkg-config systemd --variable=systemdsystemunitdir // unit dir
/lib/systemd/system
root@am57xx-evm:~# pkg-config systemd --variable=systemdsystemconfdir // config dir
/etc/systemd/system
root@am57xx-evm:~# pkg-config systemd --variable=systemdsystemgeneratordir
/lib/systemd/system
systemctl cat命令可以用来查看配置文件,那么我们来看一下sshd配置文件的内容,分析下它每项配置的含义是什么。
systemctl cat sshd.service查看的service配置文件:
[Unit]
Description=OpenSSH server daemon # 当前服务的简单描述
Documentation=man:sshd(8) man:sshd_config(5) # sshd是启动脚本,sshd_config是配置文件
After=network.target sshd-keygen.service # 启动ssh服务之前会先启动这两个Unit
Wants=sshd-keygen.service # 此Unit启动成功与否不影响ssh服务的正常启动
[Service]
Type=notify # ssh服务启动成功后会通知systemd,再启动其他依赖服务
EnvironmentFile=/etc/sysconfig/sshd # 指定ssh服务的环境参数配置文件
ExecStart=/usr/sbin/sshd -D $OPTIONS # 启动ssh服务执行的命令
ExecReload=/bin/kill -HUP $MAINPID # 重启ssh服务执行的命令
KillMode=process # process表示只停止主进程,不停止子进程
Restart=on-failure # 进程非正常退出时,包括信号终止和超时,会重启服务
RestartSec=42s # 上面Restart重启之前需要等待42秒再重启
[Install]
WantedBy=multi-user.target # ssh服务所在的系统运行模式
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8