★ FEATURED ARTICLE 1. 为什么第四天是一个关键节点由敲命令到管系统很多刚接触 Linux 的朋友都会遇到一个尴尬阶段头一两天还能靠着 ls、cd、cp、mv 这些命令维持新鲜感等慢慢开始接触权限、用户、进程、服务的时候突然觉得知识点变散了——好像每个命令都认识合在一起却不知道在解决什么问题。我之前带 A 同学入门时也卡在这个位置后来重新梳理了一遍学习路径才发现第四天恰恰是整条线里最能拉开差距的一天。这个节点上的核心转变是从会敲命令过渡到能管理系统。第一天你学会怎么进入目录、怎么复制文件那是把 Linux 当成一个操作界面在学但系统真正的复杂度不在这里。用户账户怎么建立、为什么新建出来的文件权限总是 644、某个进程卡死了该怎么处理、一台服务为什么开机没有自动跑起来——这些问题才是日常运维里反复出现的场景而它们都集中在第四天的内容范围里。我给 A 同学安排第四天的学习任务时只圈定了三个方向用户和组、文件权限的进阶理解、进程与服务排障。没有安排更多因为这三块每一块都足够深贪多反而会把最重要的底层逻辑冲淡。事实证明这个节奏是对的他把当天学的东西直接扔到一台测试服务器上去用第 5 天开始已经能独立处理新同事要开账号、某个服务起不来了这类真实请求而不是继续对着教程抄命令。这篇文章就把这套经过验证的第四天路线完整展开每一步都会给出可以直接照做的命令也会解释命令背后为什么要这样设计。无论你是零基础自学还是带着团队做内训按这个节奏走一遍比漫无目的刷文档效率高得多。2. 用户与组管理从 useradd 到 /etc/passwd 的完整链路2.1 创建用户为什么不是注册个账号那么简单很多教程会告诉你useradd 用户名就能加一个用户我建议你第一遍可以这么试但第二遍就要立刻换掉这个用法。因为裸敲 useradd 只会在 /etc/passwd 里追加一条记录它不会帮你创建家目录不会帮你设置默认 shell更不会帮你生成密码。以我这边的实测结果为例直接执行 useradd zhangsan然后 su - zhangsan你会发现自己要么进不去家目录要么拿到的 shell 根本不是你想用的那个体验非常糟糕。真正规范的创建用户方式是把这些参数一次给全useradd -m -s /bin/bash -G dev,ops zhangsan passwd zhangsan这里每个选项都有明确含义。-m表示同时创建家目录 /home/zhangsan-s指定登录 shell-G把用户加入附加组 dev 和 ops。注意-G和-g的区别-g是主组通常和用户名同名-G是附加组用于让用户获得其他组的补充权限。如果你希望用户只能通过密钥登录可以用-s /sbin/nologin创建纯服务账户。关于 useradd 和 adduser 的区别不同发行版处理方式不一样。有的发行版里 adduser 只是一个指向 useradd 的软链接有的则是交互式脚本会自动帮你设置密码、创建家目录。我的建议是在生产环境里统一使用 useradd 加显式参数因为脚本工具的交互行为在不同版本之间不一致你没法保证它在每台机器上都按预期执行。2.2 三个核心配置文件应该怎么看用户和组的背后是三个文本文件/etc/passwd、/etc/shadow、/etc/group。用 cat 打开 /etc/passwd每一行代表一个用户冒号分成七段zhangsan:x:1001:1001::/home/zhangsan:/bin/bash从左到右依次是用户名、密码占位符真正的密码在 /etc/shadow 里、UID、GID、注释信息、家目录、登录 shell。这里我特别想让初学者看懂一个设计逻辑为什么 /etc/passwd 里放的是 x 而不是真正的密码因为 passwd 文件在很多场景下需要被普通进程读取比如 ls -l 要显示文件属主如果密码也放在这里等于把哈希暴露给所有能读文件的用户安全性大打折扣。把哈希挪到只有 root 能读的 /etc/shadow同时保留一个占位符在 passwd 中就是用文件系统权限做信息隔离的典型例子。/etc/shadow 里每行的字段更多包括密码哈希、上次修改时间、最短/最长修改周期、警告天数等。日常用得最多的是强制密码过期用 chage 命令操作chage -M 90 zhangsan chage -W 7 zhangsan-M 90表示 90 天后密码必须更换-W 7表示过期前 7 天开始提醒。如果是给临时外包人员开的账号再加一个固定的过期时间-E 2025-12-31到期自动失效省得每天记着去清理。2.3 用户删除时最容易踩的坑删除用户要记一个口诀删用户不删数据删数据不删用户。userdel 默认只移除账户记录不会动家目录和用户拥有的文件这在某些场景下是好事比如要保留离职人员的工作文档但在清理测试机环境时这个默认行为反而会造成大量孤儿文件。所以预留三种操作方式userdel zhangsan # 只删账户和组记录 userdel -r zhangsan # 同时删除家目录和邮件池 userdel -f zhangsan # 强制删除即使该用户还在登录中我实际推荐大多数情况用-r。因为残留的家目录不但占空间还会在后续创建同名用户时引发一个烦人的问题新用户 UID 和旧用户不同但家目录路径一样于是新用户可能会读到旧用户留下的权限异常文件造成隐蔽的安全风险。组的管理相对简单groupadd 建组、groupmod 改名、groupdel 删组。要特别注意 groupdel 只能删除没有用户主组引用的组如果某个用户的主组还指向它会直接报错。此时要么先改掉用户的主组要么先删用户顺序错了会被系统拦下来。3. 权限进阶chmod、umask 和三个特殊权限位3.1 数字权限不神秘它就是二进制状态的简写网上的权限教程几乎都会给一张r4、w2、x1的对照表但很少讲清为什么是这三个数。其实很简单权限本质上是对 rwx 三个比特位的开和关。r 对应二进制的 100也就是十进制 4w 对应 010十进制 2x 对应 001十进制 1。把三个位加起来得到 0 到 7 的整数很自然就能表达 8 种组合。所以chmod 754真正做的事情是把属主权限设为 rwx、属组设为 r-x、其他用户设为 r--。我见过不少人背数字组合背到 775、750 就混乱了我建议不要背就现场拆解7 是 4215 是 410 是啥也没有一秒钟就能算出来。能心算之后随口写出chmod 640也不再是问题。符号模式在脚本和临时调整里也很好用。chmod ux只给属主加执行权限chmod -R g-w递归去掉属组的写权限。日常维护中我倾向于这样的选择交互式环境下用符号模式更直观写入脚本或落库配置时用数字模式因为数字模式的结果与 umask 无关执行结果完全可预期。3.2 umask为什么你新建的文件总是 644而不是 666如果你刚接触 Linux 不久一定会好奇为什么 touch 出来的新文件权限默认是 644而 mkdir 出来的目录默认是 755这个默认值不是系统拍脑袋定的而是由 umask 决定的。要理解它先记住一个底层差异文件的最大默认权限是 666没有执行位目录的最大默认权限是 777目录需要执行位才能进入。umask 是要屏蔽掉的权限位所以最终权限等于最大值减去 umask文件666 - 022 644 目录777 - 022 755这解释了为什么很多服务器上 umask 是 022它屏蔽掉了属组的写权限和其他用户的写权限保证新建文件默认对他人是只读的够安全又不会妨碍协作。我遇到过一个非常典型的案件某开发环境里启动脚本生成的日志文件权限变成了 600导致其他同事无法查看日志。排查下来发现启动脚本的作者在脚本里写了一行umask 077本意是让临时文件更私密结果整个进程创建的全部文件都受影响。这就是 umask 的隐藏作用范围——它影响的是当前 shell 及以后启动的所有子进程而不是只影响下一条命令。想临时调整就用umask 027 # 当前 shell 生效 umask -S # 以符号形式查看当前掩码要永久改就到 /etc/profile 或 /etc/bashrc 里搜 umask 关键字按需修改。如果只是想在新用户自己的环境里改则写到 ~/.bashrc。3.3 setuid、setgid 和 sticky bit三个不常用但关键时刻救命的权限位普通 rwx 权限之外还有三个特殊权限位平时 ls -l 时它们会出现在执行位上表现形式是 s 或 t。我把它称为进入真实运维世界的门票因为只懂 644/755 的人遇到这些场景会完全摸不着头脑。setuid 位数字 4作用于可执行文件时表示谁执行这个文件谁就临时获得属主的身份。最经典的例子就是 /usr/bin/passwd普通用户要改自己的密码但 /etc/shadow 只有 root 能写如果没有 setuid这个需求在逻辑上就是死路。passwd 文件上的 setuid 位让普通用户临时以 root 身份运行密码修改程序程序内部再严格校验权限问题就解决了。setgid 位数字 2有两种作用。作用于目录时新文件会继承目录的属组而不是创建者自己的主组。这个方法在共享项目目录里非常有用几个同事都在同一个目录下写文件只要目录设了 setgid生成的新文件就都是同一个组避免你的文件我改不了的尴尬。sticky bit数字 1主要用在共享目录上。典型代表是 /tmp任何用户都能在里面创建文件但不允许删除别人的文件。普通的 rwx 权限里只要对目录有写和执行权限就能删任何文件sticky bit 的约束就是目录里的文件只有属主、目录属主或 root 能删。设置方法chmod 4755 /usr/local/bin/某个工具 # 加 setuid chmod 2775 /data/shared # 加 setgid chmod 1777 /data/common # 加 sticky bit检查时注意区分大小写执行位上是小写 s、t 表示特殊位和执行位同时存在如果显示大写 S、T说明特殊位在但执行位缺失这通常意味着你的权限组合有问题需要修正。3.4 ACL当 chmod 不够用时的一层补充普通权限模型只有属主、属组、其他三类角色真实业务里经常出现让特定几个用户能读其他用户不能读的诉求用 chmod 很难优雅实现。这时就可以用 ACL 访问控制列表它的核心价值是为指定用户或指定组追加权限。常用操作setfacl -m u:zhangsan:rw /data/project # 给 zhangsan 读写权限 setfacl -m g:dev:rx /data/project # 给 dev 组读加执行权限 getfacl /data/project # 查看现有 ACL setfacl -x u:zhangsan /data/project # 移除某个条目设置了 ACL 之后ls -l 权限位末尾会出现一个加号提示符。要注意的是ACL 修改的是扩展属性需要用 cp -p 或 rsync -p 这类能保留属性的命令复制否则目标路径上 ACL 会丢失。这个问题我踩过一次备份脚本一执行新机子上登录权限全乱了排查了半天才发现是复制时丢了 ACL。4. 进程管理从 ps 到 kill 的完整生命周期认知4.1 ps aux 不是三个字母的咒语初学者第一次敲 ps aux 都会对着输出发呆其实拆开看就通了。ps 是 process status 的缩写a 显示所有用户的进程u 显示用户和资源占用信息x 显示不带终端的进程。这三者组合起来就是当前系统里所有进程及其资源消耗的全景图。输出里最需要看懂的几个列USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 59004 2128 ? Ss 08:12 0:00 /sbin/init zhangsan 2045 12.5 2.3 123456 45600 pts/0 R 10:20 0:03 ./appPID 是进程号PPID 是父进程号要用 ps -ef 才看得到。%CPU 是瞬时占用率%MEM 是物理内存占比STAT 表示状态R 运行中、S 睡眠、D 不可中断睡眠通常在做磁盘 IO、Z 僵尸进程。最需要警惕的是 Z它会持续出现在输出里表明该进程已经结束但父进程没有正确回收它。如果系统里频繁出现 Z就要检查父进程是不是写崩了或考虑把父进程重启一次。4.2 top 的交互式操作别只会按 qtop 是终端里的实时监控器默认按 CPU 占用排序展示所有进程。大多数人打开 top 按一下 q 就结束了这太浪费。实际工作中我用得最多的快捷键是这些P按 CPU 排序排查 CPU 跑满的第一选择M按内存排序内存异常时切一下k输入 PID 后发送信号可以直接在 top 里结束进程r改名进程优先级实际是 renicec显示完整命令行数字 1展开每个 CPU 核心的占用情况定位到可疑进程后可以先看一眼它的命令行、启动时间、所属用户再决定下一步动作。不需要立刻杀先观察几个刷新周期判断是间歇性的任务还是持续占用。如果遇到进程名伪装成系统进程的情况c看完整路径就很有用。htop 是 top 的增强版支持鼠标操作和树状视图体验确实更好但很多刚上线的服务器未必预装而且排障时要靠标准工具所以我的态度是top 必须熟练htop 作为加分项。4.3 信号不是只有 kill -9kill 命令的本质不是结束程序而是向进程发送信号。它只是发送信号的工具之一进程收到信号后如何响应由进程自己决定。这个认知特别重要因为很多人一遇到进程卡住就祭出 kill -9虽然有效但代价可能是数据残损。最常用的几个信号信号编号默认行为场景SIGTERM15终止进程标准关闭方式程序可捕获后做清理SIGHUP1终止进程常用于通知守护进程重读配置SIGINT2中断进程等价于 CtrlCSIGKILL9强制终止不可捕获不可忽略最后手段SIGSTOP19暂停进程相当于 CtrlZSIGCONT18继续运行配合恢复暂停的进程正确关闭一个服务的惯用链路是先kill -15 PID观察一段时间如果进程没退出再kill -9兜底。虽然多了一两步但能把进程争取到的优雅退出机会留给它。像数据库这类对数据一致性要求高的进程收到 SIGTERM 后会执行事务回滚和刷盘SIGKILL 则直接把这一切跳过数据损坏风险很高。后台任务管理也是第四天必过的一关。在命令末尾加可以直接放入后台CtrlZ 可以挂起前台任务jobs 查看后台任务列表fg 把任务拉回前台bg 让暂停任务在后台继续跑。真正长期运行的任务更推荐用 nohup 或 setsid 把它与会话解绑这样即使终端关闭进程也不会被挂断。优先级方面nice 的默认值是 0范围从 -20 到 19数值越小优先级越高。启动时指定nice -n 5 ./backup.sh运行时调整renice -n 10 -p PID。我的建议是只在明确的情景里用比如备份任务不能抢走线上服务的 CPU就给它一个较大的 nice 值让它让位。5. 服务与排障把启动失败变成可复现的排查链路5.1 systemctl 的日常循环就这几个命令到了第四天你应该开始接触服务管理了这里有现代发行版的基础用法。systemd 是当前绝大多数主流发行版使用的初始化系统意味着你管理服务的方式高度统一start、stop、restart、status、enable、disable。systemctl start nginx systemctl enable nginx systemctl enable --now nginxenable --now是我最推荐新手使用的方式一条命令同时完成开机自启和立即启动避免出现现在能用了但重启后服务消失的困惑。检查状态时status 命令会展示进程状态、内存占用关键是会显示最近的日志片段这些信息能直接告诉你是配置文件有问题还是端口被占用。5.2 一个完整的排障过程服务为什么起不来光看状态说明不够我给你还原一个真实发生过的排查链路你就知道该按什么顺序找问题。某台测试机上我配置完某个 Web 服务后执行 systemctl start结果终端没有任何报错但 curl 访问就是不返回内容。第一次碰到这种情况的人很容易慌我当时的排查步骤是这样第一步systemctl status 服务名发现进程状态是 active (running)但它显示了一行bind() 到 8080 端口失败。这一步已经锁定方向不是服务没起来而是端口没绑上。第二步ss -tlnp | grep 80检查端口占用发现 8080 端口正在被另一个进程占用。为什么我的服务没报错呢因为它配置里写的端口实际上不是 8080而是 8081所以它稳稳地起来了只是监听位置和我的预期不一致。第三步ss -tlnp | grep 8081确认它确实在监听然后 curl 用 8081 验证立刻通了。这个例子说明一个重要的排障思想先确认进程到底处于什么状态再验证资源绑定情况最后才去怀疑配置内容。顺序颠倒会浪费时间。如果 status 里显示的日志不够清楚用 journalctl -u 服务名 查看这个服务的完整日志-f 参数可以实时滚动输出。5.3 让服务配置在修改后真正生效修改服务配置文件之后很多人习惯直接 restart这大多没问题但如果服务支持平滑重载用 reload 能避免中断现有连接。systemd 的管理逻辑里改完配置文件还有一步容易漏掉systemctl daemon-reload。这个命令让 systemd 重新读取 service 文件因为 unit 文件本身的改动如果不执行它即使 restart 也可能沿用旧配置。我见过不少我改了端口但系统不生效的提问一半是忘了 daemon-reload。记住这个顺序就不会错改单元文件 - daemon-reload - restart/reload 服务。实在想验证服务能否启动到一半还有个调试技巧手工执行单元文件里 ExecStart 写的那行命令。注意这只能用于排查不能替代 systemd 的完整环境变量和资源限制设置但至少能快速告诉你是程序本身的问题还是 systemd 环境的问题。6. 日志与监控第四天开始培养的排障习惯6.1 /var/log 下到底藏着什么花一个下午把日志体系摸一遍绝对值回票价。在 CentOS 系系统里/var/log/messages 记录大部分系统消息在 Ubuntu 系里对应文件是 syslog。/var/log/secure或 auth.log记录登录验证信息谁在什么时间从哪里登录成功或失败全都能查。应用日志可能分散在各自的目录比如 /var/log/nginx/、/var/log/mysql/但多数服务都遵循同一个哲学有问题来日志目录翻。看日志的第一反应应该是 tail而不是 cat。tail -f 是实时跟踪适合观察服务启动时的输出tail -n 200 是查看最近 200 行适合快速了解当前状态。更高效的做法是组合 grep 过滤关键字比如tail -f /var/log/messages | grep -i error这样终端里只会滚出包含 error 的行别的噪音全部屏蔽掉。这个组合是日常排障使用频率最高的一条命令。6.2 三个基础监控命令df、du、free系统没反映的时候第一件事通常是看资源是否耗尽。df -h 用于查看分区使用率发现根分区已经 100% 时很多奇怪问题都有了答案——应用没法写日志、登录卡顿、临时文件创建失败全是磁盘满导致的连锁反应。du -sh 加目录路径可以进一步定位是哪个目录吃掉了空间比如du -sh /var/log/* | sort -hr | head -5free -h 查看内存注意区分 total、used、available。在 Linux 里 used 很大不一定代表内存紧张因为系统会积极使用空闲内存做缓存buff/cache真正的可用内存看 available 更准确。结合前两节学的 topCPU、内存、磁盘三块就能覆盖绝大多数服务异常但没报错的场景。我现在处理问题的基本套路是先明显看一眼资源是否超限再用日志定位具体错误最后才回到代码和配置文件层面。这个顺序能让排障时间压缩到原来的三分之一。6.3 第四天的小练兵一个完整的排查闭环把今天学的内容串起来可以做这样一次模拟演练场景某应用服务运行正常但用户反馈响应很慢。先执行 top按 P 排序看哪个进程 CPU 占用最高发现是某个 PHP-FPM 进程持续 100%。用 ps -ef 找到该进程对应的请求路径发现它正在访问的是一个磁盘上很大的日志文件。再用 df -h 确认磁盘空间充足用 iostat如果有的话确认磁盘读写情况。用 tail -n 500 查看应用日志找到大量慢查询或错误记录。结合日志定位到具体接口修复后在测试环境验证再重启服务。整个过程不会用到很高级的工具但每一条命令都在前面的内容里出现过。能把它们连成一条完整的链路就是第四天最好的毕业答卷。7. 第四天结束后你应该能独立完成的十项检查最后把今天的内容压缩成一张自查清单每一项都对应一段真实操作做完这些你基本就能说我跨过系统管理这道门槛了用 useradd 创建一个带家目录、指定 shell、加入附加组的新用户并用新用户身份登录验证。用 chage 给用户设置密码过期策略。正确删除一个用户及其家目录确认没有残留文件。用数字和符号两种方式修改文件权限并解释 640、750、4755 分别代表什么。临时修改 umask 为 027新建文件验证权限变化。在共享目录上设置 setgid 位验证新文件的属组继承。用 ps aux 找出 CPU 占用最高的进程用 top 实时确认。分别用 kill -15 和 kill -9 结束两个测试进程观察行为差异。通过 systemctl 完成某个服务的启动、开机自启、状态检查。在日志目录里用 tail grep 定位一条 error 记录并说明它对应什么问题。这十项本身不要求全部记住命令参数允许查手册但要求每一条都能当场做出来。我自己的经验是第四天晚上把这些操作完整过一遍第五天开始遇到的真实问题基本不会再让你一头雾水。学习路径到这一步你就不是会用 Linux 的人而是开始能管 Linux 系统的人了。
阅读完成 · 觉得有帮助？
