今天是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被暂停通常是任务被CtrlZ或kill -STOP挂起。我遇到过最迷惑的情况是系统看起来卡但CPU占用并不高top里一堆D状态的进程一查是在等那块快挂掉的磁盘。这时候不要急着kill先去看磁盘I/O和dmesg日志问题很可能出在存储层而不是进程本身。pstree这个命令也值得养成习惯。它把进程的父子关系画成一棵树配合systemdPID 1往下看整个系统的进程结构一目了然。排查“哪个进程是谁拉起来的”这种问题pstree -ap比看一堆ps输出直观得多。1.2 信号是进程管理的遥控器kill/pkill/systemctl的共通逻辑进程管理里最常踩的坑是把kill当成“强制杀掉”的代名词。实际上kill只是给进程发信号进程收到信号后怎么处理取决于信号类型和进程自己的逻辑。先记住一条铁律kill -9是最后的手段不是第一选择。kill -lkill -l会列出所有信号。实际运维中常用的就这几个SIGTERM15默认信号请求进程自行退出。进程可以捕获这个信号做清理工作再退出相当于“优雅关停”。SIGKILL9由内核直接终止进程进程没有机会做任何清理相当于“强制断电”。SIGHUP1挂断信号很多守护进程收到SIGHUP会重新加载配置文件比如sshd、nginx所以改完配置不一定要重启可以kill -HUP让它平滑生效。SIGSTOP19和SIGCONT18暂停和继续运行相当于进程版的CtrlZ和fg。RHCSA考点里kill、killall、pkill三个命令的区别也经常出现。简单说kill需要精确PIDkillall按进程名精确匹配pkill支持按进程名的模糊匹配和正则。比如要结束所有名为nginx的进程pkill nginx会匹配到nginx和nginx-workerkillall nginx则需要精确匹配。我喜欢用pkill -f配合完整命令行匹配比如pkill -f python manage.py runserver这条命令会杀掉命令行里包含这段字符串的进程比按进程名匹配更准。学到这里要建立一个大观念systemctl停止服务时底层也是给主进程发SIGTERM等几秒再发SIGKILLsystemctl 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、eth0connection是网络配置项可以理解成网卡上绑定的“配置方案”。一块网卡上可以存在多个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如果网关能通再检查DNSdig 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_forward1 echo net.ipv4.ip_forward 1 /etc/sysctl.d/98-forward.conf sysctl --system第二步配置防火墙或iptables做NAT。如果用的是firewalld直接开启masqueradefirewall-cmd --permanent --zonepublic --add-masquerade firewall-cmd --permanent --zonepublic --add-interfaceens160 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] DescriptionHello service demo Afternetwork-online.target [Service] Typesimple ExecStart/opt/hello.sh Restarton-failure RestartSec5 [Install] WantedBymulti-user.target写完执行systemctl daemon-reload systemctl start hello systemctl status hellounit文件分成三段理解这三段就够了[Unit]描述服务信息及依赖关系。After表示当前服务在哪个目标之后启动不代表必须依赖它只是顺序关系。真正表达“我启动需要先有它”的是Requires。[Service]定义服务怎么跑。Typesimple表示ExecStart启动的进程就是主进程systemd不会额外fork。如果是传统SysV风格的daemon用Typeforking同时通常要配PIDFile。Restarton-failure是容器环境下非常常用的配置进程异常退出后自动拉起配合RestartSec5做间隔重启。[Install]定义如何被启用。WantedBymulti-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 --typeservice --stateenabledRHCSA考试里经常考“设置某个服务开机自启且立即启动”最简单的答案就是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. 存储与目录看懂分区之后再谈挂载NAS4.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交互式操作但考试和脚本里更推荐用非交互方式可以用partedparted /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添加这样一行UUIDxxxxxx /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 挂载NASNFS和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 usernamesmbuser,passwordxxxxxx,vers3.0实际挂载CIFS时建议指定vers3.0避免一部分NAS设备默认使用协议版本不一致导致挂载失败。如果不想密码写在命令行里可以写成credentials文件并锁定权限echo usernamesmbuser /etc/smb-credentials echo passwordxxxxxx /etc/smb-credentials chmod 600 /etc/smb-credentials mount -t cifs //192.168.1.200/share /mnt/windows-share -o credentials/etc/smb-credentials,vers3.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 _COMMsshd按PID过滤journalctl _PID12345我排查问题时的习惯是先看错误级别再逐步放宽条件避免被大量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、网络、存储全部衔接起来。希望这篇日志能给你一点参考也希望你不要只把命令记住而是真的把虚拟机打开在敲命令的过程中见到那些输出和报错。