标签 启动 下的文章

1 开机启动显示的徽标中可隐藏恶意代码

研究人员发现了大量与开机时 UEFI 显示的徽标图像处理有关的漏洞。恶意代码可以通过附加到镜像中的方式在不被察觉的情况下被安装,目前的安全启动机制都无法阻止这种攻击。这个名为 “LogoFAIL” 攻击是由二十几个新发现的漏洞组成的,这些漏洞已经在负责启动运行 Windows 或 Linux 的现代设备的 UEFI 中潜伏了数年甚至数十年,几乎涵盖了整个 x64 和 ARM CPU 生态系统。首先是 UEFI 供应商 AMI、Insyde 和 Phoenix;然后是联想、戴尔和惠普等设备制造商;以及英特尔和 AMD 等 CPU 制造商。LogoFAIL 攻击的是徽标,特别是硬件销售商的徽标,这些徽标会在 UEFI 仍在运行时,在启动时显示在设备屏幕上。这种新的固件攻击几乎影响所有 Windows 和 Linux 设备。

(插图:DA/19aebc9b-a8da-4d5f-a331-c2e8afa300a0)

消息来源:Ars Technica
老王点评:真是想象力丰富,没想到开机显示的徽标也可以隐藏恶意代码。

2 谷歌 Gemini 的早期印象并不好

谷歌本周发布了新的生成式人工智能模型 Gemini,该模型将为包括 Bard 在内的一系列产品和服务提供支持。谷歌对 Gemini 的卓越架构和能力大加吹捧,声称该模型的性能达到或超过了 GPT-4 等其他领先的生成式人工智能模型。但又传闻证据表明并非如此。比如,有人发现该模型未能正确理解基本事实,会弄错 2023 年奥斯卡奖得主。翻译似乎也不是 Gemini Pro 的强项。即便谷歌拥有搜索和新闻网站,但 Gemini Pro 似乎不愿意对可能引起争议的新闻话题发表评论,而是告诉用户……自己谷歌一下。此外,其广泛传播的演示视频被指造假、基准测试有选择性前提。

(插图:DA/ab59690d-fd51-452c-8bca-50c6b93955c4)

消息来源:Tech Crunch
老王点评:LLM 好不好,数据没有用,用户反馈才是真的。这句话不只是对 Gemini 说的。

3 Fedora 40 新增直接启动统一内核镜像的功能

Fedora 40 正在将其对统一内核镜像(UKI)支持推进到下一阶段,将支持直接从 EFI SHIM 启动 UKI 文件的能力,而无需通过 GRUB 等传统的引导加载器。UKI 将带来更好的 UEFI 安全启动支持,更好地支持 TPM 测量和保密计算,以及更强大的启动过程。

(插图:MJ/a99ba7c8-2e9d-43f8-b16e-fbb11f6ae4df)

消息来源:Phoronix
老王点评:可能是我过于守旧了,我既不喜欢 systemd,也不喜欢 UKI、TPM 和安全启动。

systemd 启动过程提供的重要线索可以在问题出现时助你一臂之力。

 title=

在本系列的第一篇文章《学着爱上 systemd》,我考察了 systemd 的功能和架构,以及围绕 systemd 作为古老的 SystemV 初始化程序和启动脚本的替代品的争论。在这第二篇文章中,我将开始探索管理 Linux 启动序列的文件和工具。我会解释 systemd 启动序列、如何更改默认的启动目标(即 SystemV 术语中的运行级别)、以及在不重启的情况下如何手动切换到不同的目标。

我还将考察两个重要的 systemd 工具。第一个 systemctl 命令是和 systemd 交互、向其发送命令的基本方式。第二个是 journalctl,用于访问 systemd 日志,后者包含了大量系统历史数据,比如内核和服务的消息(包括指示性信息和错误信息)。

务必使用一个非生产系统进行本文和后续文章中的测试和实验。你的测试系统需要安装一个 GUI 桌面(比如 Xfce、LXDE、Gnome、KDE 或其他)。

上一篇文章中我写道计划在这篇文章创建一个 systemd 单元并添加到启动序列。由于这篇文章比我预期中要长,这些内容将留到本系列的下一篇文章。

使用 systemd 探索 Linux 的启动

在观察启动序列之前,你需要做几件事情得使引导和启动序列开放可见。正常情况下,大多数发行版使用一个开机动画或者启动画面隐藏 Linux 启动和关机过程中的显示细节,在基于 Red Hat 的发行版中称作 Plymouth 引导画面。这些隐藏的消息能够向寻找信息以排除程序故障、或者只是学习启动序列的系统管理员提供大量有关系统启动和关闭的信息。你可以通过 GRUB( 大统一引导加载器 Grand Unified Boot Loader )配置改变这个设置。

主要的 GRUB 配置文件是 /boot/grub2/grub.cfg ,但是这个文件在更新内核版本时会被覆盖,你不会想修改它的。相反,应该修改用于改变 grub.cfg 默认设置的 /etc/default/grub 文件。

首先看一下当前未修改的 /etc/default/grub 文件的版本:

[root@testvm1 ~]# cd /etc/default ; cat grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_testvm1-swap rd.lvm.
lv=fedora_testvm1/root rd.lvm.lv=fedora_testvm1/swap rd.lvm.lv=fedora_
testvm1/usr rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
[root@testvm1 default]#

GRUB 文档 的第 6 章列出了 /etc/default/grub 文件的所有可用项,我只关注下面的部分:

  • 我将 GRUB 菜单倒计时的秒数 GRUB_TIMEOUT,从 5 改成 10,以便在倒计时达到 0 之前有更多的时间响应 GRUB 菜单。
  • GRUB_CMDLINE_LINUX 列出了引导阶段传递给内核的命令行参数,我删除了其中的最后两个参数。其中的一个参数 rhgb 代表 “ 红帽图形化引导 Red Hat Graphical Boot ”,在内核初始化阶段显示一个小小的 Fedora 图标动画,而不是显示引导阶段的信息。另一个参数 quiet,屏蔽显示记录了启动进度和发生错误的消息。系统管理员需要这些信息,因此我删除了 rhgbquiet。如果引导阶段发生了错误,屏幕上显示的信息可以指向故障的原因。

更改之后,你的 GRUB 文件将会像下面一样:

[root@testvm1 default]# cat grub
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_testvm1-swap rd.lvm.
lv=fedora_testvm1/root rd.lvm.lv=fedora_testvm1/swap rd.lvm.lv=fedora_
testvm1/usr"
GRUB_DISABLE_RECOVERY="false"
[root@testvm1 default]#

grub2-mkconfig 程序使用 /etc/default/grub 文件的内容生成 grub.cfg 配置文件,从而改变一些默认的 GRUB 设置。grub2-mkconfig 输出到 STDOUT,你可以使用程序的 -o 参数指明数据流输出的文件,不过使用重定向也同样简单。执行下面的命令更新 /boot/grub2/grub.cfg 配置文件:

[root@testvm1 grub2]# grub2-mkconfig > /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.9-200.fc28.x86_64
Found initrd image: /boot/initramfs-4.18.9-200.fc28.x86_64.img
Found linux image: /boot/vmlinuz-4.17.14-202.fc28.x86_64
Found initrd image: /boot/initramfs-4.17.14-202.fc28.x86_64.img
Found linux image: /boot/vmlinuz-4.16.3-301.fc28.x86_64
Found initrd image: /boot/initramfs-4.16.3-301.fc28.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504
Found initrd image: /boot/initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img
done
[root@testvm1 grub2]#

重新启动你的测试系统查看本来会隐藏在 Plymouth 开机动画之下的启动信息。但是如果你没有关闭开机动画,又需要查看启动信息的话又该如何操作?或者你关闭了开机动画,而消息流过的速度太快,无法阅读怎么办?(实际情况如此。)

有两个解决方案,都涉及到日志文件和 systemd 日志 —— 两个都是你的好伙伴。你可以使用 less 命令查看 /var/log/messages 文件的内容。这个文件包含引导和启动信息,以及操作系统执行正常操作时生成的信息。你也可以使用不加任何参数的 journalctl 命令查看 systemd 日志,包含基本相同的信息:

[root@testvm1 grub2]# journalctl
-- Logs begin at Sat 2020-01-11 21:48:08 EST, end at Fri 2020-04-03 08:54:30 EDT. --
Jan 11 21:48:08 f31vm.both.org kernel: Linux version 5.3.7-301.fc31.x86_64 ([email protected]) (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)) #1 SMP Mon Oct >
Jan 11 21:48:08 f31vm.both.org kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.7-301.fc31.x86_64 root=/dev/mapper/VG01-root ro resume=/dev/mapper/VG01-swap rd.lvm.lv=VG01/root rd>
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-provided physical RAM map:
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000dffeffff] usable
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000dfff0000-0x00000000dfffffff] ACPI data
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000100000000-0x000000041fffffff] usable
Jan 11 21:48:08 f31vm.both.org kernel: NX (Execute Disable) protection: active
Jan 11 21:48:08 f31vm.both.org kernel: SMBIOS 2.5 present.
Jan 11 21:48:08 f31vm.both.org kernel: DMI: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Jan 11 21:48:08 f31vm.both.org kernel: Hypervisor detected: KVM
Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: cpu 0, msr 30ae01001, primary cpu clock
Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: using sched offset of 8250734066 cycles
Jan 11 21:48:08 f31vm.both.org kernel: clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Jan 11 21:48:08 f31vm.both.org kernel: tsc: Detected 2807.992 MHz processor
Jan 11 21:48:08 f31vm.both.org kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Jan 11 21:48:08 f31vm.both.org kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
<snip>

由于数据流可能长达几十万甚至几百万行,我在这里截断了它。(我的主要工作站上列出的日志长度是 1,188,482 行。)请确保是在你的测试系统尝试的这个命令。如果系统已经运行了一段时间 —— 即使重启过很多次 —— 还是会显示大量的数据。查看这些日志数据,因为它包含了很多信息,在进行问题判断时可能非常有用。了解这个数据文件在正常的引导和启动过程中的模样,可以帮助你在问题出现时定位问题。

我将在本系列之后的文章讨论 systemd 日志、journalctl 命令、以及如何整理输出的日志数据来寻找更详细的信息。

内核被 GRUB 加载到内存后,必须先将自己从压缩后的文件中解压出来,才能执行任何有意义的操作。解压自己后,内核开始运行,加载 systemd 并转交控制权。

引导 boot 阶段到此结束,此时 Linux 内核和 systemd 正在运行,但是无法为用户执行任何生产性任务,因为其他的程序都没有执行,没有命令行解释器提供命令行,没有后台进程管理网络和其他的通信链接,也没有任何东西能够控制计算机执行生产功能。

现在 systemd 可以加载所需的功能性单元以便将系统启动到选择的目标运行状态。

目标

一个 systemd 目标 target 代表一个 Linux 系统当前的或期望的运行状态。与 SystemV 启动脚本十分类似,目标定义了系统运行必须存在的服务,以及处于目标状态下必须激活的服务。图表 1 展示了使用 systemd 的 Linux 系统可能的运行状态目标。就像在本系列的第一篇文章以及 systemd 启动的手册页(man bootup)所看到的一样,有一些开启不同必要服务的其他中间目标,包括 swap.targettimers.targetlocal-fs.target 等。一些目标(像 basic.target)作为检查点使用,在移动到下一个更高级的目标之前保证所有需要的服务已经启动并运行。

除非开机时在 GRUB 菜单进行更改,systemd 总是启动 default.targetdefault.target 文件是指向真实的目标文件的符号链接。对于桌面工作站,default.target 通常是 graphical.target,等同于 SystemV 的运行等级 5。对于服务器,默认目标多半是 multi-user.target,就像 SystemV 的运行等级 3。emergency.target 文件类似单用户模式。目标和 服务 service 都是一种 systemd 单元。

下面的图表,包含在本系列的上一篇文章中,比较了 systemd 目标和古老的 SystemV 启动运行等级。为了向后兼容,systemd 提供了 systemd 目标别名,允许脚本和系统管理员使用像 init 3 一样的 SystemV 命令改变运行等级。当然,SystemV 命令被转发给 systemd 进行解释和执行。

systemd 目标SystemV 运行级别目标别名描述
default.target 这个目标通常是一个符号链接,作为 multi-user.targetgraphical.target 的别名。systemd 总是用 default.target 启动系统。default.target** 不能作为halt.targetpoweroff.targetreboot.target` 的别名。
graphical.target5runlevel5.target带有 GUI 的 multi-user.target
4runlevel4.target未使用。运行等级 4 和 SystemV 的运行等级 3 一致,可以创建这个目标并进行定制,用于启动本地服务,而不必更改默认的 multi-user.target
multi-user.target3runlevel3.target运行所有的服务,但是只有命令行界面(CLI) 。
2runlevel2.target多用户,没有 NFS,但是运行其他所有的非 GUI 服务
rescue.target1runlevel1.target一个基本的系统,包括挂载文件系统,但是只运行最基础的服务,以及一个主控制台上的用于救援的命令行解释器。
emergency.targetS 单用户模式 —— 没有服务运行;文件系统没有挂载。这是最基础级的操作模式,只有一个运行在主控制台的用于紧急情况的命令行解释器,供用户和系统交互。
halt.target 不断电的情况下停止系统
reboot.target6runlevel6.target重启
poweroff.target0runlevel0.target停止系统并关闭电源

每个目标在配置文件中都描述了一组依赖关系。systemd 启动需要的依赖,即 Linux 主机运行在特定功能级别所需的服务。加载目标配置文件中列出的所有依赖并运行后,系统就运行在那个目标等级。如果愿意,你可以在本系列的第一篇文章《学着爱上 systemd》中回顾 systemd 的启动序列和运行时目标。

探索当前的目标

许多 Linux 发行版默认安装一个 GUI 桌面界面,以便安装的系统可以像工作站一样使用。我总是从 Fedora Live USB 引导驱动器安装 Xfce 或 LXDE 桌面。即使是安装一个服务器或者其他基础类型的主机(比如用于路由器和防火墙的主机),我也使用 GUI 桌面的安装方式。

我可以安装一个没有桌面的服务器(数据中心的典型做法),但是这样不满足我的需求。原因不是我需要 GUI 桌面本身,而是 LXDE 安装包含了许多其他默认的服务器安装没有提供的工具,这意味着初始安装之后我需要做的工作更少。

但是,仅仅因为有 GUI 桌面并不意味着我要使用它。我有一个 16 端口的 KVM,可以用于访问我的大部分 Linux 系统的 KVM 接口,但我和它们交互的大部分交互是通过从我的主要工作站建立的远程 SSH 连接。这种方式更安全,而且和 graphical.target 相比,运行 multi-user.target 使用更少的系统资源。

首先,检查默认目标,确认是 graphical.target

[root@testvm1 ~]# systemctl get-default
graphical.target
[root@testvm1 ~]#

然后确认当前正在运行的目标,应该和默认目标相同。你仍可以使用老方法,输出古老的 SystemV 运行等级。注意,前一个运行等级在左边,这里是 N(意思是 None),表示主机启动后没有修改过运行等级。数字 5 是当前的目标,正如古老的 SystemV 术语中的定义:

[root@testvm1 ~]# runlevel
N 5
[root@testvm1 ~]#

注意,runlevel 的手册页指出运行等级已经被淘汰,并提供了一个转换表。

你也可以使用 systemd 方式,命令的输出有很多行,但确实用 systemd 术语提供了答案:

[root@testvm1 ~]# systemctl list-units --type target
UNIT                   LOAD   ACTIVE SUB    DESCRIPTION                
basic.target           loaded active active Basic System              
cryptsetup.target      loaded active active Local Encrypted Volumes    
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.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                    
sshd-keygen.target     loaded active active sshd-keygen.target        
swap.target            loaded active active Swap                      
sysinit.target         loaded active active System Initialization      
timers.target          loaded active active Timers                    

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

21 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

上面列出了当前加载的和激活的目标,你也可以看到 graphical.targetmulti-user.targetmulti-user.target 需要在 graphical.target 之前加载。这个例子中,graphical.target 是激活的。

切换到不同的目标

切换到 multi-user.target 很简单:

[root@testvm1 ~]# systemctl isolate multi-user.target

显示器现在应该从 GUI 桌面或登录界面切换到了一个虚拟控制台。登录并列出当前激活的 systemd 单元,确认 graphical.target 不再运行:

[root@testvm1 ~]# systemctl list-units --type target

务必使用 runlevel 确认命令输出了之前的和当前的“运行等级”:

[root@testvm1 ~]# runlevel
5 3

更改默认目标

现在,将默认目标改为 multi-user.target,以便系统总是启动进入 multi-user.target,从而使用控制台命令行接口而不是 GUI 桌面接口。使用你的测试主机的根用户,切换到保存 systemd 配置的目录,执行一次快速列出操作:

[root@testvm1 ~]# cd /etc/systemd/system/ ; ll
drwxr-xr-x. 2 root root 4096 Apr 25  2018  basic.target.wants
&lt;snip&gt;
lrwxrwxrwx. 1 root root   36 Aug 13 16:23  default.target -> /lib/systemd/system/graphical.target
lrwxrwxrwx. 1 root root   39 Apr 25  2018  display-manager.service -> /usr/lib/systemd/system/lightdm.service
drwxr-xr-x. 2 root root 4096 Apr 25  2018  getty.target.wants
drwxr-xr-x. 2 root root 4096 Aug 18 10:16  graphical.target.wants
drwxr-xr-x. 2 root root 4096 Apr 25  2018  local-fs.target.wants
drwxr-xr-x. 2 root root 4096 Oct 30 16:54  multi-user.target.wants
&lt;snip&gt;
[root@testvm1 system]#

为了强调一些有助于解释 systemd 如何管理启动过程的重要事项,我缩短了这个列表。你应该可以在虚拟机看到完整的目录和链接列表。

default.target 项是指向目录 /lib/systemd/system/graphical.target 的符号链接(软链接),列出那个目录查看目录中的其他内容:

[root@testvm1 system]# ll /lib/systemd/system/ | less

你应该在这个列表中看到文件、目录、以及更多链接,但是专门寻找一下 multi-user.targetgraphical.target。现在列出 default.target(指向 /lib/systemd/system/graphical.target 的链接)的内容:

[root@testvm1 system]# cat default.target
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
[root@testvm1 system]#

graphical.target 文件的这个链接描述了图形用户接口需要的所有必备条件。我会在本系列的下一篇文章至少探讨其中的一些选项。

为了使主机启动到多用户模式,你需要删除已有的链接,创建一个新链接指向正确目标。如果你的 PWD 不是 /etc/systemd/system,切换过去:

[root@testvm1 system]# rm -f default.target
[root@testvm1 system]# ln -s /lib/systemd/system/multi-user.target default.target

列出 default.target 链接,确认其指向了正确的文件:

[root@testvm1 system]# ll default.target
lrwxrwxrwx 1 root root 37 Nov 28 16:08 default.target -&gt; /lib/systemd/system/multi-user.target
[root@testvm1 system]#

如果你的链接看起来不一样,删除并重试。列出 default.target 链接的内容:

[root@testvm1 system]# cat default.target
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
[root@testvm1 system]#

default.target(这里其实是指向 multi-user.target 的链接)其中的 [Unit] 部分现在有不同的必需条件。这个目标不需要有图形显示管理器。

重启,你的虚拟机应该启动到虚拟控制台 1 的控制台登录,虚拟控制台 1 在显示器标识为 tty1。现在你已经知道如何修改默认的目标,使用所需的命令将默认目标改回 graphical.target

首先检查当前的默认目标:

[root@testvm1 ~]# systemctl get-default
multi-user.target
[root@testvm1 ~]# systemctl set-default graphical.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.
[root@testvm1 ~]#

输入下面的命令直接切换到 graphical.target 和显示管理器的登录界面,不需要重启:

[root@testvm1 system]# systemctl isolate default.target

我不清楚为何 systemd 的开发者选择了术语 isolate 作为这个子命令。我的研究表明指的可能是运行指明的目标,但是“隔离”并终结其他所有启动该目标不需要的目标。然而,命令执行的效果是从一个运行的目标切换到另一个——在这个例子中,从多用户目标切换到图形目标。上面的命令等同于 SystemV 启动脚本和 init 程序中古老的 init 5 命令。

登录 GUI 桌面,确认能正常工作。

总结

本文探索了 Linux systemd 启动序列,开始探讨两个重要的 systemd 工具 systemctljournalctl,还说明了如何从一个目标切换到另一个目标,以及如何修改默认目标。

本系列的下一篇文章中将会创建一个新的 systemd 单元,并配置为启动阶段运行。下一篇文章还会查看一些配置选项,可以帮助确定某个特定的单元在序列中启动的位置,比如在网络启动运行后。

资源

关于 systemd 网络上有大量的信息,但大部分都简短生硬、愚钝、甚至令人误解。除了本文提到的资源,下面的网页提供了关于 systemd 启动更详细可靠的信息。

  • Fedora 项目有一个优质实用的 systemd 指南,几乎有你使用 systemd 配置、管理、维护一个 Fedora 计算机需要知道的一切。
  • Fedora 项目还有一个好用的 速查表,交叉引用了古老的 SystemV 命令和对应的 systemd 命令。
  • 要获取 systemd 的详细技术信息和创立的原因,查看 Freedesktop.orgsystemd 描述
  • Linux.com 上“systemd 的更多乐趣”提供了更高级的 systemd 信息和提示

还有一系列针对系统管理员的深层技术文章,由 systemd 的设计者和主要开发者 Lennart Poettering 所作。这些文章写于 2010 年 4 月到 2011 年 9 月之间,但在当下仍然像当时一样有价值。关于 systemd 及其生态的许多其他优秀的作品都是基于这些文章的。


via: https://opensource.com/article/20/5/systemd-startup

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

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

概述你的计算机如何引导和启动一个像 FreeDOS 这样的简单操作系统。

 title=

在使用 DOS 计算机的过程中,我很欣赏的一点是,引导过程相对容易理解。在 DOS 中没有太多的变动组件。而今天,我想和大家分享一下电脑是如何引导和启动像 FreeDOS 这样的简单操作系统的概况。

初始引导

当你打开计算机的电源时,系统会进行一些自我检查,如验证内存和其他组件。这被称为 开机自检 Power On Self Test (POST)。POST 之后,计算机使用一个硬编码指令,告诉它在哪里找到加载操作系统的指令。这就是“ 引导加载程序 boot loader ”,通常它将试图找到硬盘上的 主引导记录 Master Boot Record (MBR)。然后,MBR 加载主操作系统,在这里就是 FreeDOS。

这个定位一个信息以便计算机能够加载操作系统的下一个部分的过程被称为“ 引导 bootstrapping ”,来自于“ 通过你自己的努力振作起来 picking yourself up by your bootstraps ”的古老说法。正是从这个用法中,我们采用了“ 引导 boot ”一词来表示启动你的计算机。

内核

当计算机加载 FreeDOS 内核时,内核所做的第一件事就是识别用户所表示要使用的任何参数。它被保存在一个叫做 FDCONFIG.SYS 的文件中,与内核保存在同一个根目录下。如果 FDCONFIG.SYS 不存在,那么 FreeDOS 的内核就会寻找一个叫做 CONFIG.SYS 的替代文件。

如果你在 20 世纪 80 年代或 90 年代使用过 DOS,你可能对 CONFIG.SYS 文件很熟悉。从 1999 年起,FreeDOS 首先寻找 FDCONFIG.SYS,以防你的 DOS 系统与其他 DOS(如 MS-DOS)做了 双启动。请注意,MS-DOS 只使用 CONFIG.SYS 文件。因此,如果你用同一个硬盘同时启动 FreeDOS 和 MS-DOS,MS-DOS 使用 CONFIG.SYS 来配置自己,而 FreeDOS 则使用 FDCONFIG.SYS。这样一来,双方都可以使用自己的配置。

FDCONFIG.SYS 可以包含一些配置设置,其中之一是 SHELL=SHELLHIGH=。任何一个都会指示内核加载这个程序作为用户的交互式 shell。

如果 FDCONFIG.SYSCONFIG.SYS 都不存在,那么内核就会假定几个默认值,包括在哪里找到 shell。如果你在启动 FreeDOS 系统时看到 “Bad or missing Command Interpreter” 的信息,这意味着 SHELL=SHELLHIGH= 指向了一个在你系统中不存在的 shell 程序。

 title=

你可以通过查看 SHELL=SHELLHIGH= 行来调试这个问题。如果做不到这一点,请确保你在 FreeDOS 系统的根目录下有一个名为 COMMAND.COM 的程序。它就是 shell,我接下来会讲到它。

shell

在 DOS 系统中,“shell” 一词通常是指一个命令行解释器:一个交互式程序,它从用户那里读取指令,然后执行它们。在这里,FreeDOS 的 shell 与 Linux 的 Bash shell 相似。

除非你用 SHELL=SHELLHIGH= 要求内核加载一个不同的 shell,否则 DOS 上的标准命令行 shell 被称为 COMMAND.COM。当 COMMAND.COM 启动时,它也寻找一个文件来配置自己。默认情况下,COMMAND.COM 会在根目录下寻找一个名为 AUTOEXEC.BAT 的文件。AUTOEXEC.BAT 是一个“批处理文件”,它包含一组启动时运行的指令,大致类似于 Linux 上 Bash 启动时读取的 ~/.bashrc “资源文件”。

你可以在 FDCONFIG.SYS 文件中用 SHELL=SHELLHIGH= 改变 shell 以及 shell 的启动文件。FreeDOS 1.3 RC4 安装程序将系统设置为读取 FDAUTO.BAT 而不是 AUTOEXEC.BAT。这与内核读取另一个配置文件的原因相同;你可以在硬盘上用另一个 DOS 双启动 FreeDOS。FreeDOS 将使用 FDAUTO.BAT 而 MS-DOS 将使用 AUTOEXEC.BAT

如果没有像 AUTOEXEC.BAT 这样的启动文件,shell 将简单地提示用户输入日期和时间。

 title=

就是这些了。当 FreeDOS 加载了内核,而内核也加载了 shell,FreeDOS 就准备好让用户输入命令了。

 title=


via: https://opensource.com/article/21/6/freedos-boots

作者:Jim Hall 选题:lujun9972 译者:geekpi 校对:wxy

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

了解 systemd 是怎样决定服务启动顺序,即使它本质上是个并行系统。

 title=

最近在设置 Linux 系统时,我想知道如何确保服务和其他单元的依赖关系在这些依赖于它们的服务和单元启动之前就已经启动并运行了。我需要更多 systemd 如何管理启动程序的相关知识,特别是在本质上是一个并行的系统中如何是决定服务启动顺序的。

你可能知道 SystemV(systemd 的前身,我在这个系列的 第一篇文章 中解释过)通过 Sxx 前缀命名启动脚本来决定启动顺序,xx 是一个 00-99 的数字。然后 SystemV 利用文件名来排序,然后按照所需的运行级别执行队列中每个启动脚本。

但是 systemd 使用单元文件来定义子程序,单元文件可由系统管理员创建或编辑,这些文件不仅可以用于初始化时也可以用于常规操作。在这个系列的 第三篇文章 中,我解释了如何创建一个挂载单元文件。在第五篇文章中,我解释了如何创建一种不同的单元文件 —— 在启动时执行一个程序的服务单元文件。你也可以修改单元文件中某些配置,然后通过 systemd 日志去查看你的修改在启动序列中的位置。

准备工作

先确认你已经在 /etc/default/grub 文件中的 GRUB_CMDLINE_LINUX= 这行移除了 rhgbquiet,如同我在这个系列的 第二篇文章 中展示的那样。这让你能够查看 Linux 启动信息流,你在这篇文章中部分实验中需要用到。

程序

在本教程中,你会创建一个简单的程序让你能够在主控台和后续的 systemd 日志中查看启动时的信息。

创建一个 shell 程序 /usr/local/bin/hello.sh 然后添加下述内容。你要确保执行结果在启动时是可见的,可以轻松的在 systemd 日志中找到它。你会使用一版携带一些方格的 “Hello world” 程序,这样它会非常显眼。为了确保这个文件是可执行的,且为了安全起见,它需要 root 的用户和组所有权和 700 权限

#!/usr/bin/bash
# Simple program to use for testing startup configurations
# with systemd.
# By David Both
# Licensed under GPL V2
#
echo "###############################"
echo "######### Hello World! ########"
echo "###############################"

在命令行中执行这个程序来检查它能否正常运行。

[root@testvm1 ~]# hello.sh
###############################
######### Hello World! ########
###############################
[root@testvm1 ~]#

这个程序可以用任意脚本或编译语言实现。hello.sh 程序可以被放在 Linux 文件系统层级结构(FHS)上的任意位置。我把它放在 /usr/local/bin 目录下,这样它可以直接在命令行中执行而不必在打命令的时候前面带上路径。我发现我创建的很多 shell 程序需要从命令行和其他工具(如 systemd)运行。

服务单元文件

创建服务单元文件 /etc/systemd/system/hello.service,写入下述内容。这个文件不一定是要可执行的,但是为了安全起见,它需要 root 的用户和组所有权和 644640 权限。

# Simple service unit file to use for testing
# startup configurations with systemd.
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=My hello shell script

[Service]
Type=oneshot
ExecStart=/usr/local/bin/hello.sh

[Install]
WantedBy=multi-user.target

通过查看服务状态来确认服务单元文件能如期运行。如有任何语法问题,这里会显示错误。

[root@testvm1 ~]# systemctl status hello.service
● hello.service - My hello shell script
     Loaded: loaded (/etc/systemd/system/hello.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
[root@testvm1 ~]#

你可以运行这类 “oneshot”(单发)类型的服务多次而不会有问题。此类服务适用于服务单元文件启动的程序是主进程,必须在 systemd 启动任何依赖进程之前完成的服务。

共有 7 种服务类型,你可以在 systemd.service(5) 的手册页上找到每一种(以及服务单元文件的其他部分)的详细解释。(你也可以在文章末尾的 资料 中找到更多信息。)

出于好奇,我想看看错误是什么样子的。所以我从 Type=oneshot 这行删了字母 “o”,现在它看起来是这样 Type=neshot,现在再次执行命令:

[root@testvm1 ~]# systemctl status hello.service
● hello.service - My hello shell script
     Loaded: loaded (/etc/systemd/system/hello.service; disabled; vendor preset: disabled)
     Active: inactive (dead)

May 06 08:50:09 testvm1.both.org systemd[1]: /etc/systemd/system/hello.service:12: Failed to parse service type, ignoring: neshot
[root@testvm1 ~]#

执行结果明确地告诉我错误在哪,这样解决错误变得十分容易。

需要注意的是即使在你将 hello.service 文件保存为它原来的形式之后,错误依然存在。虽然重启机器能消除这个错误,但你不必这么做,所以我去找了一个清理这类持久性错误的方法。我曾遇到有些错误需要 systemctl daemon-reload 命令来重置错误状态,但是在这个例子里不起作用。可以用这个命令修复的错误似乎总是有一个这样的声明,所以你知道要运行它。

然而,每次修改或新建一个单元文件之后执行 systemctl daemon-reload 确实是值得推荐的做法。它提醒 systemd 有修改发生,而且它可以防止某些与管理服务或单元相关的问题。所以继续去执行这条命令吧。

在修改完服务单元文件中的拼写错误后,一个简单的 systemctl restart hello.service 命令就可以清除错误。实验一下,通过添加一些其他的错误至 hello.service 文件来看看会得到怎样的结果。

启动服务

现在你已经准备好启动这个新服务,通过检查状态来查看结果。尽管你可能之前已经重启过,你仍然可以启动或重启这个单发服务任意次,因为它只运行一次就退出了。

继续启动这个服务(如下所示),然后检查状态。你的结果可能和我的有区别,取决于你做了多少试错实验。

[root@testvm1 ~]# systemctl start hello.service
[root@testvm1 ~]# systemctl status hello.service
● hello.service - My hello shell script
     Loaded: loaded (/etc/systemd/system/hello.service; disabled; vendor preset: disabled)
     Active: inactive (dead)

May 10 10:37:49 testvm1.both.org hello.sh[842]: ######### Hello World! ########
May 10 10:37:49 testvm1.both.org hello.sh[842]: ###############################
May 10 10:37:49 testvm1.both.org systemd[1]: hello.service: Succeeded.
May 10 10:37:49 testvm1.both.org systemd[1]: Finished My hello shell script.
May 10 10:54:45 testvm1.both.org systemd[1]: Starting My hello shell script...
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
May 10 10:54:45 testvm1.both.org systemd[1]: hello.service: Succeeded.
May 10 10:54:45 testvm1.both.org systemd[1]: Finished My hello shell script.
[root@testvm1 ~]#

从状态检查命令的输出中我们可以看到,systemd 日志表明 hello.sh 启动然后服务结束了。你也可以看到脚本的输出。该输出是根据服务的最近调用的日志记录生成的,试试看多启动几次这个服务,然后再看状态命令的输出就能理解我所说的。

你也应该直接查看日志内容,有很多种方法可以实现。一种办法是指定记录类型标识符,在这个例子中就是 shell 脚本的名字。它会展示前几次重启和当前会话的日志记录。如你所见,我已经为这篇文章做了挺长一段时间的研究测试了。

[root@testvm1 ~]# journalctl -t hello.sh
<剪去>
-- Reboot --
May 08 15:55:47 testvm1.both.org hello.sh[840]: ###############################
May 08 15:55:47 testvm1.both.org hello.sh[840]: ######### Hello World! ########
May 08 15:55:47 testvm1.both.org hello.sh[840]: ###############################
-- Reboot --
May 08 16:01:51 testvm1.both.org hello.sh[840]: ###############################
May 08 16:01:51 testvm1.both.org hello.sh[840]: ######### Hello World! ########
May 08 16:01:51 testvm1.both.org hello.sh[840]: ###############################
-- Reboot --
May 10 10:37:49 testvm1.both.org hello.sh[842]: ###############################
May 10 10:37:49 testvm1.both.org hello.sh[842]: ######### Hello World! ########
May 10 10:37:49 testvm1.both.org hello.sh[842]: ###############################
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
[root@testvm1 ~]#

为了定位 hello.service 单元的 systemd 记录,你可以在 systemd 中搜索。你可以使用 G+Enter 来翻页到日志记录 记录的末尾,然后用回滚来找到你感兴趣的日志。使用 -b 选项仅展示最近启动的记录。

[root@testvm1 ~]# journalctl -b -t systemd
<剪去>
May 10 10:37:49 testvm1.both.org systemd[1]: Starting SYSV: Late init script for live image....
May 10 10:37:49 testvm1.both.org systemd[1]: Started SYSV: Late init script for live image..
May 10 10:37:49 testvm1.both.org systemd[1]: hello.service: Succeeded.
May 10 10:37:49 testvm1.both.org systemd[1]: Finished My hello shell script.
May 10 10:37:50 testvm1.both.org systemd[1]: Starting D-Bus System Message Bus...
May 10 10:37:50 testvm1.both.org systemd[1]: Started D-Bus System Message Bus.

我拷贝了一些其他的日志记录,让你对你可能找到的东西有所了解。这条命令喷出了所有属于 systemd 的日志内容 —— 当我写这篇时是 109183 行。这是一个需要整理的大量数据。你可以使用页面的搜索功能,通常是 less 或者你可以使用内置的 grep 特性。-g( 或 --grep=)选项可以使用兼容 Perl 的正则表达式。

[root@testvm1 ~]# journalctl -b -t systemd -g "hello"
[root@testvm1 ~]# journalctl -b -t systemd -g "hello"
-- Logs begin at Tue 2020-05-05 18:11:49 EDT, end at Sun 2020-05-10 11:01:01 EDT. --
May 10 10:37:49 testvm1.both.org systemd[1]: Starting My hello shell script...
May 10 10:37:49 testvm1.both.org systemd[1]: hello.service: Succeeded.
May 10 10:37:49 testvm1.both.org systemd[1]: Finished My hello shell script.
May 10 10:54:45 testvm1.both.org systemd[1]: Starting My hello shell script...
May 10 10:54:45 testvm1.both.org systemd[1]: hello.service: Succeeded.
May 10 10:54:45 testvm1.both.org systemd[1]: Finished My hello shell script.
[root@testvm1 ~]#

你可以使用标准的 GNU grep 命令,但是这不会展示日志首行的元数据。

如果你只想看包含你的 hello 服务的日志记录,你可以指定时间来缩小范围。举个例子,我将在我的测试虚拟机上以 10:54:00 为开始时间,这是上述的日志记录开始的分钟数。注意 --since= 的选项必须加引号,这个选项也可以写成 -S "某个时间"

日期和时间可能在你的机器上有所不同,所以确保使用能匹配你日志中的时间的时间戳。

[root@testvm1 ~]# journalctl --since="2020-05-10 10:54:00"
May 10 10:54:35 testvm1.both.org audit: BPF prog-id=54 op=LOAD
May 10 10:54:35 testvm1.both.org audit: BPF prog-id=55 op=LOAD
May 10 10:54:45 testvm1.both.org systemd[1]: Starting My hello shell script...
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
May 10 10:54:45 testvm1.both.org systemd[1]: hello.service: Succeeded.
May 10 10:54:45 testvm1.both.org systemd[1]: Finished My hello shell script.
May 10 10:54:45 testvm1.both.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd"'
May 10 10:54:45 testvm1.both.org audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd/"'
May 10 10:56:00 testvm1.both.org NetworkManager[840]: <error> [1589122560.0633] dhcp4 (enp0s3): error -113 dispatching events
May 10 10:56:00 testvm1.both.org NetworkManager[840]: <info>  [1589122560.0634] dhcp4 (enp0s3): state changed bound -> fail
<剪去>

since 选项跳过了指定时间点的所有记录,但在此时间点之后仍有大量你不需要的记录。你也可以使用 until 选项来裁剪掉你感兴趣的时间之后的记录。我想要事件发生时附近的一分钟,其他的都不用:

[root@testvm1 ~]# journalctl --since="2020-05-10 10:54:35" --until="2020-05-10 10:55:00"
-- Logs begin at Tue 2020-05-05 18:11:49 EDT, end at Sun 2020-05-10 11:04:59 EDT. --
May 10 10:54:35 testvm1.both.org systemd[1]: Reloading.
May 10 10:54:35 testvm1.both.org audit: BPF prog-id=27 op=UNLOAD
May 10 10:54:35 testvm1.both.org audit: BPF prog-id=26 op=UNLOAD
<剪去>
ay 10 10:54:35 testvm1.both.org audit: BPF prog-id=55 op=LOAD
May 10 10:54:45 testvm1.both.org systemd[1]: Starting My hello shell script...
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
May 10 10:54:45 testvm1.both.org systemd[1]: hello.service: Succeeded.
May 10 10:54:45 testvm1.both.org systemd[1]: Finished My hello shell script.
May 10 10:54:45 testvm1.both.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd>
May 10 10:54:45 testvm1.both.org audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd/>
lines 1-46/46 (END)

如果在这个时间段中仍然有大量的活动的话,你可以使用这些选项组合来进一步缩小结果数据流:

[root@testvm1 ~]# journalctl --since="2020-05-10 10:54:35" --until="2020-05-10 10:55:00" -t "hello.sh"
-- Logs begin at Tue 2020-05-05 18:11:49 EDT, end at Sun 2020-05-10 11:10:41 EDT. --
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ######### Hello World! ########
May 10 10:54:45 testvm1.both.org hello.sh[1380]: ###############################
[root@testvm1 ~]#

你的结果应该与我的相似。你可以从这一系列的实验中看出,这个服务运行的很正常。

重启 —— 还是走到这一步

到目前为止,你还没有重启过安装了服务的机器。所以现在重启吧,因为毕竟这个教程是关于启动阶段程序运行的情况。首先,你需要在启动序列中启用这个服务。

[root@testvm1 ~]# systemctl enable hello.service
Created symlink /etc/systemd/system/multi-user.target.wants/hello.service → /etc/systemd/system/hello.service.
[root@testvm1 ~]#

注意到这个软链接是被创建在 /etc/systemd/system/multi-user.target.wants 目录下的。这是因为服务单元文件指定了服务是被 multi-user.target 所“需要”的。

重启机器,确保能在启动阶段观察数据流,这样你能看到 “Hello world” 信息。等等……你看见了么?嗯,我看见了。尽管它很快被刷过去了,但是我确实看到 systemd 的信息显示它启动了 hello.service 服务。

看看上次系统启动后的日志。你可以使用页面搜索工具 less 来找到 “Hello” 或 “hello”。我裁剪了很多数据,但是留下了附近的日志记录,这样你就能感受到和你服务有关的日志记录在本地是什么样子的:

[root@testvm1 ~]# journalctl -b
<剪去>
May 10 10:37:49 testvm1.both.org systemd[1]: Listening on SSSD Kerberos Cache Manager responder socket.
May 10 10:37:49 testvm1.both.org systemd[1]: Reached target Sockets.
May 10 10:37:49 testvm1.both.org systemd[1]: Reached target Basic System.
May 10 10:37:49 testvm1.both.org systemd[1]: Starting Modem Manager...
May 10 10:37:49 testvm1.both.org systemd[1]: Starting Network Manager...
May 10 10:37:49 testvm1.both.org systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
May 10 10:37:49 testvm1.both.org systemd[1]: Condition check resulted in Secure Boot DBX (blacklist) updater being skipped.
May 10 10:37:49 testvm1.both.org systemd[1]: Starting My hello shell script...
May 10 10:37:49 testvm1.both.org systemd[1]: Starting IPv4 firewall with iptables...
May 10 10:37:49 testvm1.both.org systemd[1]: Started irqbalance daemon.
May 10 10:37:49 testvm1.both.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=irqbalance comm="systemd" exe="/usr/lib/sy>"'
May 10 10:37:49 testvm1.both.org systemd[1]: Starting LSB: Init script for live image....
May 10 10:37:49 testvm1.both.org systemd[1]: Starting Hardware Monitoring Sensors...
<剪去>
May 10 10:37:49 testvm1.both.org systemd[1]: Starting NTP client/server...
May 10 10:37:49 testvm1.both.org systemd[1]: Starting SYSV: Late init script for live image....
May 10 10:37:49 testvm1.both.org systemd[1]: Started SYSV: Late init script for live image..
May 10 10:37:49 testvm1.both.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=livesys-late comm="systemd" exe="/usr/lib/>"'
May 10 10:37:49 testvm1.both.org hello.sh[842]: ###############################
May 10 10:37:49 testvm1.both.org hello.sh[842]: ######### Hello World! ########
May 10 10:37:49 testvm1.both.org hello.sh[842]: ###############################
May 10 10:37:49 testvm1.both.org systemd[1]: hello.service: Succeeded.
May 10 10:37:49 testvm1.both.org systemd[1]: Finished My hello shell script.
May 10 10:37:49 testvm1.both.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd>"'
May 10 10:37:49 testvm1.both.org audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd/>
May 10 10:37:50 testvm1.both.org audit: BPF prog-id=28 op=LOAD
<剪去>

你可以看到 systemd 启动了 hello.service 单元,它执行了 hello.sh 脚本并将输出记录在日志中。如果你能在启动阶段抓到它,你也应该能看见,systemd 信息表明了它正在启动这个脚本,另外一条信息表明了服务成功。通过观察上面数据流中第一条 systemd 消息,你会发现 systemd 在到达基本的系统目标后很快就启动了你的服务。

但是我想看见信息在启动阶段也被打印出来。有一种方法可以做到:在 hello.service 文件的 [Service] 段中加入下述行:

StandardOutput=journal+console

现在 hello.service 文件看起来像这样:

# Simple service unit file to use for testing
# startup configurations with systemd.
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=My hello shell script

[Service]
Type=oneshot
ExecStart=/usr/local/bin/hello.sh
StandardOutput=journal+console

[Install]
WantedBy=multi-user.target

加上这一行后,重启系统,并在启动过程中观察显示屏上滚动的数据流。你应该在它的小方框中看到信息。在启动序列完成后,你可以查看最近的启动日志,然后定位到你新服务的日志记录。

修改次序

现在你的服务已经可用了,你可以看看它在启动序列中哪个位置启动的,尝试下修改它。需要牢记的是 systemd 倾向于在每个主要目标(basic.targetmulti-user.targetgraphical.**target)中并行启动尽可能多的服务和其他的单元类型。你应该刚刚看过最近一次开机的日志记录,它应该和上面我的日志看上去类似。

注意,systemd 在它到达到基本系统目标(basic.target)后不久就启动了你的测试服务。这正是你在在服务单元文件的 WantedBy 行中指定的,所以它是对的。在你做出修改之前,列出 /etc/systemd/system/multi-user.target.wants 目录下的内容,你会看到一个指向服务单元文件的软链接。服务单元文件的 [Install] 段指定了哪一个目标会启动这个服务,执行 systemctl enable hello.service 命令会在适当的 targets.wants 路径下创建软链接。

hello.service -> /etc/systemd/system/hello.service

某些服务需要在 basic.target 阶段启动,其他则没这个必要,除非系统正在启动 graphical.target。这个实验中的服务不会在 basic.target 期间启动 —— 假设你直到 graphical.target 阶段才需要它启动。那么修改 WantedBy 这一行:

WantedBy=graphical.target

一定要先禁用 hello.service 再重新启用它,这样可以删除旧链接并且在 graphical.targets.wants 目录下创建一个新的链接。我注意到如果我在修改服务需要的目标之前忘记禁用该服务,我可以运行 systemctl disable 命令,链接将从两个 targets.wants 目录中删除。之后我只需要重新启用这个服务然后重启电脑。

启动 graphical.target 下的服务有个需要注意的地方,如果电脑启动到 multi-user.target 阶段,这个服务不会自动启动。如果这个服务需要 GUI 桌面接口,这或许是你想要的,但是它同样可能不是你想要的。

-o short-monotonic 选项来查看 graphical.targetmulti-user.target 的日志,展示内核启动几秒后的日志,精度为微秒级别:

[root@testvm1 ~]# journalctl -b -o short-monotonic

multi-user.target 的部分日志:

[   17.264730] testvm1.both.org systemd[1]: Starting My hello shell script...
[   17.265561] testvm1.both.org systemd[1]: Starting IPv4 firewall with iptables...
<剪去>
[   19.478468] testvm1.both.org systemd[1]: Starting LSB: Init script for live image....
[   19.507359] testvm1.both.org iptables.init[844]: iptables: Applying firewall rules: [  OK  ]
[   19.507835] testvm1.both.org hello.sh[843]: ###############################
[   19.507835] testvm1.both.org hello.sh[843]: ######### Hello World! ########
[   19.507835] testvm1.both.org hello.sh[843]: ###############################
<剪去>
[   21.482481] testvm1.both.org systemd[1]: hello.service: Succeeded.
[   21.482550] testvm1.both.org smartd[856]: Opened configuration file /etc/smartmontools/smartd.conf
[   21.482605] testvm1.both.org systemd[1]: Finished My hello shell script.

还有部分 graphical.target 的日志:

[   19.436815] testvm1.both.org systemd[1]: Starting My hello shell script...
[   19.437070] testvm1.both.org systemd[1]: Starting IPv4 firewall with iptables...
<剪去>
[   19.612614] testvm1.both.org hello.sh[841]: ###############################
[   19.612614] testvm1.both.org hello.sh[841]: ######### Hello World! ########
[   19.612614] testvm1.both.org hello.sh[841]: ###############################
[   19.629455] testvm1.both.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   19.629569] testvm1.both.org audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   19.629682] testvm1.both.org systemd[1]: hello.service: Succeeded.
[   19.629782] testvm1.both.org systemd[1]: Finished My hello shell script.

尽管单元文件的 WantedBy 部分包含了 graphical.targethello.service 单元在启动后大约 19.5 或 19.6 秒后运行。但是 hello.servicemulti-user.target 中开始于 17.24 秒,在 graphical target 中开始于 19.43 秒。

这意味着什么呢?看看 /etc/systemd/system/default.target 这个链接。文件内容显示 systemd 先启动了默认目标 graphical.target,然后 graphical.target 触发了 multi-user.target

[root@testvm1 system]# cat default.target
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
[root@testvm1 system]#

不管是用 graphical.target 还是 multi-user.target 启动服务,hello.service 单元都在启动后的 19.5 或 19.6 秒后启动。基于这个事实和日志结果(特别是使用单调输出的日志),你就知道这些目标是在并行启动。再看看日志中另外一件事:

[   28.397330] testvm1.both.org systemd[1]: Reached target Multi-User System.
[   28.397431] testvm1.both.org systemd[1]: Reached target Graphical Interface.

两个目标几乎是同时完成的。这是和理论一致的,因为 graphical.target 触发了 multi-user.target,在 multi-user.target 到达(即完成)之前它是不会完成的。但是 hello.service 比这个完成的早的多。

这一切表明,这两个目标几乎是并行启动的。如果你查看日志,你会发现各种目标和来自这类主要目标的服务大多是平行启动的。很明显,multi-user.target 没有必要在 graphical.target 启动前完成。所以,简单的使用这些主要目标来并不能很好地排序启动序列,尽管它在保证单元只在它们被 graphical.target 需要时启动这方面很有用。

在继续之前,把 hello.service 单元文件回滚至 WantedBy=multi-user.target(如果还没做的话)。

确保一个服务在网络运行后启动

一个常见的启动问题是保证一个单元在网络启动运行后再启动。Freedesktop.org 的文章《在网络启动后运行服务》中提到,目前没有一个真正的关于网络何时算作“启动”的共识。然而,这篇文章提供了三个选项,满足完全可用网络需求的是 network-online.target。需要注意的是 network.target 是在关机阶段使用的而不是启动阶段,所以它对你做有序启动方面没什么帮助。

在做出任何改变之前,一定要检查下日志,确认 hello.service 单元在网络可用之前可以正确启动。你可以在日志中查找 network-online.target 来确认。

你的服务并不真的需要网络服务,但是你可以把它当作是需要网络的。

因为设置 WantedBy=graphical.target 并不能保证服务会在网络启动可用后启动,所以你需要其他的方法来做到这一点。幸运的是,有个简单的方法可以做到。将下面两行代码加入 hello.service 单元文件的 [Unit] 段:

After=network-online.target                                                                            
Wants=network-online.target

两个字段都需要才能生效。重启机器,在日志中找到服务的记录:

[   26.083121] testvm1.both.org NetworkManager[842]: <info>  [1589227764.0293] device (enp0s3): Activation: successful, device activated.
[   26.083349] testvm1.both.org NetworkManager[842]: <info>  [1589227764.0301] manager: NetworkManager state is now CONNECTED_GLOBAL
[   26.085818] testvm1.both.org NetworkManager[842]: <info>  [1589227764.0331] manager: startup complete
[   26.089911] testvm1.both.org systemd[1]: Finished Network Manager Wait Online.
[   26.090254] testvm1.both.org systemd[1]: Reached target Network is Online.
[   26.090399] testvm1.both.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-wait-online comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? termina>"'
[   26.091991] testvm1.both.org systemd[1]: Starting My hello shell script...
[   26.095864] testvm1.both.org sssd[be[implicit_files]][1007]: Starting up
[   26.290539] testvm1.both.org systemd[1]: Condition check resulted in Login and scanning of iSCSI devices being skipped.
[   26.291075] testvm1.both.org systemd[1]: Reached target Remote File Systems (Pre).
[   26.291154] testvm1.both.org systemd[1]: Reached target Remote File Systems.
[   26.292671] testvm1.both.org systemd[1]: Starting Notify NFS peers of a restart...
[   26.294897] testvm1.both.org systemd[1]: iscsi.service: Unit cannot be reloaded because it is inactive.
[   26.304682] testvm1.both.org hello.sh[1010]: ###############################
[   26.304682] testvm1.both.org hello.sh[1010]: ######### Hello World! ########
[   26.304682] testvm1.both.org hello.sh[1010]: ###############################
[   26.306569] testvm1.both.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   26.306669] testvm1.both.org audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=hello comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   26.306772] testvm1.both.org systemd[1]: hello.service: Succeeded.
[   26.306862] testvm1.both.org systemd[1]: Finished My hello shell script.
[   26.584966] testvm1.both.org sm-notify[1011]: Version 2.4.3 starting

这样证实了 hello.service 单元会在 network-online.target 之后启动。这正是你想要的。你可能也看见了 “Hello World” 消息在启动阶段出现。还需要注意的是,在启动时记录出现的时间戳比之前要晚了大约 6 秒。

定义启动序列的最好方法

本文章详细地探讨了 Linux 启动时 systemd 和单元文件以及日志的细节,并且发现了当错误被引入单元文件时候会发生什么。作为系统管理员,我发现这类实验有助于我理解程序或者服务出故障时的行为,并且在安全环境中有意破坏是一种学习的好方法。

文章中实验结果证明,仅将服务单元添加至 multi-user.target 或者 graphical.target 并不能确定它在启动序列中的位置。它仅仅决定了一个单元是否作为图形环境一部分启动。事实上,启动目标 multi-user.targetgraphical.target 和所有它们的 Wants 以及 Required 几乎是并行启动的。确保单元在特定位置启动的最好方法是确定它所依赖的单元,并将新单元配置成 WantAfter 它的依赖。

资源

网上有大量的关于 systemd 的参考资料,但是大部分都有点简略、晦涩甚至有误导性。除了本文中提到的资料,下列的网页提供了跟多可靠且详细的 systemd 入门信息。

Fedora 项目有一篇切实好用的 systemd 入门,它囊括了几乎所有你需要知道的关于如何使用 systemd 配置、管理和维护 Fedora 计算机的信息。

Fedora 项目也有一个不错的 备忘录,交叉引用了过去 SystemV 命令和 systemd 命令做对比。

关于 systemd 的技术细节和创建这个项目的原因,请查看 Freedesktop.org 上的 systemd 描述。

Linux.com 的“更多 systemd 的乐趣”栏目提供了更多高级的 systemd 信息和技巧。

此外,还有一系列深度的技术文章,是由 systemd 的设计者和主要开发者 Lennart Poettering 为 Linux 系统管理员撰写的。这些文章写于 2010 年 4 月至 2011 年 9 月间,但它们现在和当时一样具有现实意义。关于 systemd 及其生态的许多其他好文章都是基于这些文章:


via: https://opensource.com/article/20/5/manage-startup-systemd

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

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

用 Ventoy 创建多启动 U 盘,你将永远不会缺少自己喜欢的 Linux 发行版。

 title=

给朋友和邻居一个可启动 U 盘,里面包含你最喜欢的 Linux 发行版,是向 Linux 新手介绍我们都喜欢的 Linux 体验的好方法。仍然有许多人从未听说过 Linux,把你喜欢的发行版放在一个可启动的 U 盘上是让他们进入 Linux 世界的好办法。

几年前,我在给一群中学生教授计算机入门课。我们使用旧笔记本电脑,我向学生们介绍了 Fedora、Ubuntu 和 Pop!\_OS。下课后,我给每个学生一份他们喜欢的发行版的副本,让他们带回家安装在自己选择的电脑上。他们渴望在家里尝试他们的新技能。

把多个发行版放在一个驱动器上

最近,一个朋友向我介绍了 Ventoy,它(根据其 GitHub 仓库)是 “一个开源工具,可以为 ISO/WIM/IMG/VHD(x)/EFI 文件创建可启动的 USB 驱动器”。与其为每个我想分享的 Linux 发行版创建单独的驱动器,我可以在一个 U 盘上放入我喜欢的 所有 Linux 发行版!

 title=

正如你所能想到的那样,U 盘的大小决定了你能在上面容纳多少个发行版。在一个 16GB 的 U 盘上,我放置了 Elementary 5.1、Linux Mint Cinnamon 5.1 和 Linux Mint XFCE 5.1......但仍然有 9.9GB 的空间。

获取 Ventoy

Ventoy 是开源的,采用 GPLv3 许可证,可用于 Windows 和 Linux。有很好的文档介绍了如何在 Windows 上下载和安装 Ventoy。Linux 的安装是通过命令行进行的,所以如果你不熟悉这个过程,可能会有点混乱。然而,其实很容易。

首先,下载 Ventoy。我把存档文件下载到我的桌面上。

接下来,使用 tar 命令解压 ventoy-x.y.z-linux.tar.gz 档案(但要用你下载的版本号替换 x.y.z)(为了保持简单,我在命令中使用 * 字符作为任意通配符):

$ tar -xvf ventoy*z

这个命令将所有必要的文件提取到我桌面上一个名为 ventoy-x.y.z 的文件夹中。

你也可以使用你的 Linux 发行版的存档管理器来完成同样的任务。下载和提取完成后,你就可以把 Ventoy 安装到你的 U 盘上了。

在 U 盘上安装 Ventoy 和 Linux

把你的 U 盘插入你的电脑。改变目录进入 Ventoy 的文件夹,并寻找一个名为 Ventoy2Disk.sh 的 shell 脚本。你需要确定你的 U 盘的正确挂载点,以便这个脚本能够正常工作。你可以通过在命令行上发出 mount 命令或者使用 GNOME 磁盘 来找到它,后者提供了一个图形界面。后者显示我的 U 盘被挂载在 /dev/sda。在你的电脑上,这个位置可能是 /dev/sdb/dev/sdc 或类似的位置。

 title=

下一步是执行 Ventoy shell 脚本。因为它被设计成不加选择地复制数据到一个驱动器上,我使用了一个假的位置(/dev/sdX)来防止你复制/粘贴错误,所以用你想覆盖的实际驱动器的字母替换后面的 X

让我重申:这个 shell 脚本的目的是把数据复制到一个驱动器上, 破坏该驱动器上的所有数据。 如果该驱动器上有你关心的数据,在尝试这个方法之前,先把它备份! 如果你不确定你的驱动器的位置,在你继续进行之前,请验证它,直到你完全确定为止。

一旦你确定了你的驱动器的位置,就运行这个脚本:

$ sudo sh Ventoy2Disk.sh -i /dev/sdX

这样就可以格式化它并将 Ventoy 安装到你的 U 盘上。现在你可以复制和粘贴所有适合放在 U 盘上的 Linux 发行版文件。如果你在电脑上用新创建的 U 盘引导,你会看到一个菜单,上面有你复制到 U 盘上的发行版。

 title=

构建一个便携式的动力源

Ventoy 是你在钥匙串上携带多启动 U 盘的关键(钥匙),这样你就永远不会缺少你所依赖的发行版。你可以拥有一个全功能的桌面、一个轻量级的发行版、一个纯控制台的维护工具,以及其他你想要的东西。

我从来没有在没有 Linux 发行版的情况下离开家,你也不应该。拿上 Ventoy、一个 U 盘,和一串 ISO。你不会后悔的。


via: https://opensource.com/article/21/5/linux-ventoy

作者:Don Watkins 选题:lujun9972 译者:wxy 校对:wxy

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

众所周知 Linux 可以在启动时添加服务。例如,如果要在启动时添加 Apache Httpd 服务,你可以在 chkconfigsystemctl 命令的帮助下完成此操作。

有时你需要在启动时添加自定义脚本、命令或服务,该怎么做?你可以使用以下三种方法来做到。

在本文中,我们将通过示例向你展示如何使用这些方法。

方法 1:如何使用 /etc/rc.d/rc.local 文件在重启或启动时运行脚本或命令

传统上,/etc/rc.local 文件是在切换到多用户运行级别的过程结束时,在所有正常的计算机服务启动之后执行的。

此方法也适用于 systemd 系统。

你需要将你的脚本位置添加到 /etc/rc.d/rc.local 文件中以在启动时运行。

确保该文件有运行权限:

# chmod +x /etc/rc.d/rc.local

作为演示,我们将创建一个简单的示例脚本。你可以根据需要创建任何脚本。

# vi /opt/scripts/run-script-on-boot.sh

#!/bin/bash
date > /root/on-boot-output.txt
hostname >> /root/on-boot-output.txt

脚本完成后,设置可执行权限:

# chmod +x /opt/scripts/run-script-on-boot.sh

最后,将该脚本添加到文件底部:

# vi /etc/rc.d/rc.local

/opt/scripts/run-script-on-boot.sh

重启系统进行检查:

# reboot

方法 2:如何使用 crontab 在重启或启动时执行命令或脚本

cron 在特定时间在后台自动执行计划的作业。可以在 cron 任务中使用特殊的字符串 @reboot 来完成。@reboot 是一个特殊的字符串,它允许用户在启动时运行任何命令或脚本。

此示例在系统重启时运行 /opt/scripts/run-script-on-boot.sh 文件。我们将使用与上面相同的脚本。

为此,只需在 crontab 文件中添加以下条目:

# crontab -e

@reboot /opt/scripts/run-script-on-boot.sh

重启系统进行检查:

# reboot

方法 3:如何使用 systemd 服务单元在重启或启动时运行命令或脚本

此方法仅适用于 systemd 系统。该方法非常简单。

我们将使用上面相同的脚本进行演示。

为此,你需要创建一个 systemd 启动脚本并将其放在 /etc/systemd/system/ 目录中。

这是我们的示例 systemd 启动单元脚本:

# vi sample-on-boot-script.service

[Unit]
Description=Run a Custom Script at Startup
After=default.target

[Service]
ExecStart=/opt/scripts/run-script-on-boot.sh

[Install]
WantedBy=default.target

将单元脚本放置在 systemd 所在位置后,运行以下命令更新 systemd 配置文件并启用服务:

# systemctl daemon-reload
# systemctl enable sample-on-boot-script.service

重启系统进行检查:

# reboot

额外提示

如果你想在后台运行脚本,你需要在最后加上 & 符号

/Path/To/My_Script &

如果你想以不同用户运行命令,使用以下格式:

su - $USER -c /Path/To/My_Script

via: https://www.2daygeek.com/execute-run-linux-scripts-command-at-reboot-startup/

作者:Magesh Maruthamuthu 选题:lujun9972 译者:geekpi 校对:wxy

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