课程主题：Linux 系统启动、运行级别、服务控制与主机名管理

适用环境：以采用 systemd 的现代 Linux 发行版为主，如 Rocky Linux、AlmaLinux、RHEL、CentOS 7+、Ubuntu 等。

目录

• 一、前言
• 二、常用命令
• 三、实验目的与基本原理
• 3.1 实验目的
• 3.2 基本原理
• 四、Linux 系统启动流程
• 4.1 第一阶段：BIOS 或 UEFI 固件启动
• 4.2 第二阶段：MBR 或 GPT 磁盘布局
• 4.3 第三阶段：GRUB2 引导加载器
• 4.4 第四阶段：加载 kernel 与 initramfs
• 4.5 第五阶段：启动 systemd（PID 1）
• 4.6 第六阶段：进入 target
• 4.7 第七阶段：login 登录
• 五、systemd 的作用与优点
• 5.1 systemd 的主要职责
• 5.2 systemd 的主要优点
• 5.3 systemd unit 类型
• 六、runlevel 与 target 映射
• 6.1 传统 runlevel 的概念
• 6.2 常用 target
• 6.3 查看、设置与切换 target
• 七、systemctl 服务管理详解
• 7.1 start 与 enable 必须分开理解
• 7.2 status 输出应该看什么
• 7.3 restart 与 reload 的区别
• 7.4 daemon-reload 与 reload 不相同
• 7.5 mask 与 disable 的区别
• 7.6 服务故障排查命令
• 7.7 自定义 service unit 示例
• 八、hostnamectl 主机名管理
• 8.1 查看主机名
• 8.2 设置静态主机名
• 8.3 三类主机名
• 九、chkconfig 作为旧系统扩展
• 9.1 chkconfig 的历史作用
• 9.2 旧命令与现代命令对照
• 十、企业实战：新上线 Web 服务器的系统管理
• 10.1 接收服务器并确认基础环境
• 10.2 按企业命名规范设置主机名
• 10.3 启用 SSH 与 Nginx 服务
• 10.4 检查服务状态
• 10.7 实战经验总结
• 十一、知识点详细解释
• 11.1 为什么 PID 1 非常重要
• 11.2 Wants、Requires 与 After 不是同一件事
• 11.3 enabled、disabled、static 和 masked
• 11.4 active 不一定表示业务正常
• 11.5 initramfs 与真实根文件系统的关系
• 11.6 rescue.target 与 emergency.target 的区别
• 11.7 systemd 日志的常见查询维度
• 11.8 启动慢不应只看 blame
• 11.9 生产操作的基本原则
• 十二、总结：今天学到了什么

一、前言 ↑

Linux 系统管理不仅是会输入命令，更重要的是理解系统从按下电源键到出现登录界面之间发生了什么，以及服务为什么能够自动启动、发生故障时应当从哪里开始排查。掌握启动流程后，管理员面对“服务器无法进入系统”“业务服务重启后没有自动运行”“系统进入了错误模式”等问题时，才能沿着正确的层次逐步定位原因。

本章以现代 Linux 系统为核心，梳理 BIOS/UEFI → MBR/GPT → GRUB2 → kernel 与 initramfs → systemd（PID 1）→ target →login 的完整启动链路，并介绍使用 systemctl 管理服务、使用 hostnamectl 管理主机名，以及传统 SysV init 系统中的 runlevel 和 chkconfig。

↑ 返回目录

二、常用命令 ↑

命令	主要作用	使用说明
systemctl status 服务名	查看服务状态	显示运行状态、PID、最近日志和失败原因。
systemctl start 服务名	立即启动服务	只影响当前运行状态，不等于设置开机自启。
systemctl stop 服务名	立即停止服务	不会自动取消该服务的开机自启配置。
systemctl restart 服务名	重启服务	先停止再启动，可能造成短暂业务中断。
systemctl reload 服务名	重新加载配置	服务需支持 reload；通常比 restart 影响小。
systemctl enable 服务名	设置开机自动启动	通常创建指向 unit 文件的符号链接，不保证服务此刻已运行。
systemctl disable 服务名	取消开机自动启动	通常不停止当前已经运行的服务。
systemctl enable --now 服务名	设置自启并立即启动	相当于同时执行 enable 和 start。
systemctl is-active 服务名	判断服务是否正在运行	适合脚本检查，常见结果为 active、inactive、failed。
systemctl is-enabled 服务名	判断是否配置开机自启	常见结果为 enabled、disabled、static、masked。
systemctl list-units --type=service	列出已加载的服务单元	默认更关注当前已加载和运行中的 unit。
systemctl list-unit-files --type=service	列出服务文件及启用状态	用于检查所有已安装服务的 enable/disable 状态。
systemctl get-default	查看默认启动 target	常见结果为 multi-user.target 或 graphical.target。
systemctl set-default TARGET	设置默认启动 target	例如设置为 multi-user.target，重启后默认进入文本多用户环境。
systemctl isolate TARGET	立即切换到指定 target	会停止不属于目标环境的服务，远程操作时必须谨慎。
systemctl daemon-reload	重新读取 unit 配置	新建或修改 unit 文件后执行，不等于重启业务服务。
journalctl -u 服务名	查看指定服务日志	可结合 -b、-f、--since 使用。
journalctl -b	查看本次启动日志	适合排查系统启动阶段故障。
hostnamectl status	查看主机名与系统信息	显示静态主机名、内核、架构和操作系统等信息。
hostnamectl set-hostname NAME	设置主机名	现代 systemd 系统推荐使用，通常不需要重启。
systemd-analyze	分析系统启动耗时	显示内核和用户空间启动时间。
systemd-analyze blame	按耗时排列启动单元	帮助定位启动速度慢的服务，但需结合依赖关系判断。
chkconfig --list	查看旧系统服务运行级别配置	主要用于 SysV init 时代，现代系统优先使用 systemctl。

常见服务管理示例

# 查看 SSH 服务状态（不同发行版可能叫 sshd 或 ssh）

sudo systemctl status ss

# 立即启动服务，但不修改开机自启设置

sudo systemctl start sshd

# 设置开机自启，但不改变服务当前状态

sudo systemctl enable sshd

# 同时设置开机自启并立即启动

sudo systemctl enable --now sshd

# 修改配置后重启服务

sudo systemctl restart sshd

# 查看本次启动中该服务的日志

sudo journalctl -b -u sshd

↑ 返回目录

三、实验目的与基本原理 ↑

3.1 实验目的 ↑

1. 理解计算机通电后从固件到用户登录界面的完整启动流程。
2. 掌握 BIOS、UEFI、MBR、GPT、GRUB2、kernel、initramfs 和 systemd 的作用。
3. 理解现代 Linux 中 systemd 作为 PID 1 的职责。
4. 掌握传统 runlevel 与现代 target 的对应关系。
5. 熟练使用 systemctl 启动、停止、重启、查看和配置服务。
6. 能够区分“当前是否运行”和“下次开机是否自动运行”。
7. 掌握使用 hostnamectl 查看及修改主机名的方法。
8. 了解传统 service、chkconfig 与现代 systemd 命令的差异。
9. 能够结合日志和依赖关系排查企业服务器的启动及服务故障。

3.2 基本原理 ↑

Linux 启动是一个逐级交接控制权的过程。固件首先完成硬件初始化并选择可启动设备；引导程序加载 Linux 内核及 initramfs；内核完成底层硬件、内存和进程机制的初始化；随后启动用户空间第一个进程。采用 systemd 的系统中，该进程通常是 /usr/lib/systemd/systemd 或 /sbin/init 指向的 systemd，进程号为 PID 1。systemd 再根据默认 target 组织依赖关系、并行启动系统服务，最后提供文本终端或图形登录界面。

核心思想：启动过程不是某一个程序独立完成，而是“固件、引导程序、内核、初始根文件系统、初始化系统、业务服务”逐层协作的结果。上一层出现问题，通常会导致下一层无法正常执行。

↑ 返回目录

四、Linux 系统启动流程 ↑

BIOS / UEFI

→

MBR / GPT

→

GRUB2

→

kernel + initramfs

→

systemd（PID 1）

→

target

→

login

4.1 第一阶段：BIOS 或 UEFI 固件启动 ↑

当服务器通电后，CPU 从固件预设位置开始执行代码。固件首先进行 POST（Power-On Self-Test，加电自检），检查 CPU、内存、键盘、磁盘控制器等基础硬件，并根据启动顺序寻找可引导设备。

• BIOS：传统固件模式，通常配合 MBR 分区表和磁盘首扇区中的引导代码。
• UEFI：现代固件模式，可直接识别 EFI System Partition（ESP）中的 .efi 程序，通常配合 GPT。
• Secure Boot：UEFI 的安全功能之一，用签名验证减少未授权启动程序被加载的风险。

BIOS/UEFI 不是 Linux 的组成部分，而是主板固件。它完成最初的硬件准备，并把启动控制权交给磁盘上的引导程序。

4.2 第二阶段：MBR 或 GPT 磁盘布局 ↑

MBR（Master Boot Record）位于传统磁盘的第一个扇区，其中包含少量引导代码和分区表。由于空间有限，GRUB 常将完整功能拆分为多个阶段。MBR 采用传统分区方案，常见限制包括磁盘容量和主分区数量。

GPT（GUID Partition Table）是现代分区表标准，支持大容量磁盘、更多分区，并保留主分区表与备份分区表。在 UEFI 模式下，固件通常从 FAT 格式的 EFI 系统分区中读取 GRUB、shim 或其他 EFI 引导程序。

比较项目	MBR	GPT
常见固件组合	传统 BIOS	UEFI
分区能力	传统限制较多	支持更多分区和大容量磁盘
冗余性	主要信息集中在磁盘开头	带主表和备份表，可靠性更高
引导位置	MBR 引导代码	通常由 UEFI 加载 ESP 中的 EFI 程序

4.3 第三阶段：GRUB2 引导加载器 ↑

GRUB2 是常见的 Linux 引导加载器。它读取自身配置，显示启动菜单，让用户选择内核或操作系统，并将选中的 Linux 内核和 initramfs 装入内存。GRUB2 还会向内核传递启动参数，例如根文件系统位置、只读挂载参数和救援模式参数。

常见相关文件和目录包括：

• /etc/default/grub：GRUB 默认参数配置文件。
• /etc/grub.d/：生成 GRUB 菜单的脚本目录。
• /boot/grub2/grub.cfg：部分 RHEL 系发行版的实际菜单配置。
• /boot/grub/grub.cfg：部分 Debian/Ubuntu 系发行版的菜单配置。
• /boot/efi/EFI/：UEFI 模式下 EFI 程序的常见位置。

注意：通常不应直接手工修改自动生成的 grub.cfg。应修改 /etc/default/grub 或对应模板，再使用发行版提供的命令重新生成配置。不同发行版、启动模式和磁盘布局的生成命令可能不同，操作前必须确认实际环境。

4.4 第四阶段：加载 kernel 与 initramfs ↑

GRUB2 将 Linux 内核加载到内存并移交控制权。内核随后完成内存管理、调度器、中断、设备驱动和基础文件系统等初始化。但是，真正的根文件系统可能位于 LVM、RAID、加密卷、iSCSI 或其他暂时无法直接访问的设备上，因此需要 initramfs 提供早期用户空间。

initramfs 是随内核一起加载到内存中的临时根文件系统，通常包含启动所需的驱动、工具和脚本。它负责发现存储设备、加载关键模块、激活 LVM/RAID、解锁加密设备并挂载真正的根文件系统。完成任务后，系统切换到真实根文件系统继续启动。

如果更换存储控制器、修改根分区结构或 initramfs 损坏，可能出现“找不到根文件系统”的启动故障。此时问题已经越过 GRUB 菜单阶段，但尚未进入完整的 systemd 用户空间阶段。

4.5 第五阶段：启动 systemd（PID 1） ↑

内核完成自身初始化后，启动用户空间的第一个进程。在现代主流发行版中，该进程通常是 systemd，其进程号固定为 PID 1。PID 1 具有特殊地位：它是其他用户空间进程的祖先之一，并负责回收失去父进程的子进程、组织服务启动和系统关机。

# 查看 PID 1 对应的进程

ps -p 1 -o pid,comm,args

# 也可查看 /sbin/init 的实际指向

readlink -f /sbin/init

systemd 读取 unit 文件，建立依赖关系图，然后根据默认 target 启动所需单元。它不必像传统脚本那样完全串行执行，因此许多无直接依赖的任务可以并行启动。

4.6 第六阶段：进入 target ↑

target 是 systemd 中用于组合和同步其他 unit 的逻辑目标。系统一般通过 default.target 符号链接决定默认进入文本多用户环境还是图形环境。

# 查看默认启动目标

systemctl get-default

# 查看 default.target 的指向

readlink -f /etc/systemd/system/default.target

服务器常使用 multi-user.target，提供网络和多用户文本环境；桌面系统常使用 graphical.target，它通常在多用户环境基础上继续启动显示管理器和图形界面。

4.7 第七阶段：login 登录 ↑

当目标环境所需服务启动完成后，系统通过虚拟终端上的 getty 提供文本登录提示，或者通过显示管理器提供图形登录界面。远程服务器还可能由 SSH 服务接收网络登录请求。用户通过认证后，系统创建会话并启动相应 Shell 或桌面环境。

↑ 返回目录

五、systemd 的作用与优点 ↑

5.1 systemd 的主要职责 ↑

• 作为现代 Linux 用户空间的初始化系统运行，并通常占用 PID 1。
• 根据依赖关系启动、停止、重启和监控系统服务。
• 管理系统启动目标、挂载点、交换分区、套接字、设备和定时任务等。
• 通过 journald 集中记录结构化日志。
• 提供登录会话、时间同步、主机名等系统管理组件。
• 协调系统关机、重启、休眠和恢复过程。

5.2 systemd 的主要优点 ↑

1. 支持并行启动： systemd 根据 unit 的依赖关系并行启动互不依赖的任务，从而缩短系统启动时间。
2. 依赖关系明确： 可通过 Requires=、Wants=、After=、 Before= 等指令描述依赖和顺序，比依赖脚本编号更清晰。
3. 统一管理接口： 管理员使用 systemctl 即可控制 service、socket、target、mount、timer 等多种 unit。
4. 按需激活： 支持 socket activation、D-Bus activation 等方式，在请求到来时再激活服务。
5. 服务监督与恢复： 可以跟踪服务主进程，并通过 Restart= 等配置在进程异常退出后自动恢复。
6. 日志集中化： journald 将内核、系统和服务日志统一管理，便于按服务、时间、启动批次等条件查询。
7. 资源控制： systemd 与 Linux cgroups 结合，可对服务进程进行归组，并限制 CPU、内存等资源。
8. 状态可观察： 可使用 status、show、list-dependencies、critical-chain 等命令查看运行状态和依赖关系。

5.3 systemd unit 类型 ↑

Unit 类型	文件后缀	作用
Service	.service	管理守护进程和一次性任务。
Target	.target	组合多个 unit，表示系统达到某个逻辑状态。
Socket	.socket	监听套接字，并按请求激活相应服务。
Timer	.timer	按时间触发任务，可作为 cron 的补充或替代。
Mount	.mount	管理文件系统挂载点。
Automount	.automount	在访问挂载点时自动挂载。
Path	.path	监视文件或目录变化并触发其他 unit。
Device	.device	表示内核识别到的设备。
Swap	.swap	管理交换空间。

↑ 返回目录

六、runlevel 与 target 映射 ↑

6.1 传统 runlevel 的概念 ↑

传统 SysV init 使用数字运行级别描述系统状态。不同发行版在个别级别的定义上可能存在差异，但常见约定如下：

传统运行级别	常见含义	systemd 兼容 target
0	关机	poweroff.target / runlevel0.target
1	单用户或救援模式	rescue.target / runlevel1.target
2	多用户模式，具体定义因发行版而异	multi-user.target / runlevel2.target
3	完整多用户文本模式，通常包含网络	multi-user.target / runlevel3.target
4	通常保留或由用户自定义	multi-user.target / runlevel4.target
5	图形多用户模式	graphical.target / runlevel5.target
6	重启	reboot.target / runlevel6.target

注意：runlevel 2、3、4 的准确含义在不同发行版中并不完全一致。因此，现代系统管理中应优先使用含义清晰的 target 名称，而不是只记数字。

6.2 常用 target ↑

• rescue.target：救援模式，提供最小化系统环境和单用户维护能力。
• emergency.target：比 rescue 更精简的紧急环境，根文件系统可能只读挂载。
• multi-user.target：非图形多用户环境，企业服务器最常使用。
• graphical.target：图形多用户环境，通常依赖 multi-user.target。
• network-online.target：表示网络管理组件认为网络已达到“在线”状态。
• poweroff.target：关闭系统。
• reboot.target：重新启动系统。

6.3 查看、设置与切换 target ↑

# 查看默认启动目标

systemctl get-default

# 设置下次启动默认进入多用户文本环境

sudo systemctl set-default multi-user.target

# 设置下次启动默认进入图形环境

sudo systemctl set-default graphical.target

# 立即切换到多用户文本环境

sudo systemctl isolate multi-user.target

# 查看 target 的依赖关系

systemctl list-dependencies multi-user.target

生产环境风险： systemctl isolate 会立即停止目标环境不需要的 unit。若通过图形终端或远程连接执行，可能导致当前会话或网络服务中断。设置默认目标与立即切换目标是两件不同的事情。

↑ 返回目录

七、systemctl 服务管理详解 ↑

7.1 start 与 enable 必须分开理解 ↑

命令	是否改变当前运行状态	是否改变开机自启状态
systemctl start nginx	是，立即尝试启动	否
systemctl stop nginx	是，立即停止	否
systemctl enable nginx	通常否	是，设置开机自启
systemctl disable nginx	通常否	是，取消开机自启
systemctl enable --now nginx	是，立即启动	是，设置开机自启
systemctl disable --now nginx	是，立即停止	是，取消开机自启

7.2 status 输出应该看什么 ↑

systemctl status nginx --no-pager -l

查看状态时应重点关注：

• Loaded：unit 文件是否成功加载，以及是否 enabled。
• Active：当前是 active、inactive、activating 还是 failed。
• Main PID：systemd 当前跟踪的主进程号。
• Process：启动前后命令及退出状态。
• 最近日志：配置错误、端口占用、权限不足等原因通常会直接显示。

7.3 restart 与 reload 的区别 ↑

restart 通常会停止旧进程再启动新进程，因此可能造成连接中断。 reload 请求服务在不中止主进程的情况下重新读取配置，但前提是服务本身及 unit 文件支持该操作。

# 先检查 Nginx 配置语法

sudo nginx -t

# 语法通过后平滑加载配置

sudo systemctl reload nginx

# 如果服务不支持 reload，才考虑重启

sudo systemctl restart nginx

对外提供 Web、数据库或代理服务时，不能在未检查配置的情况下直接重启。更安全的流程是： 备份配置 → 修改配置 → 语法检查 →reload → 状态检查 → 日志与业务验证。

7.4 daemon-reload 与 reload 不相同 ↑

• systemctl daemon-reload：通知 systemd 重新读取 unit 文件。
• systemctl reload nginx：通知 nginx 进程重新读取它自己的业务配置。

# 修改了 /etc/systemd/system/myapp.service 后

sudo systemctl daemon-reload

sudo systemctl restart myapp.service

# 修改了 /etc/nginx/nginx.conf 后

sudo nginx -t

sudo systemctl reload nginx.service

7.5 mask 与 disable 的区别 ↑

disable 只是移除开机启动关联，服务仍可被管理员手动启动，也可能因依赖关系被其他 unit 拉起。 mask 则通常把 unit 链接到 /dev/null，从而阻止手动或依赖启动。

# 取消开机自启

sudo systemctl disable cups.service

# 完全禁止该服务被启动

sudo systemctl mask cups.service

# 恢复启动能力

sudo systemctl unmask cups.service

对关键系统服务执行 mask 可能造成系统功能异常。生产环境操作前应先分析依赖关系，并准备回滚方案。

7.6 服务故障排查命令 ↑

# 查看失败的 unit

systemctl --failed

# 查看指定服务完整状态

systemctl status nginx.service --no-pager -l

# 查看本次启动以来该服务的日志

journalctl -b -u nginx.service

# 实时跟踪日志

journalctl -f -u nginx.service

# 查看从指定时间开始的日志

journalctl -u nginx.service --since "30 minutes ago"

# 查看 unit 文件内容及来源

systemctl cat nginx.service

# 查看属性

systemctl show nginx.service

# 查看依赖关系

systemctl list-dependencies nginx.service

7.7 自定义 service unit 示例 ↑

[Unit]

Description=Company Order API

Wants=network-online.target

After=network-online.target

[Service]

Type=simple

User=orderapp

Group=orderapp

WorkingDirectory=/opt/order-api

ExecStart=/opt/order-api/bin/order-api

Restart=on-failure

RestartSec=5

Environment=APP_ENV=production

[Install]

WantedBy=multi-user.target

以上 unit 文件通常可保存为 /etc/systemd/system/order-api.service。各部分含义如下：

• [Unit]：定义说明、依赖和启动顺序。
• [Service]：定义运行用户、工作目录、启动命令和失败重启策略。
• [Install]：定义 enable 时应关联到哪个 target。

# 修改或创建 unit 后，让 systemd 重新读取

sudo systemctl daemon-reload

# 设置开机自启并立即启动

sudo systemctl enable --now order-api.service

# 分别验证当前状态和开机自启状态

systemctl is-active order-api.service

systemctl is-enabled order-api.service

# 查看日志

journalctl -u order-api.service -b --no-pager

↑ 返回目录

八、hostnamectl 主机名管理 ↑

8.1 查看主机名 ↑

# 查看当前内核主机名

hostname

# 查看更完整的信息

hostnamectl status

hostnamectl status 除主机名外，通常还会显示机箱类型、机器 ID、启动 ID、操作系统、内核版本和硬件架构等信息。

8.2 设置静态主机名 ↑

# 设置规范的企业服务器主机名

sudo hostnamectl set-hostname web-prod-01.example.com

# 验证

hostnamectl status

hostname

主机名建议包含业务、环境和编号，例如 web-prod-01、db-test-02。 企业环境中还应确保 DNS 或 /etc/hosts 解析与主机名一致，避免监控、日志、证书或集群组件识别错误。

8.3 三类主机名 ↑

• Static hostname：持久化名称，通常保存在 /etc/hostname。
• Transient hostname：运行期间临时名称，可能由 DHCP 或网络管理服务设置。
• Pretty hostname：面向用户展示的描述性名称，可以包含空格和特殊字符。

# 分别设置不同类型的主机名

sudo hostnamectl set-hostname web-prod-01.example.com --static

sudo hostnamectl set-hostname web-prod-01 --transient

sudo hostnamectl set-hostname "Production Web Server 01" --pretty

↑ 返回目录

九、chkconfig 作为旧系统扩展 ↑

9.1 chkconfig 的历史作用 ↑

在采用 SysV init 的旧版 RHEL/CentOS 系统中，服务通常由 /etc/init.d/ 下的脚本管理。chkconfig 用于配置服务在不同运行级别下是否自动启动，而 service 命令用于控制服务当前的启动和停止。

# 旧系统：查看服务在各运行级别中的配置

chkconfig --list

# 旧系统：设置 httpd 开机自启

chkconfig httpd on

# 旧系统：取消 httpd 开机自启

chkconfig httpd off

# 旧系统：指定在运行级别 3 和 5 启动

chkconfig --level 35 httpd on

# 旧系统：立即启动服务

service httpd start

# 旧系统：查看服务状态

service httpd status

9.2 旧命令与现代命令对照 ↑

管理目的	传统 SysV init	现代 systemd
立即启动服务	service httpd start	systemctl start httpd
立即停止服务	service httpd stop	systemctl stop httpd
查看服务状态	service httpd status	systemctl status httpd
设置开机自启	chkconfig httpd on	systemctl enable httpd
取消开机自启	chkconfig httpd off	systemctl disable httpd
查看自启状态	chkconfig --list httpd	systemctl is-enabled httpd

部分采用 systemd 的发行版仍提供 service 或 chkconfig 兼容命令，但它们可能只是转换调用。现代系统应优先使用 systemctl，以便完整利用 unit、依赖、日志和状态管理能力。

↑ 返回目录

十、企业实战：新上线 Web 服务器的系统管理 ↑

业务场景： 某电商企业准备上线一台新的生产 Web 服务器。服务器安装了现代 Linux 系统，使用 Nginx 对外提供 HTTPS 服务，并通过 SSH 接受运维管理。管理员需要规范主机名、确认默认启动模式、配置服务开机自启，并处理一次因配置错误导致的 Nginx 启动失败。

10.1 接收服务器并确认基础环境 ↑

管理员登录新服务器后，不应立即修改配置，而应先确认系统身份、PID 1、默认 target 和当前失败单元。这样可以避免把适用于旧 SysV init 系统的命令错误地用在 systemd 环境中。

hostnamectl status

ps -p 1 -o pid,comm,args

systemctl get-default

systemctl --failed

检查结果表明 PID 1 为 systemd，默认目标为 graphical.target。由于该服务器位于机房，仅通过 SSH 维护，不需要长期运行图形桌面，因此管理员计划把默认启动目标改为 multi-user.target，减少不必要的软件和资源占用。

sudo systemctl set-default multi-user.target

systemctl get-default

这里仅修改“下次启动时的默认目标”，并没有贸然执行 systemctl isolate multi-user.target。这是因为立即 isolate 可能关闭当前环境依赖的服务，生产操作必须首先评估远程连接是否会受到影响。

10.2 按企业命名规范设置主机名 ↑

企业规定主机名由“业务角色、环境、编号”构成。管理员将服务器命名为 web-prod-01.example.com，随后检查 DNS 和本地 hosts 解析，保证监控平台、日志中心和证书系统能够识别同一台主机。

sudo hostnamectl set-hostname web-prod-01.example.com

hostnamectl status

getent hosts web-prod-01.example.com

10.3 启用 SSH 与 Nginx 服务 ↑

管理员先检查 SSH 服务，确认远程维护通道处于运行和开机自启状态。然后部署 Nginx。为了避免“现在能访问、重启后业务消失”，管理员分别验证 active 与 enabled，而不是只执行 start。

# SSH 服务名在部分系统中可能是 ssh

sudo systemctl status sshd

systemctl is-active sshd

systemctl is-enabled sshd

# 同时立即启动 Nginx 并设置开机自启

sudo systemctl enable --now nginx

# 分别验证两个维度

systemctl is-active nginx

systemctl is-enabled nginx

systemctl status nginx --no-pager -l

systemctl enable --now nginx 是便利写法，本质上同时完成开机自启和立即启动。上线检查表仍应把“当前运行状态”和“开机启动状态”列成两个独立项目，因为两者表示不同的系统事实。

10.4 检查服务状态 ↑

管理员使用 systemctl 查看服务是否正在运行、是否设置开机自启；如果服务异常，再使用 journalctl 查看日志。

systemctl status sshd --no-pager -l

systemctl is-active sshd

systemctl is-enabled sshd

journalctl -b -u sshd --no-pager -n 20

10.7 实战经验总结 ↑

• 先识别系统使用 systemd 还是传统 init，再选择管理命令。
• 修改默认 target 不等于立即切换 target。
• 服务“正在运行”和“开机自启”必须分别验证。
• 修改配置后先做语法检查，再 reload 或 restart。
• 服务失败时先看 status 和 journal，不要盲目重复重启。
• systemd 状态正常后，还必须做真实业务验证。
• 重启验证应安排维护窗口，并提前准备回滚与带外管理方式。

↑ 返回目录

十一、知识点详细解释 ↑

11.1 为什么 PID 1 非常重要 ↑

PID 1 是内核启动的第一个用户空间进程。普通进程如果失去父进程，会被 PID 1 接管并回收其退出状态。PID 1 退出通常会使系统失去正常用户空间管理能力，因此内核会把它作为特殊进程处理。在 systemd 系统中，查看 PID 1 是判断初始化系统类型的直接方法。

11.2 Wants、Requires 与 After 不是同一件事 ↑

• Wants=：弱依赖，目标 unit 会尝试一起启动，但被依赖者失败不一定导致本 unit 失败。
• Requires=：较强依赖，被依赖 unit 未能启动时，通常会影响当前 unit。
• After=：只描述启动顺序，不自动建立“必须启动”的依赖关系。
• Before=：表示当前 unit 应先于指定 unit 启动，同样主要描述顺序。

因此，若服务既要拉起网络在线目标，又要等其之后启动，常同时写：

Wants=network-online.target

After=network-online.target

11.3 enabled、disabled、static 和 masked ↑

状态	含义
enabled	已创建相应启动关联，通常会随目标环境自动启动。
disabled	没有配置自动启动，但仍可能被手动启动或被依赖拉起。
static	unit 通常没有可供 enable 的安装信息，主要由其他 unit 依赖触发。
masked	unit 被屏蔽，不能正常启动，限制比 disabled 更强。
indirect	通过别名或其他 unit 间接启用，具体行为取决于 unit 安装配置。

11.4 active 不一定表示业务正常 ↑

active (running) 只表示 systemd 认为服务进程正在运行。以下问题仍可能存在：

• 服务监听了错误的地址或端口。
• 防火墙没有放行端口。
• 应用无法连接数据库或缓存。
• 反向代理的上游节点全部失败。
• 接口返回 500，但进程本身没有退出。
• 证书过期或域名解析错误。

所以标准验证至少应覆盖：进程状态、端口监听、日志、网络连接和业务请求。

11.5 initramfs 与真实根文件系统的关系 ↑

initramfs 不是系统长期使用的根文件系统，而是启动早期的临时环境。它先提供必要驱动和工具，找到真实根文件系统后再执行根切换。如果 initramfs 中缺少关键存储驱动，即使磁盘中的系统文件完整，内核也可能无法访问根分区。

11.6 rescue.target 与 emergency.target 的区别 ↑

• rescue.target：启动较多基础服务并进入单用户维护环境，适合一般修复。
• emergency.target：提供更加精简的环境，常用于根文件系统或关键挂载严重异常时。

进入救援模式可能需要本地控制台、云平台串口或带外管理系统。远程服务器在操作前应确认不会因网络服务停止而失去连接。

11.7 systemd 日志的常见查询维度 ↑

# 当前这一次启动

journalctl -b

# 上一次启动（系统保留持久日志时）

journalctl -b -1

# 指定服务

journalctl -u nginx.service

# 只看错误级别

journalctl -p err

# 指定时间范围

journalctl --since "2026-07-12 08:00:00" --until "2026-07-12 10:00:00"

# 内核日志

journalctl -k

# 反向显示最新日志

journalctl -r

若系统未启用持久化 journal，重启后旧日志可能无法保留。企业环境应根据审计和排障需求配置日志持久化、轮转以及远程日志集中存储。

11.8 启动慢不应只看 blame ↑

systemd-analyze blame 会列出 unit 自身耗时，但并不完整表示关键启动路径。某个耗时较长的服务可能与其他服务并行运行，并未真正阻塞系统达到默认 target。因此还应结合关键链分析：

systemd-analyze

systemd-analyze blame

systemd-analyze critical-chain

critical-chain 更有助于找出真正阻塞目标到达时间的依赖链，但仍需结合服务日志、网络等待和磁盘性能综合分析。

11.9 生产操作的基本原则 ↑

1. 先观察：确认系统版本、初始化系统、服务名和当前状态。
2. 再备份：修改关键配置前保留可用版本。
3. 先检查后应用：使用程序自带的语法检测功能。
4. 优先最小影响：能 reload 时评估是否无需 restart。
5. 检查日志：状态信息不足时使用 journalctl 定位原因。
6. 业务验证：不能把进程存活等同于业务可用。
7. 准备回滚：明确恢复配置、恢复服务和带外登录方案。
8. 保留记录：记录操作时间、人员、命令、结果和问题。

↑ 返回目录

十二、总结：今天学到了什么 ↑

通过本章学习，我对 Linux 系统从通电到提供业务服务的全过程有了系统认识，主要收获如下：

1. Linux 启动通常依次经历 BIOS/UEFI、MBR/GPT、GRUB2、kernel 与 initramfs、systemd、target 和 login。
2. BIOS/UEFI 负责硬件初始化和启动设备选择；GRUB2 负责加载内核及 initramfs；内核负责底层资源管理；initramfs 负责找到并挂载真实根文件系统。
3. 现代 Linux 中 PID 1 通常是 systemd。它根据 unit 依赖关系组织服务，并提供统一的系统管理方式。
4. systemd 具有并行启动、按需激活、依赖管理、服务监督、日志集中和资源控制等优点。
5. 传统 runlevel 已由更清晰的 target 机制取代，其中 multi-user.target 常用于服务器，graphical.target 常用于图形桌面。
6. systemctl start 与 systemctl enable 必须分开理解：前者控制当前状态，后者配置开机自启。
7. restart 和 reload 影响不同；修改配置后应先做语法检查，再选择影响更小的应用方式。
8. daemon-reload 是让 systemd 重读 unit 文件，不是让业务程序重读业务配置。
9. 正确的主机名命令是 hostname 和 hostnamectl，不是 homename。
10. chkconfig 和 service 主要属于传统 SysV init 管理方式，现代系统应优先使用 systemctl。
11. 服务故障排查应结合 systemctl status、journalctl、端口监听和真实业务请求，不能只看进程是否存在。
12. 企业运维的关键不只是“命令执行成功”，而是形成 检查、备份、变更、验证、监控和回滚的完整闭环。

本章结论： 理解 Linux 启动链路可以帮助管理员判断故障发生在哪一个层次；掌握 systemd 和 systemctl，则可以在系统进入用户空间后高效、规范地管理服务。二者结合，是 Linux 运维人员处理启动故障、服务异常和生产变更的基础能力。

↑ 返回目录

Linux 系统管理 · 启动流程与 systemd 服务管理