标签 systemd 下的文章

Devuan GNU+LinuxDebian 的分支,它不含有 systemd。如果你想知道 systemd 有什么问题,我们可以改天再讨论这个话题。

不过,如果你想要一个没有 systemd 的 Linux 发行版,那么 Devuan Beowulf 3.0 的发布对你来说应该是个好消息。

Devuan Beowulf 3.0 有什么新增功能?

Devuan 通常因其提供了替代性的初始化系统(如 SysV)而受到喜爱。

在本文中,我们将介绍 Devuan Beowulf 3.0 中的主要亮点。

基于 Debian 10.4 Buster

Debian 10 Buster 无疑是一款令人印象深刻的发行版系列,它的最新版本是 Debian 10.4。

而 Devuan Beowulf 3.0,是基于最新的 Debian 10.4 Buster 更新版本的。如果你不了解,可以查看 Debian 10.4 Buster 的官方公告,以了解更多信息。

Linux Kernel 4.19

在它的最新版本中装有 Linux Kernel 4.19 LTS 也是一个很好的加分项。

当然,这不是最新的内核,因为我们身处 “Debian 领域”,这里的事物并非总是最新的,但更加稳定。这个新内核应该可以解决以前版本中可能遇到的几个问题。

支持 ppc64el 架构

ppc64el 的支持在大多数时候都不是大事,但支持 PowerPC 和 Power ISA 处理器是一个优势。

顺便提一句,Devuan GNU+Linux 已经支持 i386、amd64、armel、armhf 和 arm64 架构。

添加 runit 和 OpenRC 作为可选项

想要更多替代的的初始化系统吗?现在最新版本中可选 runitopenrc

其他变化

除了上面的这样亮点外,你还可以发现它添加了独立守护进程 eudevelogind

启动页面、显示管理器和桌面主题也有了细微的变化。例如,启动菜单显示的是 “Debian” 而不是 “Devuan”。

如果你想了解有关 Devuan Beowulf 3.0.0 变更的更多技术详细信息,那么可以查看官方发行说明

花絮

Devuan 的发布版本以小行星命名。Beowulf 是一个编号为 38086 的小行星

总结

最新稳定版本的 Devuan Beowulf 3.0 是提供无 systemd 的发行版的很好的进展。

如果你想支持 Devuan 项目,请在财务上为他们的项目捐款通过其他方式

你觉得这个版本怎么样?请在下面评论让我知道你的想法!


via: https://itsfoss.com/devuan-3-release/

作者:Ankush Das 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

systemd 是所有进程之母,负责将 Linux 主机启动到可以做生产性任务的状态。

systemd(是的,全小写,即使在句子开头也是小写),是初始化程序(init)和 SystemV 初始化脚本的现代替代者。此外,它还有更多功能。

当我想到 init 和 SystemV 初始化时,像大多数系统管理员一样,我想到的是 Linux 的启动和关闭,而不是真正意义上的管理服务,例如在服务启动和运行后对其进行管理。像 init 一样,systemd 是所有进程之母,它负责使 Linux 主机启动到可以做生产性任务的状态。systemd 设定的一些功能比老的初始化程序要广泛得多,它要管理正在运行的 Linux 主机的许多方面,包括挂载文件系统、管理硬件、处理定时器以及启动和管理生产性主机所需的系统服务。

本系列文章是基于我的三期 Linux 培训课程《使用和管理 Linux:从零开始进行学习系统管理》部分内容的摘录,探讨了 systemd 在启动和启动完成后的功能。

Linux 引导

Linux 主机从关机状态到运行状态的完整启动过程很复杂,但它是开放的并且是可知的。在详细介绍之前,我将简要介绍一下从主机硬件被上电到系统准备好用户登录的过程。大多数时候,“引导过程”被作为一个整体来讨论,但这是不准确的。实际上,完整的引导和启动过程包含三个主要部分:

  • 硬件引导:初始化系统硬件
  • Linux 引导 boot :加载 Linux 内核和 systemd
  • Linux 启动 startup :systemd 为主机的生产性工作做准备

Linux 启动阶段始于内核加载了 init 或 systemd(取决于具体发行版使用的是旧的方式还是还是新的方式)之后。init 和 systemd 程序启动并管理所有其它进程,它们在各自的系统上都被称为“所有进程之母”。

将硬件引导与 Linux 引导及 Linux 启动区分开,并明确定义它们之间的分界点是很重要的。理解它们的差异以及它们每一个在使 Linux 系统进入生产状态所起的作用,才能够管理这些进程,并更好地确定大部分人所谓的“启动”问题出在哪里。

启动过程按照三步引导流程,使 Linux 计算机进入可进行生产工作的状态。当内核将主机的控制权转移到 systemd 时,启动环节开始。

systemd 之争

systemd 引起了系统管理员和其它负责维护 Linux 系统正常运行人员的广泛争议。在许多 Linux 系统中,systemd 接管了大量任务,这在某些开发者和sysadmins群体中引起了反对和不和谐。

SystemV 和 systemd 是执行 Linux 启动环节的两种不同的方法。SystemV 启动脚本和 init 程序是老的方法,而使用 目标 target 的 systemd 是新方法。尽管大多数现代 Linux 发行版都使用较新的 systemd 进行启动、关机和进程管理,但仍有一些发行版未采用。原因之一是某些发行版维护者和系统管理员喜欢老的 SystemV 方法,而不是新的 systemd。

我认为两者都有其优势。

为何我更喜欢 SystemV

我更喜欢 SystemV,因为它更开放。使用 Bash 脚本来完成启动。内核启动 init 程序(这是一个编译后的二进制)后,init 启动 rc.sysinit 脚本,该脚本执行许多系统初始化任务。rc.sysinit 执行完后,init 启动 /etc/rc.d/rc 脚本,该脚本依次启动 /etc/rc.d/rcX.d 中由 SystemV 启动脚本定义的各种服务。其中 X 是待启动的运行级别号。

除了 init 程序本身之外,所有这些程序都是开放且易于理解的脚本。可以通读这些脚本并确切了解整个启动过程中发生的事情,但是我不认为有太多系统管理员真正做到这一点。每个启动脚本都被编了号,以便按特定顺序启动预期的服务。服务是串行启动的,一次只能启动一个服务。

systemd 是由 Red Hat 的 Lennart Poettering 和 Kay Sievers 开发的,它是一个由大型的、编译的二进制可执行文件构成的复杂系统,不访问其源码就无法理解。它是开源的,因此“访问其源代码”并不难,只是不太方便。systemd 似乎表现出对 Linux 哲学多个原则的重大驳斥。作为二进制文件,systemd 无法被直接打开供系统管理员查看或进行简单更改。systemd 试图做所有事情,例如管理正在运行的服务,同时提供明显比 SystemV 更多的状态信息。它还管理硬件、进程、进程组、文件系统挂载等。systemd 几乎涉足于现代 Linux 主机的每个方面,使它成为系统管理的一站式工具。所有这些都明显违反了“程序应该小,且每个程序都应该只做一件事并做好”的原则。

为何我更喜欢 systemd

我更喜欢用 systemd 作为启动机制,因为它会根据启动阶段并行地启动尽可能多的服务。这样可以加快整个的启动速度,使得主机系统比 SystemV 更快地到达登录屏幕。

systemd 几乎可以管理正在运行的 Linux 系统的各个方面。它可以管理正在运行的服务,同时提供比SystemV 多得多的状态信息。它还管理硬件、进程和进程组、文件系统挂载等。systemd 几乎涉足于现代 Linux 操作系统的每方面,使其成为系统管理的一站式工具。(听起来熟悉吧?)

systemd 工具是编译后的二进制文件,但该工具包是开放的,因为所有配置文件都是 ASCII 文本文件。可以通过各种 GUI 和命令行工具来修改启动配置,也可以添加或修改各种配置文件来满足特定的本地计算环境的需求。

真正的问题

你认为我不能喜欢两种启动系统吗?我能,我会用它们中的任何一个。

我认为,SystemV 和 systemd 之间大多数争议的真正问题和根本原因在于,在系统管理层面没有选择权。使用 SystemV 还是 systemd 已经由各种发行版的开发人员、维护人员和打包人员选择了(但有充分的理由)。由于 init 极端的侵入性,挖出并替换 init 系统会带来很多影响,会带来很多在发行版设计过程之外难以解决的后果。

尽管该选择实际上是为我而选的,但我的Linux主机能不能开机、能不能工作,这是我平时最关心的。作为最终用户,甚至是系统管理员,我主要关心的是我是否可以完成我的工作,例如写我的书和这篇文章,安装更新以及编写脚本来自动化所有事情。只要我能做我的工作,我就不会真正在意发行版中使用的启动系统。

在启动或服务管理出现问题时,我会在意。无论主机上使用哪种启动系统,我都足够了解如何沿着事件顺序来查找故障并进行修复。

替换SystemV

以前曾有过用更现代的东西替代 SystemV 的尝试。大约在两个版本中,Fedora 使用了一个叫作 Upstart 的东西来替换老化的 SystemV,但是它没有取代 init,也没有提供我所注意到的任何变化。由于 Upstart 并未对 SystemV 的问题进行任何显著的改变,所以在这个方向上的努力很快就被放弃了,转而使用 systemd。

尽管大部分 Linux 开发人员都认可替换旧的 SystemV 启动系统是个好主意,但许多开发人员和系统管理员并不喜欢 systemd。与其重新讨论人们在 systemd 中遇到的或曾经遇到过的所有所谓的问题,不如带你去看两篇好文章,尽管有些陈旧,但它们涵盖了大多数内容。Linux 内核的创建者 Linus Torvalds 对 systemd 似乎不感兴趣。在 2014 年 ZDNet 的一篇文章《Linus Torvalds 和其他人对 Linux 上的 systemd 的看法》中,Linus 清楚地表达了他的感受。

“实际上我对 systemd 本身没有任何特别强烈的意见。我对一些核心开发人员有一些问题,我认为他们在对待错误和兼容性方面过于轻率,而且我认为某些设计细节是疯狂的(例如,我不喜欢二进制日志),但这只是细节,不是大问题。”

如果你对 Linus 不太了解的话,我可以告诉你,如果他不喜欢某事,他是非常直言不讳的,很明确,而且相当明确的表示不喜欢。他解决自己对事物不满的方式已经被社会更好地接受了。

2013 年,Poettering 写了一篇很长的博客,他在文章驳斥了关于 systemd 的迷思,同时对创建 systemd 的一些原因进行了深入的剖析。这是一分很好的读物,我强烈建议你阅读。

systemd 任务

根据编译过程中使用的选项(不在本系列中介绍),systemd 可以有多达 69 个二进制可执行文件执行以下任务,其中包括:

  • systemd 程序以 1 号进程(PID 1)运行,并提供使尽可能多服务并行启动的系统启动能力,它额外加快了总体启动时间。它还管理关机顺序。
  • systemctl 程序提供了服务管理的用户接口。
  • 支持 SystemV 和 LSB 启动脚本,以便向后兼容。
  • 服务管理和报告提供了比 SystemV 更多的服务状态数据。
  • 提供基本的系统配置工具,例如主机名、日期、语言环境、已登录用户的列表,正在运行的容器和虚拟机、系统帐户、运行时目录及设置,用于简易网络配置、网络时间同步、日志转发和名称解析的守护进程。
  • 提供套接字管理。
  • systemd 定时器提供类似 cron 的高级功能,包括在相对于系统启动、systemd 启动时间、定时器上次启动时间的某个时间点运行脚本。
  • 它提供了一个工具来分析定时器规范中使用的日期和时间。
  • 能感知分层的文件系统挂载和卸载功能可以更安全地级联挂载的文件系统。
  • 允许主动的创建和管理临时文件,包括删除。
  • D-Bus 的接口提供了在插入或移除设备时运行脚本的能力。这允许将所有设备(无论是否可插拔)都被视为即插即用,从而大大简化了设备的处理。
  • 分析启动环节的工具可用于查找耗时最多的服务。
  • 它包括用于存储系统消息的日志以及管理日志的工具。

架构

这些以及更多的任务通过许多守护程序、控制程序和配置文件来支持。图 1 显示了许多属于 systemd 的组件。这是一个简化的图,旨在提供概要描述,因此它并不包括所有独立的程序或文件。它也不提供数据流的视角,数据流是如此复杂,因此在本系列文章的背景下没用。

 title=

图 1:systemd 的架构,作者 Shmuel Csaba Otto Traian (CC BY-SA 3.0)

如果要完整地讲解 systemd 就需要一本书。你不需要了解图 1 中的 systemd 组件是如何组合在一起的细节。只需了解支持各种 Linux 服务管理以及日志文件和日志处理的程序和组件就够了。但是很明显, systemd 并不是某些批评者所宣称的那样,它是一个单一的怪物。

作为 1 号进程的 systemd

systemd 是 1 号进程(PID 1)。它的一些功能,比老的 SystemV3 init 要广泛得多,用于管理正在运行的 Linux 主机的许多方面,包括挂载文件系统以及启动和管理 Linux 生产主机所需的系统服务。与启动环节无关的任何 systemd 任务都不在本文讨论范围之内(但本系列后面的一些文章将探讨其中的一些任务)。

首先,systemd 挂载 /etc/fstab 所定义的文件系统,包括所有交换文件或分区。此时,它可以访问位于 /etc 中的配置文件,包括它自己的配置文件。它使用其配置链接 /etc/systemd/system/default.target 来确定将主机引导至哪个状态或目标。default.target 文件是指向真实目标文件的符号链接。对于桌面工作站,通常是 graphical.target,它相当于 SystemV 中的运行级别 5。对于服务器,默认值更可能是 multi-user.target,相当于 SystemV 中的运行级别 3。emergency.target 类似于单用户模式。 目标 target 服务 service 是 systemd 的 单元 unit

下表(图 2)将 systemd 目标与老的 SystemV 启动运行级别进行了比较。systemd 提供 systemd 目标别名以便向后兼容。目标别名允许脚本(以及许多系统管理员)使用 SystemV 命令(如 init 3)更改运行级别。当然,SystemV 命令被转发给 systemd 进行解释和执行。

systemd 目标SystemV 运行级别目标别名描述
default.target 此目标总是通过符号连接的方式成为 multi-user.targetgraphical.target 的别名。systemd 始终使用 default.target 来启动系统。default.target 绝不应该设为 halt.targetpoweroff.targetreboot.target 的别名。
graphic.target5runlevel5.target带有 GUI 的 multi-user.target
4runlevel4.target未用。在 SystemV 中运行级别 4 与运行级别 3 相同。可以创建并自定义此目标以启动本地服务,而无需更改默认的 multi-user.target
multi-user.target3runlevel3.target所有服务在运行,但仅有命令行界面(CLI)。
2runlevel2.target多用户,没有 NFS,其它所有非 GUI 服务在运行。
rescue.target1runlevel1.target基本系统,包括挂载文件系统,运行最基本的服务和主控制台的恢复 shell。
emergency.targetS 单用户模式:没有服务运行;不挂载文件系统。这是最基本的工作级别,只有主控制台上运行的一个紧急 Shell 供用户与系统交互。
halt.target 停止系统而不关闭电源。
reboot.target6runlevel6.target重启。
poweroff.target0runlevel0.target停止系统并关闭电源。

图 2:SystemV 运行级别与 systemd 目标和一些目标别名的比较

每个目标在其配置文件中都描述了一个依赖集。systemd 启动必须的依赖项,这些依赖项是运行 Linux 主机到特定功能级别所需的服务。当目标配置文件中列出的所有依赖项被加载并运行后,系统就在该目标级别运行了。在图 2 中,功能最多的目标位于表的顶部,从顶向下,功能逐步递减。

systemd 还会检查老的 SystemV init 目录,以确认是否存在任何启动文件。如果有,systemd 会将它们作为配置文件以启动它们描述的服务。网络服务是一个很好的例子,在 Fedora 中它仍然使用 SystemV 启动文件。

图 3(如下)是直接从启动手册页复制来的。它显示了 systemd 启动期间一般的事件环节以及确保成功启动的基本顺序要求。

                                        cryptsetup-pre.target
                                                   |
 (various low-level                                v
     API VFS mounts:                 (various cryptsetup devices...)
  mqueue, configfs,                                |    |
  debugfs, ...)                                    v    |
  |                                  cryptsetup.target  |
  |  (various swap                                 |    |    remote-fs-pre.target
  |   devices...)                                  |    |     |        |
  |    |                                           |    |     |        v
  |    v                       local-fs-pre.target |    |     |  (network file systems)
  |  swap.target                       |           |    v     v                 |
  |    |                               v           |  remote-cryptsetup.target  |
  |    |  (various low-level  (various mounts and  |             |              |
  |    |   services: udevd,    fsck services...)   |             |    remote-fs.target
  |    |   tmpfiles, random            |           |             |             /
  |    |   seed, sysctl, ...)          v           |             |            /
  |    |      |                 local-fs.target    |             |           /
  |    |      |                        |           |             |          /
  \____|______|_______________   ______|___________/             |         /
                              \ /                                |        /
                               v                                 |       /
                        sysinit.target                           |      /
                               |                                 |     /
        ______________________/|\_____________________           |    /
       /              |        |      |               \          |   /
       |              |        |      |               |          |  /
       v              v        |      v               |          | /
  (various       (various      |  (various            |          |/
   timers...)      paths...)   |   sockets...)        |          |
       |              |        |      |               |          |
       v              v        |      v               |          |
 timers.target  paths.target   |  sockets.target      |          |
       |              |        |      |               v          |
       v              \_______ | _____/         rescue.service   |
                              \|/                     |          |
                               v                      v          |
                           basic.target         rescue.target    |
                               |                                 |
                       ________v____________________             |
                      /              |              \            |
                      |              |              |            |
                      v              v              v            |
                  display-    (various system   (various system  |
              manager.service     services        services)      |
                      |         required for        |            |
                      |        graphical UIs)       v            v
                      |              |            multi-user.target
 emergency.service    |              |              |
         |            \_____________ | _____________/
         v                          \|/
 emergency.target                    v
                              graphical.target

图 3: systemd 启动图

sysinit.targetbasic.target 目标可以看作启动过程中的检查点。尽管 systemd 的设计目标之一是并行启动系统服务,但是某些服务和功能目标必须先启动,然后才能启动其它服务和目标。直到该检查点所需的所有服务和目标被满足后才能通过这些检查点。

sysinit.target 所依赖的所有单元都完成时,就会到达 sysinit.target。所有这些单元,包括挂载文件系统、设置交换文件、启动 Udev、设置随机数生成器种子、启动低层服务以及配置安全服务(如果一个或多个文件系统是加密的)都必须被完成,但在 sysinit.target 中,这些任务可以并行执行。

sysinit.target 启动了系统接近正常运行所需的所有低层服务和单元,它们也是进入 basic.target 所需的。

在完成 sysinit.target 之后,systemd 会启动实现下一个目标所需的所有单元。basic.target 通过启动所有下一目标所需的单元来提供一些额外功能。包括设置为各种可执行程序目录的路径、设置通信套接字和计时器之类。

最后,用户级目标 multi-user.targetgraphical.target 被初始化。要满足 graphical.target 的依赖必须先达到 multi-user.target。图 3 中带下划线的目标是通常的启动目标。当达到这些目标之一时,启动就完成了。如果 multi-user.target 是默认设置,那么你应该在控制台上看到文本模式的登录界面。如果 graphical.target 是默认设置,那么你应该看到图形的登录界面。你看到的具体的 GUI 登录界面取决于你的默认显示管理器。

引导手册页还描述并提供了引导到初始化 RAM 磁盘和 systemd 关机过程的图。

systemd 还提供了一个工具,该工具列出了完整的启动过程或指定单元的依赖项。单元是一个可控的 systemd 资源实体,其范围可以从特定服务(例如 httpd 或 sshd)到计时器、挂载、套接字等。尝试以下命令并滚动查看结果。

systemctl list-dependencies graphical.target

注意,这会完全展开使系统进入 graphical.target 运行模式所需的顶层目标单元列表。也可以使用 --all 选项来展开所有其它单元。

systemctl list-dependencies --all graphical.target

你可以使用 less 命令来搜索诸如 targetslicesocket 之类的字符串。

现在尝试下面的方法。

systemctl list-dependencies multi-user.target

systemctl list-dependencies rescue.target

systemctl list-dependencies local-fs.target

systemctl list-dependencies dbus.service

这个工具帮助我可视化我正用的主机的启动依赖细节。继续花一些时间探索一个或多个 Linux 主机的启动树。但是要小心,因为 systemctl 手册页包含以下注释:

“请注意,此命令仅列出当前被服务管理器加载到内存的单元。尤其是,此命令根本不适合用于获取特定单元的全部反向依赖关系列表,因为它不会列出被单元声明了但是未加载的依赖项。”

结尾语

即使在没有深入研究 systemd 之前,很明显能看出它既强大又复杂。显然,systemd 不是单一、庞大、独体且不可知的二进制文件。相反,它是由许多较小的组件和旨在执行特定任务的子命令组成。

本系列的下一篇文章将更详细地探讨 systemd 的启动,以及 systemd 的配置文件,更改默认的目标以及如何创建简单服务单元。

资源

互联网上有大量关于 systemd 的信息,但是很多都很简短、晦涩甚至是带有误导。除了本文提到的资源外,以下网页还提供了有关 systemd 启动的更详细和可靠的信息。

  • Fedora 项目有一个很好的实用的 systemd 指南。它有你需要知道的通过 systemd 来配置、管理和维护 Fedora 主机所需的几乎所有知识。
  • Fedora 项目还有一个不错的速记表,将老的 SystemV 命令与对比的 systemd 命令相互关联。
  • 有关 systemd 的详细技术信息及创建它的原因,请查看 Freedesktop.orgsystemd 描述
  • Linux.com 的“systemd 的更多乐趣”提供了更高级的 systemd 信息和技巧

还有针对 Linux 系统管理员的一系列技术性很强的文章,作者是 systemd 的设计师和主要开发者 Lennart Poettering。这些文章是在 2010 年 4 月至 2011 年 9 月之间撰写的,但它们现在和那时一样有用。关于 systemd 及其生态的其它许多好文都基于这些论文。


via: https://opensource.com/article/20/4/systemd

作者:David Both 选题:lujun9972 译者:messon007 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我有一个这样的电脑棒(图1),我把它用作通用服务器。它很小且安静,由于它是基于 x86 架构的,因此我为我的打印机安装驱动没有任何问题,而且这就是它大多数时候干的事:与客厅的共享打印机和扫描仪通信。

一个英特尔电脑棒。欧元硬币大小。

大多数时候它都是闲置的,尤其是当我们外出时,因此我认为用它作监视系统是个好主意。该设备没有自带的摄像头,也不需要一直监视。我也不想手动启动图像捕获,因为这样就意味着在出门前必须通过 SSH 登录,并在 shell 中编写命令来启动该进程。

因此,我以为应该这么做:拿一个 USB 摄像头,然后只需插入它即可自动启动监视系统。如果这个电脑棒重启后发现连接了摄像头也启动监视系统就更加分了。

在先前的文章中,我们看到 systemd 服务既可以手动启动或停止,也可以在满足某些条件时启动或停止。这些条件不限于操作系统在启动或关机时序中达到某种状态,还可以在你插入新硬件或文件系统发生变化时进行。你可以通过将 Udev 规则与 systemd 服务结合起来实现。

有 Udev 支持的热插拔

Udev 规则位于 /etc/udev/rules 目录中,通常是由导致一个 动作 action 条件 conditions 赋值 assignments 的单行语句来描述。

有点神秘。让我们再解释一次:

通常,在 Udev 规则中,你会告诉 systemd 当设备连接时需要查看什么信息。例如,你可能想检查刚插入的设备的品牌和型号是否与你让 Udev 等待的设备的品牌和型号相对应。这些就是前面提到的“条件”。

然后,你可能想要更改一些内容,以便以后可以方便使用该设备。例如,更改设备的读写权限:如果插入 USB 打印机,你会希望用户能够从打印机读取信息(用户的打印应用程序需要知道其模型、制造商,以及是否准备好接受打印作业)并向其写入内容,即发送要打印的内容。更改设备的读写权限是通过你之前阅读的“赋值” 之一完成的。

最后,你可能希望系统在满足上述条件时执行某些动作,例如在插入某个外部硬盘时启动备份程序以复制重要文件。这就是上面提到的“动作”的例子。

了解这些之后, 来看看以下几点:

ACTION=="add", SUBSYSTEM=="video4linux", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="e207", 
SYMLINK+="mywebcam", TAG+="systemd", MODE="0666", ENV{SYSTEMD_WANTS}="webcam.service"

规则的第一部分,

ACTION=="add", SUBSYSTEM=="video4linux",  ATTRS{idVendor}=="03f0", 
ATTRS{idProduct}=="e207" [etc... ]

表明了执行你想让系统执行的其他动作之前设备必须满足的条件。设备必须被添加到(ACTION=="add")机器上,并且必须添加到 video4linux 子系统中。为了确保仅在插入正确的设备时才应用该规则,你必须确保 Udev 正确识别设备的制造商(ATTRS{idVendor}=="03f0")和型号(ATTRS{idProduct}=="e207")。

在本例中,我们讨论的是这个设备(图2):

这个试验使用的是 HP 的摄像头。

注意怎样用 == 来表示这是一个逻辑操作。你应该像这样阅读上面的简要规则:

如果添加了一个设备并且该设备由 video4linux 子系统控制,而且该设备的制造商编码是 03f0,型号是 e207,那么…

但是,你从哪里获取的这些信息?你在哪里找到触发事件的动作、制造商、型号等?你可要使用多个来源。你可以通过将摄像头插入机器并运行 lsusb 来获得 IdVendoridProduct

lsusb
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 03f0:e207 Hewlett-Packard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 04f2:b1bb Chicony Electronics Co., Ltd
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

我用的摄像头是 HP 的,你在上面的列表中只能看到一个 HP 设备。ID 提供了制造商和型号,它们以冒号(:)分隔。如果你有同一制造商的多个设备,不确定哪个是哪个设备,请拔下摄像头,再次运行 lsusb , 看看少了什么。

或者…

拔下摄像头,等待几秒钟,运行命令 udevadmin monitor --environment ,然后重新插入摄像头。当你使用的是HP摄像头时,你将看到:

udevadmin monitor --environment
UDEV  [35776.495221] add      /devices/pci0000:00/0000:00:1c.3/0000:04:00.0
    /usb3/3-1/3-1:1.0/input/input21/event11 (input) 
.MM_USBIFNUM=00 
ACTION=add 
BACKSPACE=guess 
DEVLINKS=/dev/input/by-path/pci-0000:04:00.0-usb-0:1:1.0-event 
     /dev/input/by-id/usb-Hewlett_Packard_HP_Webcam_HD_2300-event-if00 
DEVNAME=/dev/input/event11 
DEVPATH=/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/
     usb3/3-1/3-1:1.0/input/input21/event11 
ID_BUS=usb 
ID_INPUT=1 
ID_INPUT_KEY=1 
ID_MODEL=HP_Webcam_HD_2300 
ID_MODEL_ENC=HPx20Webcamx20HDx202300 
ID_MODEL_ID=e207 
ID_PATH=pci-0000:04:00.0-usb-0:1:1.0 
ID_PATH_TAG=pci-0000_04_00_0-usb-0_1_1_0 
ID_REVISION=1020 
ID_SERIAL=Hewlett_Packard_HP_Webcam_HD_2300 
ID_TYPE=video 
ID_USB_DRIVER=uvcvideo 
ID_USB_INTERFACES=:0e0100:0e0200:010100:010200:030000: 
ID_USB_INTERFACE_NUM=00 
ID_VENDOR=Hewlett_Packard 
ID_VENDOR_ENC=Hewlettx20Packard 
ID_VENDOR_ID=03f0 
LIBINPUT_DEVICE_GROUP=3/3f0/e207:usb-0000:04:00.0-1/button 
MAJOR=13 
MINOR=75 
SEQNUM=3162 
SUBSYSTEM=input 
USEC_INITIALIZED=35776495065 
XKBLAYOUT=es 
XKBMODEL=pc105 
XKBOPTIONS= 
XKBVARIANT=

可能看起来有很多信息要处理,但是,看一下这个:列表前面的 ACTION 字段, 它告诉你刚刚发生了什么事件,即一个设备被添加到系统中。你还可以在其中几行中看到设备名称的拼写,因此可以非常确定它就是你要找的设备。输出里还显示了制造商的ID(ID_VENDOR_ID = 03f0)和型号(ID_VENDOR_ID = 03f0)。

这为你提供了规则条件部分需要的四个值中的三个。你可能也会想到它还给了你第四个,因为还有一行这样写道:

SUBSYSTEM=input

小心!尽管 USB 摄像头确实是提供输入的设备(键盘和鼠标也是),但它也属于 usb 子系统和其他几个子系统。这意味着你的摄像头被添加到了多个子系统,并且看起来像多个设备。如果你选择了错误的子系统,那么你的规则可能无法按你期望的那样工作,或者根本无法工作。

因此,第三件事就是检查网络摄像头被添加到的所有子系统,并选择正确的那个。为此,请再次拔下摄像头,然后运行:

ls /dev/video*

这将向你显示连接到本机的所有视频设备。如果你使用的是笔记本,大多数笔记本都带有内置摄像头,它可能会显示为 /dev/video0 。重新插入摄像头,然后再次运行 ls /dev/video*

现在,你应该看到多一个视频设备(可能是/dev/video1)。

现在,你可以通过运行 udevadm info -a /dev/video1 找出它所属的所有子系统:

udevadm info -a /dev/video1

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

 looking at device '/devices/pci0000:00/0000:00:1c.3/0000:04:00.0
  /usb3/3-1/3-1:1.0/video4linux/video1':
 KERNEL=="video1"
 SUBSYSTEM=="video4linux"
 DRIVER==""
 ATTR{dev_debug}=="0"
 ATTR{index}=="0"
 ATTR{name}=="HP Webcam HD 2300: HP Webcam HD"

[etc...]

输出持续了相当长的时间,但是你感兴趣的只是开头的部分:SUBSYSTEM =="video4linux"。你可以将这行文本直接复制粘贴到你的规则中。输出的其余部分(为简洁未显示)为你提供了更多的信息,例如制造商和型号 ID,同样是以你可以复制粘贴到你的规则中的格式。

现在,你有了识别设备的方式吗,并明确了什么事件应该触发该动作,该对设备进行修改了。

规则的下一部分,SYMLINK+="mywebcam", TAG+="systemd", MODE="0666" 告诉 Udev 做三件事:首先,你要创建设备的符号链接(例如 /dev/video1/dev/mywebcam。这是因为你无法预测系统默认情况下会把那个设备叫什么。当你拥有内置摄像头并热插拔一个新的时,内置摄像头通常为 /dev/video0,而外部摄像头通常为 /dev/video1。但是,如果你在插入外部 USB 摄像头的情况下重启计算机,则可能会相反,内部摄像头可能会变成 /dev/video1 ,而外部摄像头会变成 /dev/video0。这想告诉你的是,尽管你的图像捕获脚本(稍后将看到)总是需要指向外部摄像头设备,但是你不能依赖它是 /dev/video0/dev/video1。为了解决这个问题,你告诉 Udev 创建一个符号链接,该链接在设备被添加到 video4linux 子系统的那一刻起就不会再变,你将使你的脚本指向该链接。

第二件事就是将 systemd 添加到与此规则关联的 Udev 标记列表中。这告诉 Udev,该规则触发的动作将由 systemd 管理,即它将是某种 systemd 服务。

注意在这个两种情况下是如何使用 += 运算符的。这会将值添加到列表中,这意味着你可以向 SYMLINKTAG 添加多个值。

另一方面,MODE 值只能包含一个值(因此,你可以使用简单的 = 赋值运算符)。MODE 的作用是告诉 Udev 谁可以读或写该设备。如果你熟悉 chmod(你读到此文, 应该会熟悉),你就也会熟悉如何用数字表示权限。这就是它的含义:0666 的含义是 “向所有人授予对设备的读写权限”。

最后, ENV{SYSTEMD_WANTS}="webcam.service" 告诉 Udev 要运行什么 systemd 服务。

将此规则保存到 /etc/udev/rules.d 目录名为 90-webcam.rules(或类似的名称)的文件中,你可以通过重启机器或运行以下命令来加载它:

sudo udevadm control --reload-rules && udevadm trigger

最后的服务

Udev 规则触发的服务非常简单:

# webcam.service

[Service]
Type=simple
ExecStart=/home/[user name]/bin/checkimage.sh

基本上,它只是运行存储在你个人 bin/ 中的 checkimage.sh 脚本并将其放到后台。这是你在先前的文章中看过的内容。它看起来似乎很小,但那只是因为它是被 Udev 规则调用的,你刚刚创建了一种特殊的 systemd 单元,称为 device 单元。 恭喜。

至于 webcam.service 调用的 checkimage.sh 脚本,有几种方法从摄像头抓取图像并将其与前一个图像进行比较以检查变化(这是 checkimage.sh 所做的事),但这是我的方法:

#!/bin/bash 
# This is the checkimage.sh script

mplayer -vo png -frames 1 tv:// -tv driver=v4l2:width=640:height=480:device=
    /dev/mywebcam &>/dev/null 
mv 00000001.png /home/[user name]/monitor/monitor.png 

while true 
do 
   mplayer -vo png -frames 1 tv:// -tv driver=v4l2:width=640:height=480:device=/dev/mywebcam &>/dev/null 
   mv 00000001.png /home/[user name]/monitor/temp.png 

   imagediff=`compare -metric mae /home/[user name]/monitor/monitor.png /home/[user name]
       /monitor/temp.png /home/[user name]/monitor/diff.png 2>&1 > /dev/null | cut -f 1 -d " "` 
   if [ `echo "$imagediff > 700.0" | bc` -eq 1 ] 
       then 
           mv /home/[user name]/monitor/temp.png /home/[user name]/monitor/monitor.png 
       fi 
    
   sleep 0.5 
done

首先使用MPlayer从摄像头抓取一帧(00000001.png)。注意,我们怎样将 mplayer 指向 Udev 规则中创建的 mywebcam 符号链接,而不是指向 video0video1。然后,将图像传输到主目录中的 monitor/ 目录。然后执行一个无限循环,一次又一次地执行相同的操作,但还使用了Image Magick 的 compare 工具来查看最后捕获的图像与 monitor/ 目录中已有的图像之间是否存在差异。

如果图像不同,则表示摄像头的镜框里某些东西动了。该脚本将新图像覆盖原始图像,并继续比较以等待更多变动。

插线

所有东西准备好后,当你插入摄像头后,你的 Udev 规则将被触发并启动 webcam.servicewebcam.service 将在后台执行 checkimage.sh ,而 checkimage.sh 将开始每半秒拍一次照。你会感觉到,因为摄像头的 LED 在每次拍照时将开始闪。

与往常一样,如果出现问题,请运行:

systemctl status webcam.service

检查你的服务和脚本正在做什么。

接下来

你可能想知道:为什么要覆盖原始图像?当然,系统检测到任何动静,你都想知道发生了什么,对吗?你是对的,但是如你在下一部分中将看到的那样,将它们保持原样,并使用另一种类型的 systemd 单元处理图像将更好,更清晰和更简单。

请期待下一篇。


via: https://www.linux.com/blog/intro-to-linux/2018/6/systemd-services-reacting-change

作者:Paul Brown 选题:lujun9972 译者:messon007 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

五年前, Phoronix 发现 systemd 源码树已经接近 55 万行,所以好奇之下,让我们来看看今天的 systemd Git 存储库有多大:现在已超过 120 万行了!

systemd 代码行数

在 2017 年超过 systemd 的代码超过了 100 万行之后,如今在 systemd 的 Git 存储库上运行 GitStats 时,发现它已经有 1,207,302 行了。这 120 万行分布在 3,260 个文件中,来自近 1,400 个不同作者的 40,057 个提交。

systemd 提交数

去年,systemd 出现了创纪录的提交数量,但到目前为止,2019 年恐怕很难再次看到突破该记录。到目前为止,今年已有 2,145 个提交,而去年有 6,245 个提交,而 2016 年和 2017 年每年的提交总数不到 4 千个。

Lennart Poettering 依旧是 systemd 最多产的贡献者,今年迄今为止他贡献了超过 32% 的提交。今年其他多产贡献者包括 Yu Watanabe、ZbigniewJędrzejewski-Szmek、Frantisek Sumsal、Susant Sahani 和 Evgeny Vereshchagin 等人。到目前为止,已有大约 142 人为 systemd 的源代码树做出了贡献。

对于那些对其他系统统计数据感兴趣的人,请参阅最新的 GitStats 输出

继续 systemd 教程,这些特殊的例子可以展示给你如何更好的利用 systemd 定时器单元。

在这个 systemd 系列教程中,我们已经在某种程度上讨论了 systemd 定时器单元。不过,在我们开始讨论 sockets 之前,我们先来看三个例子,这些例子展示了如何最佳化利用这些单元。

简单的类 cron 行为

我每周都要去收集 Debian popcon 数据,如果每次都能在同一时间收集更好,这样我就能看到某些应用程序的下载趋势。这是一个可以使用 cron 任务来完成的典型事例,但 systemd 定时器同样能做到:

# 类 cron 的 popcon.timer

[Unit]
Description= 这里描述了下载并处理 popcon 数据的时刻

[Timer]
OnCalendar= Thu *-*-* 05:32:07
Unit= popcon.service

[Install]
WantedBy= basic.target

实际的 popcon.service 会执行一个常规的 wget 任务,并没有什么特别之处。这里的新内容是 OnCalendar= 指令。这个指令可以让你在一个特定日期的特定时刻来运行某个服务。在这个例子中,Thu 表示 “在周四运行”,*-*-* 表示“具体年份、月份和日期无关紧要”,这些可以翻译成 “不管年月日,只在每周四运行”。

这样,你就设置了这个服务的运行时间。我选择在欧洲中部夏令时区的上午 5:30 左右运行,那个时候服务器不是很忙。

如果你的服务器关闭了,而且刚好错过了每周的截止时间,你还可以在同一个计时器中使用像 anacron 一样的功能。

# 具备类似 anacron 功能的 popcon.timer

[Unit]
Description= 这里描述了下载并处理 popcon 数据的时刻

[Timer]
Unit=popcon.service
OnCalendar=Thu *-*-* 05:32:07
Persistent=true

[Install]
WantedBy=basic.target

当你将 Persistent= 指令设为真值时,它会告诉 systemd,如果服务器在本该它运行的时候关闭了,那么在启动后就要立刻运行服务。这意味着,如果机器在周四凌晨停机了(比如说维护),一旦它再次启动后,popcon.service 将会立刻执行。在这之后,它的运行时间将会回到例行性的每周四早上 5:32.

到目前为止,就是这么简单直白。

延迟执行

但是,我们提升一个档次,来“改进”这个基于 systemd 的监控系统。你应该记得,当你接入摄像头的时候,系统就会开始拍照。假设你并不希望它在你安装摄像头的时候拍下你的脸。你希望将拍照服务的启动时间向后推迟一两分钟,这样你就有时间接入摄像头,然后走到画框外面。

为了完成这件事,首先你要更改 Udev 规则,将它指向一个定时器:

ACTION=="add", SUBSYSTEM=="video4linux", ATTRS{idVendor}=="03f0", 
ATTRS{idProduct}=="e207", TAG+="systemd", ENV{SYSTEMD_WANTS}="picchanged.timer", 
SYMLINK+="mywebcam", MODE="0666"

这个定时器看起来像这样:

# picchanged.timer

[Unit]
Description= 在摄像头接入的一分钟后,开始运行 picchanged

[Timer]
OnActiveSec= 1 m
Unit= picchanged.path

[Install]
WantedBy= basic.target

在你接入摄像头后,Udev 规则被触发,它会调用定时器。这个定时器启动后会等上一分钟(OnActiveSec= 1 m),然后运行 picchanged.path,它会监视主图片的变化picchanged.path 还会负责接触 webcan.service,这个实际用来拍照的服务。

在每天的特定时刻启停 Minetest 服务器

在最后一个例子中,我们认为你决定用 systemd 作为唯一的依赖。讲真,不管怎么样,systemd 差不多要接管你的生活了。为什么不拥抱这个必然性呢?

你有个为你的孩子设置的 Minetest 服务。不过,你还想要假装关心一下他们的教育和成长,要让他们做作业和家务活。所以你要确保 Minetest 只在每天晚上的一段时间内可用,比如五点到七点。

这个跟之前的“在特定时间启动服务”不太一样。写个定时器在下午五点启动服务很简单…:

# minetest.timer

[Unit]
Description= 在每天下午五点运行 minetest.service

[Timer]
OnCalendar= *-*-* 17:00:00
Unit= minetest.service

[Install]
WantedBy= basic.target

…可是编写一个对应的定时器,让它在特定时刻关闭服务,则需要更大剂量的横向思维。

我们从最明显的东西开始 —— 设置定时器:

# stopminetest.timer

[Unit]
Description= 每天晚上七点停止 minetest.service

[Timer]
OnCalendar= *-*-* 19:05:00
Unit= stopminetest.service

[Install]
WantedBy= basic.target

这里棘手的部分是如何去告诉 stopminetest.service 去 —— 你知道的 —— 停止 Minetest. 我们无法从 minetest.service 中传递 Minetest 服务器的 PID. 而且 systemd 的单元词汇表中也没有明显的命令来停止或禁用正在运行的服务。

我们的诀窍是使用 systemd 的 Conflicts= 指令。它和 systemd 的 Wants= 指令类似,不过它所做的事情正相反。如果你有一个 b.service 单元,其中包含一个 Wants=a.service 指令,在这个单元启动时,如果 a.service 没有运行,则 b.service 会运行它。同样,如果你的 b.service 单元中有一行写着 Conflicts= a.service,那么在 b.service 启动时,systemd 会停止 a.service.

这种机制用于两个服务在尝试同时控制同一资源时会发生冲突的场景,例如当两个服务要同时访问打印机的时候。通过在首选服务中设置 Conflicts=,你就可以确保它会覆盖掉最不重要的服务。

不过,你会在一个稍微不同的场景中来使用 Conflicts=. 你将使用 Conflicts= 来干净地关闭 minetest.service

# stopminetest.service

[Unit]
Description= 关闭 Minetest 服务
Conflicts= minetest.service

[Service]
Type= oneshot
ExecStart= /bin/echo "Closing down minetest.service"

stopminetest.service 并不会做特别的东西。事实上,它什么都不会做。不过因为它包含那行 Conflicts=,所以在它启动时,systemd 会关掉 minetest.service.

在你完美的 Minetest 设置中,还有最后一点涟漪:你下班晚了,错过了服务器的开机时间,可当你开机的时候游戏时间还没结束,这该怎么办?Persistent= 指令(如上所述)在错过开始时间后仍然可以运行服务,但这个方案还是不行。如果你在早上十一点把服务器打开,它就会启动 Minetest,而这不是你想要的。你真正需要的是一个确保 systemd 只在晚上五到七点启动 Minetest 的方法:

# minetest.timer

[Unit]
Description= 在下午五到七点内的每分钟都运行 minetest.service

[Timer]
OnCalendar= *-*-* 17..19:*:00
Unit= minetest.service

[Install]
WantedBy= basic.target

OnCalendar= *-*-* 17..19:*:00 这一行有两个有趣的地方:(1) 17..19 并不是一个时间点,而是一个时间段,在这个场景中是 17 到 19 点;以及,(2) 分钟字段中的 * 表示服务每分钟都要运行。因此,你会把它读做 “在下午五到七点间的每分钟,运行 minetest.service”

不过还有一个问题:一旦 minetest.service 启动并运行,你会希望 minetest.timer 不要再次尝试运行它。你可以在 minetest.service 中包含一条 Conflicts= 指令:

# minetest.service

[Unit]
Description= 运行 Minetest 服务器
Conflicts= minetest.timer

[Service]
Type= simple
User= <your user name>

ExecStart= /usr/bin/minetest --server
ExecStop= /bin/kill -2 $MAINPID

[Install]
WantedBy= multi-user.targe

上面的 Conflicts= 指令会保证在 minstest.service 成功运行后,minetest.timer 就会立即停止。

现在,启用并启动 minetest.timer

systemctl enable minetest.timer
systemctl start minetest.timer

而且,如果你在六点钟启动了服务器,minetest.timer 会启用;到了五到七点,minetest.timer 每分钟都会尝试启动 minetest.service。不过,一旦 minetest.service 开始运行,systemd 会停止 minetest.timer,因为它会与 minetest.service “冲突”,从而避免计时器在服务已经运行的情况下还会不断尝试启动服务。

在首先启动某个服务时杀死启动它的计时器,这么做有点反直觉,但它是有效的。

总结

你可能会认为,有更好的方式来做上面这些事。我在很多文章中看到过“过度设计”这个术语,尤其是在用 systemd 定时器来代替 cron 的时候。

但是,这个系列文章的目的不是为任何具体问题提供最佳解决方案。它的目的是为了尽可能多地使用 systemd 来解决问题,甚至会到荒唐的程度。它的目的是展示大量的例子,来说明如何利用不同类型的单位及其包含的指令。我们的读者,也就是你,可以从这篇文章中找到所有这些的可实践范例。

尽管如此,我们还有一件事要做:下回中,我们会关注 sockets 和 targets,然后我们将完成对 systemd 单元的介绍。

你可以在 Linux 基金会和 edX 中,通过免费的 Linux 介绍课程中,学到更多关于 Linux 的知识。


via: https://www.linux.com/blog/intro-to-linux/2018/8/systemd-timers-two-use-cases-0

作者:Paul Brown 选题:lujun9972 译者:StdioA 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

对于 Linux 管理员来说这是一个重要(美妙)的话题,所以每个人都必须知道,并练习怎样才能更高效的使用它们。

在 Linux 中,无论何时当你安装任何带有服务和守护进程的包,系统默认会把这些服务的初始化及 systemd 脚本添加进去,不过此时它们并没有被启用。

我们需要手动的开启或者关闭那些服务。Linux 中有三个著名的且一直在被使用的初始化系统。

什么是初始化系统?

在以 Linux/Unix 为基础的操作系统上,init (初始化的简称) 是内核引导系统启动过程中第一个启动的进程。

init 的进程 id (pid)是 1,除非系统关机否则它将会一直在后台运行。

init 首先根据 /etc/inittab 文件决定 Linux 运行的级别,然后根据运行级别在后台启动所有其他进程和应用程序。

BIOS、MBR、GRUB 和内核程序在启动 init 之前就作为 Linux 的引导程序的一部分开始工作了。

下面是 Linux 中可以使用的运行级别(从 0~6 总共七个运行级别):

  • 0:关机
  • 1:单用户模式
  • 2:多用户模式(没有NFS)
  • 3:完全的多用户模式
  • 4:系统未使用
  • 5:图形界面模式
  • 6:重启

下面是 Linux 系统中最常用的三个初始化系统:

  • System V(Sys V)
  • Upstart
  • systemd

什么是 System V(Sys V)?

System V(Sys V)是类 Unix 系统第一个也是传统的初始化系统。init 是内核引导系统启动过程中第一支启动的程序,它是所有程序的父进程。

大部分 Linux 发行版最开始使用的是叫作 System V(Sys V)的传统的初始化系统。在过去的几年中,已经发布了好几个初始化系统以解决标准版本中的设计限制,例如:launchd、Service Management Facility、systemd 和 Upstart。

但是 systemd 已经被几个主要的 Linux 发行版所采用,以取代传统的 SysV 初始化系统。

什么是 Upstart?

Upstart 是一个基于事件的 /sbin/init 守护进程的替代品,它在系统启动过程中处理任务和服务的启动,在系统运行期间监视它们,在系统关机的时候关闭它们。

它最初是为 Ubuntu 而设计,但是它也能够完美的部署在其他所有 Linux系统中,用来代替古老的 System-V。

Upstart 被用于 Ubuntu 从 9.10 到 Ubuntu 14.10 和基于 RHEL 6 的系统,之后它被 systemd 取代。

什么是 systemd?

systemd 是一个新的初始化系统和系统管理器,它被用于所有主要的 Linux 发行版,以取代传统的 SysV 初始化系统。

systemd 兼容 SysV 和 LSB 初始化脚本。它可以直接替代 SysV 初始化系统。systemd 是被内核启动的第一个程序,它的 PID 是 1。

systemd 是所有程序的父进程,Fedora 15 是第一个用 systemd 取代 upstart 的发行版。systemctl 用于命令行,它是管理 systemd 的守护进程/服务的主要工具,例如:(开启、重启、关闭、启用、禁用、重载和状态)

systemd 使用 .service 文件而不是 bash 脚本(SysVinit 使用的)。systemd 将所有守护进程添加到 cgroups 中排序,你可以通过浏览 /cgroup/systemd 文件查看系统等级。

如何使用 chkconfig 命令启用或禁用引导服务?

chkconfig 实用程序是一个命令行工具,允许你在指定运行级别下启动所选服务,以及列出所有可用服务及其当前设置。

此外,它还允许我们从启动中启用或禁用服务。前提是你有超级管理员权限(root 或者 sudo)运行这个命令。

所有的服务脚本位于 /etc/rd.d/init.d文件中

如何列出运行级别中所有的服务

--list 参数会展示所有的服务及其当前状态(启用或禁用服务的运行级别):

# chkconfig --list
NetworkManager     0:off    1:off    2:on    3:on    4:on    5:on    6:off
abrt-ccpp          0:off    1:off    2:off    3:on    4:off    5:on    6:off
abrtd              0:off    1:off    2:off    3:on    4:off    5:on    6:off
acpid              0:off    1:off    2:on    3:on    4:on    5:on    6:off
atd                0:off    1:off    2:off    3:on    4:on    5:on    6:off
auditd             0:off    1:off    2:on    3:on    4:on    5:on    6:off
.
.

如何查看指定服务的状态

如果你想查看运行级别下某个服务的状态,你可以使用下面的格式匹配出需要的服务。

比如说我想查看运行级别中 auditd 服务的状态

# chkconfig --list| grep auditd
auditd             0:off    1:off    2:on    3:on    4:on    5:on    6:off

如何在指定运行级别中启用服务

使用 --level 参数启用指定运行级别下的某个服务,下面展示如何在运行级别 3 和运行级别 5 下启用 httpd 服务。

# chkconfig --level 35 httpd on

如何在指定运行级别下禁用服务

同样使用 --level 参数禁用指定运行级别下的服务,下面展示的是在运行级别 3 和运行级别 5 中禁用 httpd 服务。

# chkconfig --level 35 httpd off

如何将一个新服务添加到启动列表中

-–add 参数允许我们添加任何新的服务到启动列表中,默认情况下,新添加的服务会在运行级别 2、3、4、5 下自动开启。

# chkconfig --add nagios

如何从启动列表中删除服务

可以使用 --del 参数从启动列表中删除服务,下面展示的是如何从启动列表中删除 Nagios 服务。

# chkconfig --del nagios

如何使用 systemctl 命令启用或禁用开机自启服务?

systemctl 用于命令行,它是一个用来管理 systemd 的守护进程/服务的基础工具,例如:(开启、重启、关闭、启用、禁用、重载和状态)。

所有服务创建的 unit 文件位与 /etc/systemd/system/

如何列出全部的服务

使用下面的命令列出全部的服务(包括启用的和禁用的)。

# systemctl list-unit-files --type=service
UNIT FILE                                     STATE
arp-ethers.service                            disabled
auditd.service                                enabled
[email protected]                               enabled
blk-availability.service                      disabled
brandbot.service                              static
[email protected]                        static
chrony-wait.service                           disabled
chronyd.service                               enabled
cloud-config.service                          enabled
cloud-final.service                           enabled
cloud-init-local.service                      enabled
cloud-init.service                            enabled
console-getty.service                         disabled
console-shell.service                         disabled
[email protected]                      static
cpupower.service                              disabled
crond.service                                 enabled
.
.
150 unit files listed.

使用下面的格式通过正则表达式匹配出你想要查看的服务的当前状态。下面是使用 systemctl 命令查看 httpd 服务的状态。

# systemctl list-unit-files --type=service | grep httpd
httpd.service disabled

如何让指定的服务开机自启

使用下面格式的 systemctl 命令启用一个指定的服务。启用服务将会创建一个符号链接,如下可见:

# systemctl enable httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

运行下列命令再次确认服务是否被启用。

# systemctl is-enabled httpd
enabled

如何禁用指定的服务

运行下面的命令禁用服务将会移除你启用服务时所创建的符号链接。

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

运行下面的命令再次确认服务是否被禁用。

# systemctl is-enabled httpd
disabled

如何查看系统当前的运行级别

使用 systemctl 命令确认你系统当前的运行级别,runlevel 命令仍然可在 systemd 下工作,不过,运行级别对于 systemd 来说是一个历史遗留的概念。所以我建议你全部使用 systemctl 命令。

我们当前处于运行级别 3, 它等同于下面显示的 multi-user.target

# systemctl list-units --type=target
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cloud-config.target   loaded active active Cloud-config availability
cryptsetup.target     loaded active active Local Encrypted Volumes
getty.target          loaded active active Login Prompts
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
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
slices.target         loaded active active Slices
sockets.target        loaded active active Sockets
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
timers.target         loaded active active Timers

via: https://www.2daygeek.com/how-to-enable-or-disable-services-on-boot-in-linux-using-chkconfig-and-systemctl-command/

作者:Prakash Subramanian 选题:lujun9972 译者:way-ww 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出