从Centos7.x开始,传统的init已经被舍弃,取而代之的是Systemd
什么是daemon与服务(service)
简单的说,系统为某些功能提供了一些服务
daemon既然是一个程序执行后的进程,那么daemon所处的那个本来的程序通常是如何命名的(daemon程序的命名方式)?每一个服务的开发者,在开发他们的服务时,都有特别的故事.不过无论如何,这些服务的名称被建立之后,在Linux中使用时,通常在服务的名称之后会加一个d,例如计划任务命令建立的at与cron这两个服务,他们的程序名会被取为atd和cornd,这个d就是代表daemon的意思.所以我们在使用ps和top查看进程时,都会发现很多的{xxxx}d进程,通常就是daemon的一些进程
systemd使用的unit分类
从Centos7.x开始,Red Hat系列的发行版放弃沿用多年的SystemV开机启动服务的流程,就是前一届提到的init启动脚本的方法,改用systemd这个启动服务管理机制.那么systemd有什么好处呢?
并行处理所有服务,加速开机流程
一经要求就响应的on-daemon启动方式
systemd全部就是仅有一个systemctl服务搭配systemctl命令来处理,无需其他额外的命令来支持
服务依赖性得到自我检查
依赖daemon功能分类
systemd旗下管理的服务非常多,为了梳理清楚所有服务的类型,因此首先systemd先定义所有的服务为一个服务单位(unit),并将该unit归类到不同的服务类型(type)之中.就得init仅分为stand,alone与super daemon, 是在不够好,systemd将服务单位(unit)区分为service,socket,target,path,snapshot,timer等多种不同的类型(type),方便管理员分类与记忆
将多个daemon集合成为一个群组
向下兼容旧有的init服务脚本
- 如果某个服务启动是管理员自己手动执行启动,而不是使用systemctl去启动(例如你自己手动输入crond来启动crond服务),那么systemd将无法检测到该服务,而无法进一步管理
- systemd启动过程中,无法与管理员通过标准输入传入信息,因此自行编写systemd的启动设置时,务必取消交互机制
systemd的配置文件放置目录
基本上systemd将过去所谓的daemon执行脚本统统称为一个服务单位(unit),而每种服务单位根据功能来区分时,就分类为不同的类型(type).基本的我服务包括系统服务,数据监听与交换的socket文件服务(socket),存储系统状态的快照服务,提供不同类似运行级别分类的操作环境(target).这些服务的配置文件都放在一下的目录中:
- /usr/lib/systemd/system/:每个系统最主要的启动脚本设置,有点;类似以前的/etc/init.d下面的文件
- /run/systemd/system/:系统执行过程中所产生的服务脚本,这个脚本的优先级比/usr/lib/systemd/system/的优先级高
- /etc/systemd/system/:管理员根据主机系统的需求建立的执行脚本,其实这个目录有点像之前的/etc/rc.d/rc5.d/Sxx之类的功能,执行优先级又比/run/systemd/system高
也就是说到底操作系统会不会启动某些服务需要看/etc/systemd/system/下面的配置,所以该目录下面有一大堆链接文件,其实都是放置在/usr.lib/systemd/system/下面,因此如果你想要修改某个服务启动的设置,应该去/usr/lib/systemd/system/下面修改才对,/etc/systemd/system/仅是链接到正确的执行脚本配置文件而已.所以想要看执行脚本设置,应该就得要到/usr/lib/systemd/system/下面去看才对
systemd的unit类型分类说明
通过systemctl管理服务
通过systemctl管理单一服务(service unit)的启动/开机启动与查看状态
一般服务的启动有两个阶段,一个是开机的时候设置要不要启动这个服务,以及你现在要不要启动这个服务,这两者之间有很大 的差异.举个例子,假如我们现在要立刻停止atd这个服务,正确的方法(不要用kill)要怎么处理
上面的范例中我们已经关闭了atd,这样做才是对的.不应该使用kill来关闭一个正常的服务
使用systemctl status atd的输出结果中,第2,3行十分重要,因为哪个是告知我们该unit下次开机会不会默认启动,以及目前启动的状态,这个相当重要,最下面的unit日志文件,如果你的unit出错过,查看这个地方也是相当重要的
那么现在问一个问题,你的atd现在是关闭的,未来重新启动之后,这个服务会不会再次启动?答案是会.因为胡第二行中他是enabled,这样理解所谓的现在的状态和开机默认状态两者的差异
第三行有一下几个状态:
通过systemctl查看系统上的所有服务
使用systemctl list-unit-files会将系统中所欲的服务统统显示出来,而不像list-units仅仅以unit分类做大致得到说明.至于STATE状态就是前两个小节谈到的开机是否会加载的那个状态项目.主要有enabled,disabled,mask,static等假设我不需要这么多的unit项目,我只想知道service这种类别的daemon而已,而且不论是否已经成功,统统都要显示出来,那该如何是好?
与systemd的daemon运行过程相关的目录简介
systemctl针对service类型的配置文件
以前我们想要建立系统服务,就得到/etc/init.d/下面建立对应的bash脚本来完成.那么现在systemd的环境下面,如果我们想要设置相关的服务启动环境,那应该如何处理?这就是本小节的任务
systemctl配置文件相关目录简介
我们知道服务的管理是通过systemd来完成,而systyemd的配置文件大部分放置于/usr/lib/systemd/system/目录中.但是Red Hat官方文件中指出,该目录的文件主要是原本软件所提供的设置,建议不要修改.而要修改的位置应该放置于/etc/systemd/system/目录中.举例来说,你想要额外修改vsftpd.service的话,他们的建议应该放置到那些位置?
- /usr/lib/systemd/system/vsftpd.service:官方发布的默认配置文件
- /etc/systemd/system/vsftpd.service.d/custom.conf:在/etc/systemd/system下面建立与配置文件相同文件名的目录,但要加上.d的扩展名,然后在该目录下建立配置文件即可.另外,配置文件的扩展名最好使用.conf.这个目录下的文件会"累加其他设置"到/usr/lib/systremd/system/vsftpd.service中
- /etc/systemd/system/vsftpd.service.wants/*:此目录的文件为链接文件,设置依赖服务的链接,意思是启动vsftpd.service之后,最好在加上该目录下建议的服务
- /etc/systemd/system/vsftpd.service.requires/*:此目录的文件为链接文件,设置依赖服务的链接,意思是启动vsftpd.service之前,需要启动那些服务的意思
systemctl配置文件的设置项目简介
了解了配置文件的相关目录与文件之后,当然得要了解一下配置文件本身的内容了,让我们先来看一看sshd.service的内容
分析上面的配置文件,我们大概能够将整个设置分为三个部分
- [Service],[Socket],[Timer],[Mount],[Path]:不同的unit类型就得要使用相对应的设置项目.我们使用ssh.service来当模板,所以使用[Service]来设置.这个项目主要用来规范服务启动的脚本,环境配置文件名,重新启动的方式等
至于配置文件内的有些设置骨=规则还是要说明一下:
- 设置项目通常是可以重复的,例如我们可以重复设置两个After在配置文件中,不过,后面的设置会替代前面的.因此,如果你想将设置值归零,可以使用类似[After=]的设置,亦即该项目的等号后面什么都没有,就将设置值归零了(reset)
- 如果设置参数需要有[是/否]的项目(布尔值,boolean),你可以使用1,yes,true,on代表启动,用0,no,false,off代表关闭,随你喜好设置
- 空白行,开头为#或者;的那一行,都代表注释
每一部分里面还有很多的设置,我们使用一个简单的表格来说明每个项目的内容
