今天是RHCSA+云原生学习日志的第三篇，前两篇我把文件权限、用户与组、yum源配置、vim操作这些基础扫了一遍，笔记也攒了二十多节。这篇我打算换个思路：不再往命令清单里硬塞东西，而是把Linux系统日常运行最关键的几条线串起来——进程、网络、服务、存储、日志。理由很简单，RHCSA考试不是考你背了多少命令，而是考你在断网、磁盘满、服务起不来这些真实故障现场能不能把系统恢复；云原生也一样，容器、Kubernetes这些上层技术，落地时完全依赖Linux的进程模型和systemd机制。你每天花四十分钟，开一台Rocky Linux 9虚拟机跟着敲一遍，一个月后再回头看这些命令，理解深度会完全不一样。这篇文章里的命令我全部在Rocky Linux 9上实际验证过，个别发行版有差异的地方会单独标注，建议你边看边动手，光存书签是没有用的。
1. 进程管理：从看懂输出到能改进程名
1.1 先分清ps输出里的每一列：进程状态的底层含义
很多新手学进程管理，上来就敲ps aux，看到一堆输出反而懵了。我备考RHCSA时也是这个状态，直到我把ps输出里的每一列都搞明白，才觉得整个系统清晰了很多。先看最常用的两组：
ps -ef ps auxps -ef适合看进程的父子关系，第一列UID是启动者，第二列PID是进程号，第三列PPID是父进程号。排查问题时我基本都用ps -ef | grep 进程名来找目标进程，特别是需要知道它是谁拉起来的时候，直接看PPID能省不少事。
ps aux适合查看资源占用情况，里面有个STAT列，这一列才是新手最容易忽略的重点。STAT列会显示进程当前处于什么状态，常见的有这么几个：
- S：可中断的睡眠，进程在等待某个事件，比如等待I/O完成，这是最正常的休息状态。
- R：运行中或在运行队列里，代表进程正在吃CPU。
- D：不可中断睡眠，通常是等待磁盘I/O，这一类进程连kill都杀不掉，只能等I/O超时恢复。
- Z：僵尸进程，子进程结束了但父进程没去收尸，PID还在，但已经不占内存了。偶尔出现不是大事，如果越积越多，就要去找父进程的问题。
- T：被暂停，通常是任务被Ctrl+Z或
kill -STOP挂起。
我遇到过最迷惑的情况是系统看起来卡，但CPU占用并不高，top里一堆D状态的进程，一查是在等那块快挂掉的磁盘。这时候不要急着kill，先去看磁盘I/O和dmesg日志，问题很可能出在存储层而不是进程本身。
pstree这个命令也值得养成习惯。它把进程的父子关系画成一棵树，配合systemd（PID 1）往下看，整个系统的进程结构一目了然。排查“哪个进程是谁拉起来的”这种问题，pstree -ap比看一堆ps输出直观得多。
1.2 信号是进程管理的遥控器：kill/pkill/systemctl的共通逻辑
进程管理里最常踩的坑，是把kill当成“强制杀掉”的代名词。实际上kill只是给进程发信号，进程收到信号后怎么处理，取决于信号类型和进程自己的逻辑。先记住一条铁律：kill -9是最后的手段，不是第一选择。
kill -lkill -l会列出所有信号。实际运维中常用的就这几个：
- SIGTERM（15）：默认信号，请求进程自行退出。进程可以捕获这个信号做清理工作再退出，相当于“优雅关停”。
- SIGKILL（9）：由内核直接终止进程，进程没有机会做任何清理，相当于“强制断电”。
- SIGHUP（1）：挂断信号，很多守护进程收到SIGHUP会重新加载配置文件，比如sshd、nginx，所以改完配置不一定要重启，可以
kill -HUP让它平滑生效。 - SIGSTOP（19）和SIGCONT（18）：暂停和继续运行，相当于进程版的Ctrl+Z和fg。
RHCSA考点里，kill、killall、pkill三个命令的区别也经常出现。简单说：kill需要精确PID，killall按进程名精确匹配，pkill支持按进程名的模糊匹配和正则。比如要结束所有名为nginx的进程，pkill nginx会匹配到nginx和nginx-worker，killall nginx则需要精确匹配。我喜欢用pkill -f配合完整命令行匹配，比如：
pkill -f "python manage.py runserver"这条命令会杀掉命令行里包含这段字符串的进程，比按进程名匹配更准。
学到这里要建立一个大观念：systemctl停止服务时，底层也是给主进程发SIGTERM，等几秒再发SIGKILL；systemctl restart也一样。理解了信号之后，再看systemd服务管理就不是“背命令”，而是明白每一步做了什么。这也是本系列一直强调的：把Linux看成一套有规则的协作系统，而不是一堆孤立命令。
1.3 通过exec -a和setproctitle修改进程名
标题里写了“修改进程名称”，这个需求在RHCSA教材里很少展开，但在云原生场景下非常实用。容器里同时跑着好几个同类型的worker进程，全都叫java或者python，排查问题时根本分不清谁是谁。给进程起一个可识别的名字，就是“可观测性”的第一步。
Linux进程名的展示逻辑其实由两部分决定：一部分是/proc/<PID>/comm，这个文件限制在15个字符以内，ps默认显示的进程名主要来自它；另一部分是argv[0]，也就是命令行里的第一个参数，ps -ef里展示的完整命令行会用到它。
最简单的方式是用bash的exec -a命令，启动时临时改掉argv[0]：
exec -a myworker python3 /opt/worker.py这样ps -ef里看到的进程名就是myworker，但要注意exec -a只改了argv[0]，不会修改/proc/<PID>/comm，所以ps默认的进程名列可能还是显示python3。如果需要同时改comm，可以用Python的setproctitle库：
pip install setproctitle然后在Python脚本开头加一行：
import setproctitle setproctitle.setproctitle("myworker-01")这个库会用prctl系统调用直接修改内核里的进程名，效果最干净。C语言里也有prctl(PR_SET_NAME, "worker01")，原理一样。我在实测中发现，容器里给每个worker设置不同的名称参数，再配合后面要讲的journalctl按_COMM过滤，定位问题速度能提升一个档次。
2. 网络配置实战：nmcli为主，iptables共享上网为辅
2.1 用nmcli从零配置静态IP：连接名和设备名的区别
网络配置是RHCSA的重头戏，也是云原生运维的基础。现在主流发行版都用NetworkManager管理网络，命令行下对应的工具是nmcli。很多新手在配静态IP时反复失败，根本原因是没分清“连接”和“设备”。
先看两行命令：
nmcli device status nmcli connection showdevice是物理网卡，比如ens160、ens192、eth0；connection是网络配置项，可以理解成网卡上绑定的“配置方案”。一块网卡上可以存在多个connection，但同一时刻只能激活一个。新手常犯的错是只改connection不管device，或者建了connection但忘了激活。
配置一个静态IP的完整过程如下：
# 新建一个连接，绑定到ens160 nmcli connection add con-name my-static ifname ens160 type ethernet # 设置IP、网关和DNS nmcli connection modify my-static ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 223.5.5.5 # 激活连接 nmcli connection up my-static这里con-name后面跟的是连接名，ifname指定的是物理网卡。系统安装时默认生成的连接名通常也叫ens160，但那只是一个默认名字，两个“ens160”完全不是一个东西。我建议配置时给连接起一个有意义的名称，比如my-static或office-internal，便于后续维护。
改完IP后第一件事是验证连通性：
ping -c 3 192.168.1.1如果网关能通，再检查DNS：
dig baidu.com没有dig的话用：
nslookup baidu.com很多网络故障其实是DNS配置错了，但排查顺序却先卡在网关，这条链路要记牢。
2.2 排查思路：通不通、快不快、通到哪，三层定位
网络排查最忌讳的是没有章法地乱ping。我在运维实践中总结出一套三段排查思路，RHCSA考试里的网络故障题也完全适用。
第一段，确认网卡和链路状态：
ip link ip -s link show ens160ip link能看到网卡是否UP，物理链路是否正常。ip -s link能看到累计收发流量，如果发送/接收计数一直不变，多半是物理链路或对端设备问题。
第二段，确认路由和连通性：
ip route ping -c 3 网关地址 ping -c 3 8.8.8.8这里有个小技巧：先ping网关，再ping公网IP，如果网关通但公网IP不通，那是路由或防火墙问题；如果公网IP通但域名不通，再转第三段查DNS。
第三段，确认端口和服务：
ss -tulnpss是取代netstat的现代工具，-t看TCP，-u看UDP，-l只看监听端口，-n不解析服务名，-p显示占用进程。比如排查nginx为什么打不开，先ss -tulnp | grep 80，如果nginx在监听但外部连不上，问题多半在防火墙。查看防火墙状态：
firewall-cmd --list-all我遇到过很多次配置完全正确、服务也在监听，结果就是firewalld默认zone没放行对应端口，外网一直访问不了。这条经验放在RHCSA考试里同样适用：答网络题时，检查顺序能救命。
2.3 把Linux主机变成内网出口：NAT共享上网的两种做法
热搜词里“linux 共享上网 办法”值得展开讲。场景是这样的：一台CentOS/Rocky主机有外网网络（比如ens160），内网网段192.168.10.0/24通过这台主机访问外部网络。这时候要让Linux主机承担网关角色，做NAT转发。
第一步，开启内核IPv4转发：
sysctl -w net.ipv4.ip_forward=1 echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/98-forward.conf sysctl --system第二步，配置防火墙或iptables做NAT。如果用的是firewalld，直接开启masquerade：
firewall-cmd --permanent --zone=public --add-masquerade firewall-cmd --permanent --zone=public --add-interface=ens160 firewall-cmd --reload如果内网网口和外网网口在不同zone，需要单独把内网网口加入internal zone，再开启masquerade。我习惯用更直观的iptables方式理解原理，命令如下：
iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE iptables -A FORWARD -i ens192 -o ens160 -j ACCEPT iptables -A FORWARD -i ens160 -o ens192 -m state --state ESTABLISHED,RELATED -j ACCEPT这里关键点是POSTROUTING链的MASQUERADE：内网机器发出来的数据包到达Linux主机后，源地址是192.168.10.x，经过这一条规则，源地址会被改写成ens160的公网地址，返回的数据包再自动转换回去。内网机器的网关地址要指向Linux主机的内网IP，同时配置一台可用的DNS。
这种NAT共享上网，在实验室搭测试环境非常实用。云原生场景里也常见：一台裸机作为Kubernetes节点的跳板机，同时为内网容器提供访问外网的途径，原理完全一致，只是把iptables换成了更底层的eBPF或IPVS。
3. systemd：服务管理，RHCSA考题与容器托管都靠它
3.1 systemd的unit文件：写一个nginx服务练手
systemd是Linux服务管理的核心，RHCSA几乎必考。云原生场景下，containerd、kubelet、etcd都是通过systemd托管的，学透systemd，后面理解容器生命周期会轻松很多。
先写一个最简单的systemd服务unit文件。假设我有一个脚本/opt/hello.sh，内容如下：
#!/bin/bash while true; do echo "hello at $(date)" >> /tmp/hello.log sleep 5 done给它加上执行权限并运行一次确认目录没问题：
chmod +x /opt/hello.sh然后新建unit文件/etc/systemd/system/hello.service：
[Unit] Description=Hello service demo After=network-online.target [Service] Type=simple ExecStart=/opt/hello.sh Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target写完执行：
systemctl daemon-reload systemctl start hello systemctl status hellounit文件分成三段，理解这三段就够了：
[Unit]：描述服务信息及依赖关系。After表示当前服务在哪个目标之后启动，不代表必须依赖它，只是顺序关系。真正表达“我启动需要先有它”的是Requires。[Service]：定义服务怎么跑。Type=simple表示ExecStart启动的进程就是主进程，systemd不会额外fork。如果是传统SysV风格的daemon，用Type=forking，同时通常要配PIDFile。Restart=on-failure是容器环境下非常常用的配置：进程异常退出后自动拉起，配合RestartSec=5做间隔重启。[Install]：定义如何被启用。WantedBy=multi-user.target是大多数命令行服务的标准写法，表示开启自启时把这个服务挂到多用户模式target下。
我在实战中多次因为忘了daemon-reload，导致systemd还在用旧的unit配置而启动失败。记住一个原则：unit文件任何修改，都先执行systemctl daemon-reload再重启服务。
3.2 systemctl命令背后的机制：enable到底做了什么
新手的第二个困惑是systemctl start和systemctl enable分不开。简化的理解是：start是立即启动一次，enable是设置开机自启。但深入一点，enable的实际动作是创建符号链接：
ln -s /usr/lib/systemd/system/hello.service /etc/systemd/system/multi-user.target.wants/hello.service看到这个链接就能理解，所谓“开机自启”就是在对应target的wants目录里建一个软链接，引导系统进入multi-user.target时就会把这个服务一起拉起来。同理，disable就是删除这个软链接。
常用命令总结如下：
systemctl enable --now hello # 启动并设置开机自启，等价于 start + enable systemctl disable --now hello # 停止并取消开机自启 systemctl restart hello systemctl reload hello # 如果unit文件配置了ExecReload指令，用这个做平滑加载 systemctl list-unit-files --type=service --state=enabledRHCSA考试里经常考“设置某个服务开机自启且立即启动”，最简单的答案就是systemctl enable --now 服务名。但如果你理解了符号链接机制，就算不记得这个组合参数，也可以用前面两个命令凑出同样效果。
systemctl is-enabled可以查看是否开机自启，systemctl is-active查看是否运行。这两个命令在脚本里经常用作条件判断，比解析status输出简单多了。
3.3 journalctl日志与dbus状态通知
systemd另一个强大的地方是统一收集服务日志。传统方式里各服务自己往/var/log/目录写文件，systemd则默认把服务的标准输出和标准错误接到journal里，用journalctl统一查看。
journalctl -u hello.service # 只看hello服务的日志 journalctl -u hello.service -f # 持续跟踪 journalctl --since "10 minutes ago" # 只看最近10分钟 journalctl -p err # 只看错误级别以上-u指定服务，-p指定优先级，--since按时间过滤，这三个参数组合基本覆盖了日常排障需求。做RHCSA模拟题时，看到“检查某服务为什么启动失败”，第一步一定是systemctl status看状态，第二步就journalctl -u 服务名 -n 50看最后50行日志。
这里要提一下热搜词里的“linux d bus通讯”。systemd与系统其他组件通信，很多依赖DBus。当你执行systemctl命令时，客户端会把请求通过DBus消息发给PID 1的systemd进程，systemd处理完再把结果返回。这也是为什么某些极端情况下DBus服务不正常，systemd命令会卡住。理解这个通信链路，对排查“systemctl命令无响应”很关键。如果哪天sytemctl status卡住，先看/run/dbus/system_bus_socket是否异常，再用ps -ef | grep dbus确认dbus-daemon进程是否活着。
顺带提一下“fence机制”这个词。它属于高可用集群领域，核心思想是当节点状态不可信时，必须先把异常节点从共享存储或网络中隔离（fence）掉，再让备用节点接手，防止两个节点同时操作数据导致脑裂。systemd的单机服务Restart是局部保活，fence是集群层面的“物理隔离”，两者解决的问题不同，但背后都是“异常后必须可靠恢复”的思路。单机基础没打牢之前，不建议一上来就折腾这套。
4. 存储与目录：看懂分区之后再谈挂载NAS
4.1 先理解目录地图：/etc、/var、/proc、/sys不能搞混
RHCSA基础篇里“目录说明”必须过关。Linux的目录树看着复杂，本质就三类：用户数据、系统配置、内核与设备信息接口。搞清楚分类，遇到存放路径时就不会乱猜。
/etc：系统的全局配置文件目录，nginx.conf、fstab、hosts、passwd都在这。改系统配置基本绕不开它。/var：会变动的数据，最常见的/var/log日志目录，/var/tmp临时目录，还有邮箱、缓存等。/proc：这是一个虚拟文件系统，目录里的内容不是磁盘上的真实文件，而是内核运行信息的接口。比如/proc/cpuinfo是CPU信息，/proc/meminfo是内存信息，每个进程都有对应的/proc/PID/目录。执行cat /proc/version可以看到内核版本。/sys：另一个虚拟文件系统，主要暴露内核设备模型。现代硬件管理工具（如udev、systemd）都在和它打交道。/dev：设备文件的所在地，/dev/sda代表第一块SATA磁盘，/dev/nvme0n1代表NVMe磁盘。/home和/root：普通用户家目录和root家目录。/usr：系统软件资源的集中地，可执行文件在/usr/bin，库文件在/usr/lib。早期会把/usr单独分区，现在很多系统选择合并，但路径含义没变。
记住一句话：**真实数据在/home、/var和/etc，虚拟接口在/proc和/sys，设备节点在/dev。**这样在清理磁盘空间时就知道该往哪儿看，看到/proc里的“文件”不是垃圾。
4.2 分区、格式化、挂载与fstab持久化
存储操作的完整链路是：分区、格式化、挂载、持久化。RHCSA考试和真实运维里，这条链路必须闭着眼睛做下来。
先看当前盘符：
lsblk假设有一块新磁盘/dev/sdb，计划分一个区并格式化为xfs。分区用fdisk交互式操作，但考试和脚本里更推荐用非交互方式，可以用parted：
parted /dev/sdb mklabel gpt parted /dev/sdb mkpart primary xfs 1MiB 100% mkfs.xfs /dev/sdb1实际操作用parted可以避免fdisk的交互麻烦，如果只想快速分区，fdisk也没有问题：
fdisk /dev/sdb <<EOF n p 1 w EOF格式化之后，创建挂载点并挂载：
mkdir -p /data mount /dev/sdb1 /data df -hdf -h显示-使用量和挂载点。如果要卸载，直接umount /data，注意先确保没有进程在使用该目录。
持久化到fstab，这一步最容易翻车：
blkid /dev/sdb1用blkid查到UUID，再编辑/etc/fstab，添加这样一行：
UUID=xxxxxx /data xfs defaults 0 0第一个0表示不在dump备份中，第二个0表示开机不做fsck检查。接着执行mount -a验证fstab有没有语法错误。
fstab写错最典型的后果是开机进emergency mode。真实运维里我在云主机上改fstab从来不是直接改文件，而是一边开着另一个终端，一边准备随时恢复。稳妥的做法是先备份：cp /etc/fstab /etc/fstab.bak，然后验证无误后再重启。如果已经开机失败，进入emergency mode后执行mount -o remount,rw /把根分区变为可写，再改回fstab。这个恢复流程RHCSA不一定会考，但很大概率是生产环境救命的操作。
4.3 挂载NAS：NFS和CIFS的实战参数与开机自动挂载
热搜词里“linux挂载nas存储csdn”的出现频率很高，说明这是真实运维里的高频需求。NAS本质就是一台通过网络提供存储的服务器，Linux下最常见两种协议：NFS主要面向Linux/Unix系统，CIFS/SMB主要用于Windows共享，但在Linux下也能挂载Windows共享目录。
NFS端操作：
# 安装客户端工具 dnf install -y nfs-utils # 查看服务端共享目录 showmount -e 192.168.1.200 # 挂载 mount -t nfs 192.168.1.200:/data/backup /mnt/nfs-backupCIFS端操作：
dnf install -y cifs-utils mount -t cifs //192.168.1.200/share /mnt/windows-share \ -o username=smbuser,password=xxxxxx,vers=3.0实际挂载CIFS时，建议指定vers=3.0，避免一部分NAS设备默认使用协议版本不一致导致挂载失败。如果不想密码写在命令行里，可以写成credentials文件并锁定权限：
echo "username=smbuser" > /etc/smb-credentials echo "password=xxxxxx" >> /etc/smb-credentials chmod 600 /etc/smb-credentials mount -t cifs //192.168.1.200/share /mnt/windows-share -o credentials=/etc/smb-credentials,vers=3.0开机自动挂载网络存储，fstab里要特别注意用_netdev选项，它告诉systemd这是一个网络设备，要等网络就绪后再挂载，避免开机时网络还没起来就尝试挂载导致失败。NFS的fstab行为例：
192.168.1.200:/data/backup /mnt/nfs-backup nfs defaults,_netdev 0 0云原生场景下，Kubernetes的PV/PVC也经常对接NFS这类存储，底层就是通过NFS协议挂载到宿主机或Pod里。理解了mount、fstab和权限问题，再看存储类资源就不会头大。硬盘是普通存储，NFS是网络存储，它们的共同点是都以文件系统形式挂载进目录树，这一点永远不变。
5. 日志排障与系统维护：把故障当成学习机会
5.1 用journalctl精准过滤日志：按时间、服务和优先级
日志是Linux排障的第一手证据。journalctl基础用法之前提过，这里再说几个能立刻提效的组合用法。
按时间过滤：
journalctl --since "2025-01-01 00:00:00" --until "2025-01-01 23:59:59"按服务加优先级：
journalctl -u nginx.service -p warning --since "1 hour ago"只显示关键进程的消息：
journalctl _COMM=sshd按PID过滤：
journalctl _PID=12345我排查问题时的习惯是先看错误级别，再逐步放宽条件，避免被大量info日志淹没。默认情况下journal只存在内存里，重启就丢了。如果想把系统日志持久化到磁盘，创建目录并设置：
mkdir -p /var/log/journal mkdir -p /var/log/journal/$(cat /etc/machine-id) systemd-tmpfiles --create --prefix /var/log/journal重启后日志就会持久保留。生产环境建议一定要做这一步，否则想看上一次重启前发生了什么，会发现什么线索都没有。
5.2 日志文件不清理的后果：logrotate与清空技巧
日志文件如果不做轮转，/var/log迟早会被写满。很多“系统故障”的根因就是磁盘满了。先看磁盘空间：
df -h du -sh /var/log/* | sort -rh | head日志清理的第一推荐方案是logrotate，它不是简单的删除，而是按策略轮转：把当前日志改名、压缩，再生成一个新的空日志文件，进程不用重启，继续往新文件里写。配置文件的默认位置在/etc/logrotate.conf，具体服务的轮转规则在/etc/logrotate.d/。
看一下一个典型的nginx日志轮转配置：
/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty sharedscripts postrotate /bin/kill -USR1 $(cat /var/run/nginx.pid 2>/dev/null) 2>/dev/null || true endscript }含义说明：daily每天轮转一次，rotate 14保留14份旧日志，compress对旧日志压缩，delaycompress延迟一天压缩（给还没有完全写完的日志留时间），notifempty表示日志为空时不轮转。postrotate是在轮转后执行的一段脚本，这里给nginx发送USR1信号让nginx重新打开日志文件，否则nginx还写旧文件句柄，轮转就失去意义了。
这里有个很重要的细节：不要用rm直接删除正在被进程写入的日志文件。进程打开的是文件句柄，不是文件名。你把文件删了，进程还在往那个句柄里写，磁盘空间并不会释放，只有把进程重启或让进程重新打开日志文件才生效。我实测里最稳妥的“快速清理”方式是用truncate清空文件，而不是删除：
truncate -s 0 /var/log/大文件.log这条命令能立即释放磁盘空间，又不影响进程继续写入。应急处理时很好用，但根本解法还是配置好logrotate。
5.3 完整排障示例：从网络中断追到日志累积
学习Linux最有效的方式是真实排障。我拿一个非常典型的故障链完整演示一遍：某天内网一台测试服务器突然连不上，排查过程如下。
第一步，先猜问题范围。先ping服务器IP，不通；再ping网关，通。说明网络链路从我这台机器到服务器所在网段有问题，或服务器本身失联。
第二步，通过带外管理或物理控制台登录服务器。登录后发现系统能进入，但非常卡。查看系统负载和内存：
top free -h发现CPU不高，但I/O waiting很高，磁盘读写异常。
第三步，查磁盘空间：
df -h根分区100%满。进一步定位大文件：
du -ah /var | sort -rh | head -20发现/var/log/某个服务的日志已经膨胀到几十GB。为什么之前没发现？因为这个服务的日志轮转配置缺失或失效，写日志的进程也一直没有重启，日志文件句柄还挂在两天前的位置，df看到空间确实满了，但du查这个文件却显示“实际占用的块”没有完全释放。
第四步，应急处理。别急着删除，先truncate -s 0清空那个大日志文件，然后重启那个服务，让进程重新打开日志。空间立刻释放，系统恢复响应。
第五步，根治。给该服务的日志加上logrotate规则，并调整日志级别，避免下次再发生同样问题。
上面这个链路里融合了进程、存储、日志三条主线，是我认为最有RHCSA风格的真实场景。故障排查的关键是控制节奏：先看现象，再定范围，再查根因，最后做根治，千万不要上来就kill进程或者格式化磁盘。
我备考RHCSA时，基本上把这类故障脚本化：每天故意在虚拟机里制造一个问题，比如关掉一个服务、写错一行fstab、改错网络配置，然后逼自己不看笔记去恢复。这个习惯帮我建立了条件反射，考试时面对“service sshd is not running”这类题目，扫一眼就能定位是服务挂了、配置错了还是网络不通。
基础篇到这里，前面三篇覆盖的命令和概念——文件权限、用户管理、yum源、vim、进程、网络、systemd、存储、日志——已经可以支撑你完成大部分RHCSA入门题。从我的学习经验看，接下来性价比最高的方向是两个：一是把Podman和容器跑起来，体验“systemd管理包含容器进程”的完整链路；二是开始接触Kubernetes核心概念，把单机Linux的知识搬到集群环境。下一篇的更新笔记，我计划写容器运行时和Pod的基础操作，正好把这篇里讲的systemd、网络、存储全部衔接起来。希望这篇日志能给你一点参考，也希望你不要只把命令记住，而是真的把虚拟机打开，在敲命令的过程中见到那些输出和报错。
