欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  科技

CentOS 7上的系统管理之:Systemd和systemctl

程序员文章站 2022-05-09 14:14:08
参考资料: Chapter 10. Managing Services with systemd Red Hat Enterprise Linux 7 | Red Hat Customer Portal systemd - Wikipedia man手册:systemd(1)和systemctl(1 ......

参考资料:

chapter 10. managing services with systemd red hat enterprise linux 7 | red hat customer portal

systemd - wikipedia

man手册:systemd(1)和systemctl(1)

ibm developer works上,刘明老师关于centos 5/6/7的init系统的介绍

简介

早期的centos 5系统上,使用的init系统是sysv init。这套系统运行稳定,使用shell脚本的形式,串行地一个个启动进程,当前一个进程启动完毕后,再启动后一个。这种方式带来的缺点是:

  • 计算机的启动速度很慢,后面的进程必须等待前面的进程依次串行地启动完毕方可启动。
  • 有的服务可能在启动后很长的一段时间或者几乎不会使用到,例如服务器中的打印服务。

发展到centos 6的时候,init系统换成了upstart,这个系统有效的解决了上述的缺点,实现了并行启动和按需启动。

而到了centos 7的时候,则出现了systemd这套init系统,它更加完善了并行启动和按需启动,使得启动的速度更上一层楼。这里的按需启动,指的是某个服务被设置为开机启动,当开机时该服务并没有真正的启动,只是注册好了socket占用,等待第一次有请求进来的时候,systemd悬挂该请求然后启动服务,服务启动完毕后就恢复该请求,从而实现按需启动,这种方式也变相加速了系统的启动速度。

systemd不仅仅是一个服务,还可以用于管理系统自身的方方面面,例如日志、类似crond的任务调度程序(timer)、电源管理等等。

systemd支持向后兼容(backward compatible)sysv init的脚本等其他的诸多特性,使得其目前在慢慢成为linux发行版的一种标准,这是一件好事。

这篇文章所能阐述的也只是systemd的皮毛而已。主要描述了运维人员在日常使用中应该掌握的systemctl命令,以及如何阅读unit文件以及寻找帮助。

unit

在systemd中使用配置文件来进行管理,这些配置文件叫做unit。unit有许许多多的类型,如下。

unit 类型 文件扩展名 描述
service unit .service 用于管理系统的服务unit,最常用,一般由所安装的服务所提供(httpd、mysql等)
target unit .target target unit表示的是期望系统运行于哪个状态下,用户的目标是什么。比如运行于支持图形显示的状态下,那么它除了可以提供cli的shell界面以外,还需要额外启用许多服务等组件用于支持图形界面,这些组件也是一个个的unit,所以target就是多个unit的集合(这些unit之间还有先后和依赖关系)。因此,target就是用来模拟以前的运行级别(runlevel)的概念。
automount unit .automount 文件系统自动挂载点。
device unit .device 一个被内核所识别的设备文件。
mount unit .mount 一个文件系统的挂载点。
path unit .path 文件系统中的一个文件或目录。
scope unit .scope 一个外部创建的进程。
slice unit .slice 一组用于管理系统进程的分层组织的单元。
snapshot unit .snapshop systemd管理器所保存的一个状态,因此称之为快照。
socket unit .socket 一个进程间通信(ipc)socket。
swap unit .swap 一个swap设备或者swap文件。

timer unit

.timer

一个systemd timer。

unit配置文件

unit文件存在于三个位置:

  • /usr/lib/systemd/system/:软件程序包所提供的unit文件。例如httpd程序包提供了httpd.service文件。
  • /run/systemd/system/:运行时所创建的unit文件。优先级高于已安装的服务unit文件所在的目录。
  • /etc/systemd/system/:通过systemctl enable所创建的和用于扩展一个服务所添加的unit文件目录。优先级高于运行时unit文件。

优先级:/etc/systemd/system/ --> /run/systemd/system/ --> /usr/lib/systemd/system/。

systemd配置文件

/etc/systemd/system.conf是systemd的配置文件,用户可以编辑此文件来修改值。想要恢复默认值的话直接删除此文件即可。文件中每个选项的作用可以参考man手册systemd-system.conf(5)。

主特性

  • 基于socket激活(socket-based):在引导时,系统针对所有支持这类激活的系统服务创建监听socket,一旦服务启动就将这些socket传递给它们。这不仅允许systemd并行启动服务,还使得服务在重启的时候不会丢失任何在其服务不可用期间发送给它的消息(因为相关的socket仍然可以访问并且将所有的消息放入队列中)。该特性需要使用socket unit。
  • 基于总线激活(bus-based):当第一次被客户端程序访问的时候,使用d-bus用于ipc的系统服务可以按需启动。该特性需要使用d-bus服务文件。
  • 基于设备激活(device-based):当某种特定的硬件设备被插入或者可用时,支持基于设备激活的系统服务可以按需启动。该特性需要使用device unit。
  • 基于路径激活(path-based):当一个文件或者目录改变其状态时,支持基于路径激活的系统服务可以按需启动。该特性需要使用path unit。
  • 挂载和自动挂载点管理:systemd监视和管理挂载和自动挂载点。该特性需要使用mount和automount unit。
  • 进击的并行性(aggressive parallelization):由于具备基于socket激活的特性,只要所有监听的socket准备就绪,systemd就可以并行启动服务。结合系统服务的按需激活特性,并发激活有效地减少了系统启动的时间。
  • 支持事务的(transactional)unit激活逻辑:在激活或者关闭(deactivate)一个unit之前,systemd会计算它的依赖关系,创建一个临时事务,验证事务的一致性。当一个事务出现不一致的情况时,systemd会在其报错之前尝试去校对它并从中移除一些不重要的工作。
  • 向后兼容(backward compatibility)sysv init:支持遵循lsb标准的sysv init脚本。

兼容性变化

systemd在设计的时候尽可能做到与sysv和upstart兼容,不过还是有一些点是不同的,需要留意:

  • systemd对于运行级别的支持是有限的,并不是所有的运行级别都支持。其对于运行级别的支持是通过target unit来实现的,类似一种映射关系,例如graphical.target映射到runlevel5。systemd程序包在发行的时候包含了runlevel命令,不过用户因该尽量避免使用该命令。
  • systemctl程序不支持自定义子命令。在centos 6的sysv init脚本中,除了支持start、stop和restart这些基础子命令以外,脚本作者还可以撰写任何自己希望实现的功能实现额外的子命令。例如rhel 6中的iptables脚本支持panic子命令,该子命令告诉系统进入panic模式,丢弃所有的流入和流出的数据包。而systemctl,仅支持文档中列出的子命令。
  • 非由systemd所启动的服务,无法收到systemctl管理。当使用systemd启动服务的时候,systemd会记录并追踪服务的主进程pid,systemctl命令通过该pid来管理服务进程。若用户通过程序的cli程序启动服务的话,那么systemd就无法获取并追踪该pid了。
  • systemd只能停止运行中的服务。在以前,rhel 6和以往的版本中,系统使用【/etc/rc0.d/】中的字符链接来关闭所有可用的服务而不关心它们的状态。在systemd中,只有运行中的服务会被关闭了。
  • 系统服务无法从标准输入流中读取数据。当systemd启动一个服务的时候,会将/dev/null和服务的stdin关联起来,使得用户无法与其交互。
  • 系统服务不会从调用它们的用户和会话中继承任何上下文(context,例如home和path这类环境变量)。每个服务运行在一个干净的执行上下文中。
  • 当加载一个sysv init脚本的时候,systemd从lsb头中读取依赖关系并在运行时解释。
  • systemd的服务unit有一个代码写死的5分钟超时时长,用于处理那些运行出现故障的服务。这个时长可以在独立的服务类unit文件中修改。

 

管理服务

在sysv init和upstart中,使用【/etc/rc.d/init.d/】下的shell脚本(一般是bash)来管理服务,使用的命令是service和chkconfig。在systemd中使用service类型的unit文件(.service文件)来管理,使用的命令统一为systemctl。

由于向后兼容的特性的存在,旧命令依然可用,但是官方并不建议。新旧命令的对应关系如下。

service命令和systemctl命令对照表,service命令用于管理一个服务的启动和停止。

service  systemctl  描述 
 service name start  systemctl start name.service  启动一个服务
 service name stop  systemctl stop name.service  停止一个服务
 service name restart  systemctl restart name.service  重启一个服务
 service name condrestart  systemctl try-restart name.serivce  只有当服务处于运行状态时才重启服务
 service name reload  systemctl reload name.service  重载服务,一般用于配置文件的修改后执行
 serivce name status

 systemctl status name.service

 systemctl is-active name.service

 查看服务的运行状态
 service --status-all  systemctl list-units --type service --all  查看所有服务的运行状态

chkconfig命令和systemctl命令对照表,chkconfig命令用于管理服务的开机启动情况以及将服务纳入chkconfig管理。

chkconfig systemctl 描述
 chkconfig name on  systemctl enable name.service  使服务开机启动
 chkconfig name off  systemctl disable name.service  禁止服务开机启动
 chkconfig --list name

 systemctl status name.service

 systemctl is-enable name.service

 查看服务是否开机启动
 chkconfig --list  systemctl list-unit-files --type service  列出所有的服务并检查其是否开机启动
 chkconfig --list  systemctl list-dependencies --after  列出在指定的unit之前需要被启动的服务
 chkconfig --list  systemctl list-dependencies --before  列出在指定的unit之后需要被启动的服务

在书写unit名称的时候,一般是建议写全名,这样比较能顾名思义,例如“httpd.service”。不过简写,不写unit类型后缀,那么systemctl也是可以识别的,如下2个命令的效果是一样的,systemctl会自动识别unit类型。

~]# systemctl stop nfs-server.service
~]# systemctl stop nfs-server

unit的名称如果比较长,可以定义一个简短的别名,想查看别名的话使用如下命令。show子命令可以查看很多unit的信息。

[root@c7-server ~]# systemctl show httpd.service -p names
names=httpd.service

如果结合chroot命令来运行systemctl命令的话,大部分命令是不可用的,除了systemctl enable和systemctl disable,详见。

列出服务

列出所有当前已载入的服务。

[root@c7-server ~]# systemctl list-units --type service
  unit                               load   active sub     description
  abrt-ccpp.service                  loaded active exited  install abrt coredump hook
  abrt-oops.service                  loaded active running abrt kernel log watcher
  abrt-xorg.service                  loaded active running abrt xorg log watcher
...
● kdump.service                      loaded failed failed  crash recovery kernel arming
...

unit:unit的完整名称。

load:加载的情况。

active:高级激活状态。

sub:低级激活状态。这个状态会取决于unit的类型有不同的状态值。

description:描述。

默认情况下列出的是已激活的服务(不过从上述结果来看,状态为failed的也可以被列出),想要查看已加载的所有状态的服务的话,需要传递--all选项。

注:--type和--all均有缩写版,为了顾名思义,这里尽量都参照官方文档,给出了完整版选项。

从结果上来看,load状态为not-found的也可以被列出。

[root@c7-server ~]# systemctl list-units --type service --all
  unit                                                  load      active   sub     description
  abrt-ccpp.service                                     loaded    active   exited  install abrt coredump hook
  abrt-oops.service                                     loaded    active   running abrt kernel log watcher
  abrt-vmcore.service                                   loaded    inactive dead    harvest vmcores for abrt
...
● apparmor.service                                      not-found inactive dead    apparmor.service
...
● kdump.service                                         loaded    failed   failed  crash recovery kernel arming
...

查看所有已安装的服务类unit单元,并可查看其是否开机启动。

[root@c7-server ~]# systemctl list-unit-files
unit file                                     state   
proc-sys-fs-binfmt_misc.automount             static
...
tmp.mount                                     disabled
...
cups.path                                     enabled
...
sssd-autofs.service                           indirect
...

显示服务状态

[root@c7-server ~]# systemctl status httpd.service
● httpd.service - the apache http server
   loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   active: inactive (dead)
     docs: man:httpd(8)
           man:apachectl(8)
[root@c7-server ~]# systemctl start httpd.service
[root@c7-server ~]# systemctl status httpd.service
● httpd.service - the apache http server
   loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   active: active (running) since fri 2019-11-22 11:49:33 cst; 1s ago
     docs: man:httpd(8)
           man:apachectl(8)
 main pid: 3193 (httpd)
   status: "processing requests..."
    tasks: 6
   cgroup: /system.slice/httpd.service
           ├─3193 /usr/sbin/httpd -dforeground
           ├─3195 /usr/sbin/httpd -dforeground
           ├─3196 /usr/sbin/httpd -dforeground
           ├─3197 /usr/sbin/httpd -dforeground
           ├─3199 /usr/sbin/httpd -dforeground
           └─3201 /usr/sbin/httpd -dforeground

nov 22 11:49:32 c7-server systemd[1]: starting the apache http server...
nov 22 11:49:33 c7-server systemd[1]: started the apache http server.

服务处于启动或停止的状态时,有不同的状态信息显示。使用root用户执行此命令,还可以显示日志信息。

如果仅希望查看服务是否启动,是否开机启动的话,可使用如下命令。

[root@c7-server ~]# systemctl is-active httpd.service
active
[root@c7-server ~]# systemctl is-enabled httpd.service
disabled

启动、停止和重启等

~]# systemctl start httpd.service
~]# systemctl stop httpd.service
~]# systemctl restart httpd.service

如果服务原本是停止的状态,则执行restart会启用该服务。如果我们希望只有当服务当前是启动的状态才重启的话,那么应该执行try-restart。

~]# systemctl try-restart httpd.service

某些服务支持在不打断运行状态的情况下重载服务从而读取配置文件。

~]# systemctl reload httpd.service

如果服务不支持重载的话,服务会忽略systemd的reload操作。为了方便,确保修改的配置文件一定会生效,可以执行如下2个子命令。

reload-or-restart:尝试reload,如果服务不支持就restart。

reload-or-try-restart:尝试reload,如果服务不支持就try-restart。如果服务本身没启动,那么再执行了此命令后应该也不会启动,需要手工启动。启动时,服务就会去读取配置文件了。

~]# systemctl reload-or-restart httpd.service
~]# systemctl reload-or-try-restart httpd.service

开机启动

~]# systemctl enable httpd.service
~]# systemctl disable httpd.service

当我们设置开机启动的时候,systemd会读取服务的配置文件(/usr/lib/systemd/system/httpd.service)中的[install]部分。

[install]
wantedby=multi-user.target

根据此部分的内容创建字符链接。

created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

如果服务本身是开机启动的,那么再执行一次enable的话并不会创建字符链接文件。想确保其一定创建的话,可使用reenable。

~]# systemctl reenable httpd.service
removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.
created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

关闭开机启动,就是删除字符链接了。

~]# systemctl disable httpd.service
removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.

systemd支持mask操作,如果一个服务被mask了,那么它无法被手动启动或者被其他服务所启动,也无法被设置为开机启动。

[root@c7-server ~]# systemctl mask httpd.service
created symlink from /etc/systemd/system/httpd.service to /dev/null.
[root@c7-server ~]# systemctl start httpd.service
failed to start httpd.service: unit is masked.
[root@c7-server ~]# systemctl enable httpd.service
failed to execute operation: cannot send after transport endpoint shutdown

可使用unmask来取消mask。

~]# systemctl unmask httpd.service
removed symlink /etc/systemd/system/httpd.service.

启动一个冲突的服务

在systemd中存在积极的(positive)依赖和消极的(negative)依赖。启动某个特定的服务,可能会要求启动一个或多个其他服务(此为积极的依赖),或者要求停止一个或多个其他服务(此为消极的依赖)。

当你尝试启动某个服务的时候,systemd会自动解决这些依赖关系。注意,systemd不会显式通知用户。如果你已经启动了一个服务a(比如postfix),然后你尝试启动服务b(比如sendmail),服务b和服务a有消极的依赖关系,那么当你启动服务b的时候,服务a会自动被停止。

注:sendmail和postfix都是邮件服务,之间存在消极的依赖关系。

 

target

systemd上使用target来模仿以前的运行级别的概念。不过要注意,这只是模仿,并不代表完全一样。target可以看作是一系列的unit的集合从而实现某个运行级别的功能。并且这些target之间会存在一个依赖链的关系。例如想启动图形界面(graphical.target)的话,就需要启动图形服务(gdm.service)或者账户服务(accounts-daemon.service)并且需要激活multi-user.target。同样地,multi-user.target需要启动网络服务(networkmanager.service)或者d-bus(dbus.service)并激活basic.target。basic.target也有自己的依赖。

运行级别和target的对应关系如下表。

运行级别 target units 描述
0 runlevel0.target, poweroff.target 关闭系统并关闭电源
1 runlevel1.target, rescue.target 救援模式
2 runlevel2.target, multi-user.target 非图形的多用户模式
3 runlevel3.target, multi-user.target 非图形的多用户模式
4 runlevel4.target, multi-user.target 非图形的多用户模式
5 runlevel5.target, graphical.target 带图形的多用户模式
6 runlevel6.target, reboot.target 重启

查看、切换运行级别/target的新旧命令如下表所示,应尽量避免使用旧的命令。

旧命令 新命令 描述
runlevel systemctl list-units --type target 查看当前系统运行于哪个target下
telinit runlevel systemctl isolate name.target 修改当前的target

查看默认target

~]# systemctl get-default
graphical.target

这个值的获取,其实是去检索字符链接。

~]# ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 36 oct 17 15:06 /etc/systemd/system/default.target -> /lib/systemd/system/graphical.target

查看当前target

~]# systemctl list-units --type target
unit                   load   active sub    description
basic.target           loaded active active basic system
bluetooth.target       loaded active active bluetooth
cryptsetup.target      loaded active active local encrypted volumes
getty-pre.target       loaded active active login prompts (pre)
getty.target           loaded active active login prompts
graphical.target       loaded active active graphical interface
local-fs-pre.target    loaded active active local file systems (pre)
local-fs.target        loaded active active local file systems
multi-user.target      loaded active active multi-user system
network-online.target  loaded active active network is online
network-pre.target     loaded active active network (pre)
network.target         loaded active active network
nfs-client.target      loaded active active nfs client services
nss-user-lookup.target loaded active active user and group name lookups
paths.target           loaded active active paths
remote-fs-pre.target   loaded active active remote file systems (pre)
remote-fs.target       loaded active active remote file systems
rpc_pipefs.target      loaded active active rpc_pipefs.target
slices.target          loaded active active slices
sockets.target         loaded active active sockets
sound.target           loaded active active sound card
swap.target            loaded active active swap
sysinit.target         loaded active active system initialization
timers.target          loaded active active timers

这个命令查询出来的,是当前已加载并激活的target。那么我们如何从里面找到当前的target是什么呢?

在bootup(7)的man手册中有描述,并不是所有的unit都是并行启动的,局部并行,整体依然是有先后次序之分的。例如:

sysinit.target --> basic.target --> multi-user.target --> graphical.target

rescue.target和emergency.target应该都是单独出现,也就是说:

见到rescue.target或者emergency.target或者graphical.target,那么就是对应的target,这三者之间不会有并存的关系。

见到multi-user.target,就看看有没有graphical.target,没有的话那就是multi-user.target。

设置默认target

~]# systemctl set-default multi-user.target
removed symlink /etc/systemd/system/default.target.
created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/multi-user.target.

修改当前的target

类似于以前的切换运行级别。

~]# systemctl isolate multi-user.target

执行了该命令以后,我在xshell的终端不会断开,不过vmware中的虚拟机已经退出了gui进入了cli。

CentOS 7上的系统管理之:Systemd和systemctl

切换救援(rescue)模式

当正常的系统启动流程失败的时候,可以进入救援模式。救援模式是一种单用户的模式,用于让用户修复系统。在救援模式中,os尝试挂载所有的文件系统并启动一些重要的系统服务,但它不会激活网络服务也只允许单用户同时登录。类似于以前的单用户模式。

~]# systemctl rescue

切换至救援模式以后,xshell终端全部退出并无法登陆,并收到广播通知。

broadcast message from root@c7-server on pts/1 (fri 2019-11-22 17:14:20 cst):

the system is going down to rescue mode now!

如果管理员不想让用户收到这个通知,可以使用--no-wall选项。

vmware控制台退出登录并要求root密码重新登录。

CentOS 7上的系统管理之:Systemd和systemctl

也可以使用isolate子命令切换至救援模式,但是isolate的方式,不会向其他用户发送切换救援模式的通知。

~]# systemctl isolate recue.target

切换紧急(emergency)模式

紧急模式是最小化的系统环境,相比救援模式,它所提供的服务就更少了,仅用于当进入救援模式都失败的时候。

紧急模式中,仅以只读的方式挂载根文件系统,其他的所有本地文件系统均不挂载,不会激活网络服务,只启动少许基本服务,需要root密码。

同样也支持isoloate切换方式和--no-walls选项。同样会退出xshell的终端,仅在vmware控制台允许登录。因此就不截图了,贴命令即可。

~]# systemctl emergency
~]# systemctl emergency --no-walls
~]# systemctl isolate emergency.target

 

电源管理

在systemd中使用systemctl统一了电源管理,新旧命令对照表如下:

旧命令 新命令 描述
halt systemctl halt 停止系统
poweroff systemctl poweroff 关机
reboot systemctl reboot 重启
pm-suspend systemctl suspend 悬挂系统
pm-hibernate systemctl hibernate 休眠系统
pm-suspend-hybrid systemctl hybrid-sleep 休眠并悬挂系统

关机

在linux中,关闭系统指的是halt,它会停止所有的进程以及cpu,但是并没有关闭掉电源。而poweroff则比较接近于我们所理解的关机。

如果在vmware中halt了一个系统,那么它会提示你需要手工关闭计算机的电源才可完成关机。而poweroff则不用。

CentOS 7上的系统管理之:Systemd和systemctl

 

 

因此在linux环境下的关机,应该是使用poweroff来取代halt。

正确关机:

~]# systemctl poweroff

同样,关机命令会向系统中的用户发送消息,支持--no-wall选项不发送消息。

~]# systemctl poweroff --no-all

关机也可以通过shutdown命令。虽然该命令也会调用systemctl来完成关机,但是它支持延时关机和取消延时关机。

~]# shutdown --poweroff hh:mm
~]# shutdown --halt +m
~]# shutdown -c

时间的参数,可以修改为now,等同于+0,表示立即关机。

重启

~]# systemctl reboot
~]# systemctl reboot --no-wall

悬挂和休眠

悬挂(suspend)指的是将系统的运行状态保存在内存中同时伴随内存模块异常,并关闭机器中的大部分设备。当用户回到计算机面前时,可以从内存中恢复。由于是从内存中恢复并且避免了再一次引导系统,因此它的恢复速度比休眠(hibernation)要快。

如果在悬挂期间电源出现故障,那么系统的状态就会丢失了。

~]# systemctl suspend

休眠(hibernate)和悬挂的作用相似,都是保存系统的状态避免了再次重新引导系统,区别在于休眠是将系统的状态保存在磁盘中。因此其恢复系统的速度较慢。

~]# systemctl hibernate

还有一个休眠并悬挂系统。

~]# systemctl hybrid-sleep

感觉作为运维,休眠和悬挂应该是不怎么会在服务器上所使用的,因此了解下常见的关机和重启操作即可。

 

创建和修改unit文件

创建和修改unit文件是理解systemd工作的重点和难点,对于服务的开发人员来说,应该是必备的技能。对于我目前的运维阶段来说,只要达到会看即可,因此这里先暂时留白,感兴趣的可以直接看开头参考资料中的红帽文档。

unit文件存在于文章开头处提到的三个目录,其中“/etc/systemd/system/”目录是留给管理员自定义的,因此我们自定义的unit文件建议放该目录下。

unit文件的文件名:

unit_name.type_extension

unit名和类型都是可替换的,合在一起叫做完整(full)的unit文件名。

例如sshd有两个常见的unit文件:sshd.service和sshd.socket。

如果我们想对一个unit做选项补充的话,可以新增一个“.d”目录并在其下创建补充的配置文件。例如当我们想为sshd.service增加自定义的配置选项时,可以创建sshd.service.d/custom.conf配置文件。详见文档

另外,还可以存在“sshd.service.wants/”和“sshd.service.requires/”目录,这些目录下都是字符链接文件,链接到其他的unit文件,以此来决定sshd.service的依赖关系。字符链接会自动产生,也可人为创建。详见文档

了解unit文件的结构

unit文件由典型的三部分构成:

  • [unit]:包含通用的选项,不受unit类型所影响。这部分主要提供了unit的简单描述信息,指定其行为,定义其依赖关系。
  • [unit type]:这部分的选项,是和unit类型相关的。即如果是.service类的unit,就有其相关的特定选项。
  • [install]:在通过systemctl enable或者disable的时候,所涉及到的选项。

[unit]和[install]的选项的完整参考手册,可见systemd.unit(5);[unit type]的选项,则需要根据unit的类型来确定。可通过以下命令查找对应的man手册。

~]# man -k systemd
...
systemd.scope (5)    - scope unit configuration
systemd.service (5)  - service unit configuration
systemd.slice (5)    - slice unit configuration
systemd.snapshot (5) - snapshot unit configuration
systemd.socket (5)   - socket unit configuration
...
systemd.swap (5)     - swap unit configuration
systemd.target (5)   - target unit configuration
...

当编辑或者新建了unit的文件,需要使用该命令重载systemd,使其知晓。

~]# systemctl daemon-reload

 

总结

最后对于unit文件的具体描述比较少,在初级运维的时候可能就够用了。但是在慢慢深入后,对于系统的排错或者需要开发服务的时候,就需要来了解这块的内容了,到时候若有遇到再来补充。