这篇笔记是linux初学者笔记系列的第三篇。前两篇我们聊了文件操作、目录结构、文本处理这些基本功这一篇开始进入系统管理的核心区用户权限、磁盘文件系统、进程服务、软件安装和故障排查。说句实话很多初学者学到这里就开始分叉了一部分人停留在“会用命令”的层面另一部分人开始真正理解Linux的设计思路。这篇笔记就是帮你走第二条路每条命令背后我都会解释为什么要这么干遇到报错怎么定位以及哪些坑是我亲手踩出来的。1. 用户与权限给系统立规矩1.1 新建用户不是只有一条useradd那么简单热搜词里有个“linux新建用户”很多教程只教一句useradd username然后你就发现这个用户根本登不进去连home目录都没有。真实场景下创建一个能正常登录、有家目录、能切sudo权限的用户至少要这套组合sudo useradd -m -s /bin/bash zhangsan sudo passwd zhangsan sudo usermod -aG sudo zhangsan三个命令分别解释一下-m同时创建/home/zhangsan家目录。不加这个参数你建出来的用户家目录是空的登录后直接落在根目录各种配置文件都没地方写。-s /bin/bash指定登录shell。如果不指定很多发行版会默认成/bin/sh你进去之后发现没有自动补全方向键还乱码这就是shell不对。usermod -aG sudo把用户加入sudo组。Ubuntu系用sudo组CentOS/RHEL 8以上也是sudo组但老一点的CentOS 7是wheel组这个要区分开。-aG里-a是关键意思是append追加不加-a直接-G会把用户从其他组里踢出去。很多运维事故就出在usermod -G漏了-a把用户原有的组清空了服务起不来权限乱套。这个-a务必养成肌肉记忆。补充一个检查用户信息的技巧用户建完之后用id zhangsan查看UID、GID和所属组UID从1000开始是普通用户0是root。如果想看哪些用户能登录系统直接看/etc/passwd里每行最后一个字段是/bin/bash还是/bin/nologin后者是系统服务账号不开放交互登录。1.2 文件权限为什么要分三组很多人背chmod 777背得滚瓜烂熟但一问rwx对目录到底意味着什么就卡住了。这里我用一个房间的类比破一下文件的r能看内容。文件的w能改内容。文件的x能执行。目录的r能用ls看到目录里有哪些文件名。目录的w能在目录里新建、删除、重命名文件。目录的x能cd进这个目录能访问目录里文件的实际内容。注意最后一条目录没有x权限就算你有r权限看到文件名也打不开文件内容因为路径解析需要逐级执行权限。这个组合拳在实际系统里经常坑人ls能看到文件但cat提示权限拒绝第一反应应该去查父目录的x权限而不是去查文件本身。权限还涉及umask默认创建文件的权限是666 - umask目录是777 - umask。多数发行版默认umask 022所以文件是644、目录是755。如果在一个多人协作的目录里想让大家都能改文件可以把用户的umask设成002新文件就是664配合sgid组继承一套协作目录就搭起来了。再补充两个命令排查权限时非常好用stat -c %A %a %U %G /path一条命令看权限字符、数字、属主、属组。namei -l /var/lib/mysql逐级显示路径上每层目录的权限特别适合排查“明明文件没问题但就是访问不了”的谜案。1.3 特殊权限别乱用但一定要懂chmod 777是初学者最爱的解法但真正系统管理里更值得关注的是三个特殊权限位setuid4、setgid2、sticky1。setuid给可执行文件挂上用户执行这个文件时临时拥有文件属主的权限。最典型的是/usr/bin/passwd它的权限是-rwsr-xr-x那个s就是setuid所以普通用户能通过它修改/etc/shadow里的密码。setgid对目录生效目录里新建文件自动继承目录的属组这是协作目录的标准配置。sticky最典型的是/tmp目录权限是drwxrwxrwt意味着所有用户都能在/tmp里创建文件但只能删自己创建的文件删不了别人的。多用户共享临时目录全靠这层保护。学习阶段建议别给软件加setuid很多提权漏洞就是靠setuid滥用打进来的。搞清楚这些权限位的原理更多是为了排查别人留下的问题而不是自己动手设置。2. 磁盘与文件系统别等满了才想起来看2.1 挂载、格式化与fstab“虚拟机安装linux蓝屏”这个热搜词说明很多人栽在了系统安装阶段但安装完成之后磁盘怎么管理同样有讲头。新加一块硬盘之后正确流程是分区 → 格式化 → 挂载 → 写fstab。sudo lsblk # 先看磁盘设备名一般新盘是vdb或者sdb sudo fdisk /dev/vdb # 交互式分区n新建p主分区w保存 sudo mkfs.ext4 /dev/vdb1 # 格式化成ext4文件系统 sudo mkdir /data sudo mount /dev/vdb1 /datalsblk必须放在第一步它能看到系统目前识别到了哪些块设备设备名是sda还是vda取决于虚拟化环境不先看一眼愣头愣脑去fdisk会找不到设备。格式化这步要重点说一下mkfs.ext4会彻底抹掉分区上的数据前期用测试盘无所谓真机上操作前务必确认设备名没错。我见过有人把数据盘格式化成系统盘数据的那个后悔药没地方买。最后服务重启之后自动挂载要写进/etc/fstab核心一行UUIDxxxxxx /data ext4 defaults 0 2注意千万别写/dev/vdb1 /data ...这种写法设备名在重启后可能变化UUID才是文件系统的身份证。用blkid命令查设备的UUID填进去。2.2 磁盘满了怎么定位系统报警磁盘空间满的时候正常人第一反应是df -h但只能看到分区占用比例不知道具体是谁吃掉的。排查顺序应该是df -h # 确认哪个分区满了 df -i # 确认inode够不够文件数太多也会报No space left cd /var/log du -sh * | sort -rh | headdf -i这个命令很多初学者压根没见过但它特别有价值。磁盘空间是够的但如果一个小分区上堆了几百万个小型缓存文件inode耗尽一样会报磁盘满这时候du看下来空间占用并不高真正的方向是清文件数量。定位大文件用du -sh配合sort -rh一层目录一层目录往里找。分享一个更狠的命令组合直接找出系统里最大的20个文件sudo find / -xdev -type f -size 1G -exec ls -lh {} \; 2/dev/null找出来后先判断是日志、是core dump还是别的什么再决定删不删。日志文件有logrotate管理core dump可以关不要一上来就rm -rf先弄清楚是什么再动手。2.3 删了文件空间没释放的经典场景这里分享一个我踩过三次的坑日志文件越来越大我删了/var/log/syslog结果df -h一看空间还是满的。原因是有一个进程还开着这个文件的句柄文件没有被真正删除只是从目录里“看不见”了空间被进程占着。再次遇到这种情况的处理方法sudo lsof L1 | grep deleted # 找出被删但还开着的文件 systemctl restart syslog # 重启相关服务释放句柄这个lsof L1是排查此类问题的标准入口看到deleted标记的文件句柄对应重启相关进程就解决了。记住一个原则日志可以删但真正应该做的是配好logrotate让日志按大小或时间自动滚动、压缩、清理而不是等它膨胀了再手动处理。3. 进程、服务与系统运行3.1 systemctl是新时代的“关机键”“linux系统管理”这个词范围很大但落到日常操作上接触最多的还是systemd这一套。systemctl是管理系统服务的总入口常用命令先记熟systemctl status nginx # 看服务状态、PID、最近的日志 systemctl start nginx # 启动服务 systemctl enable nginx # 开机自启 systemctl daemon-reload # 改完配置文件后重载unit定义 systemctl list-units --failed # 一键查出启动失败的服务重点说一下status输出内容的读法。第一行有Active: active (running)是正常failed是挂了inactive (dead)是配了开机自启但没启动过。看到failed不要慌先journalctl -u nginx.service --no-pager -n 50看最近50行错误日志八成是端口被占、配置文件写错语法、依赖服务没起来这三种原因之一。3.2 进程查看ps aux和top的互补关系排查性能问题进程信息是关键。入门阶段掌握ps aux和top就够用了。ps aux是一次性快照。a显示所有终端进程u显示用户和资源占用x显示没有终端的进程。输出里要关注这几个字段%CPU、%MEM、STAT进程状态、TIME进程累计消耗CPU时间。状态字段里D是不可中断睡眠通常是等待磁盘IOZ是僵尸进程R是正在运行S是睡眠。top是动态刷新版的进程监控默认按CPU排序按P按CPU排序按M按内存排序按1看每个CPU核心的负载。更现代一点的工具是htop有交互式界面能用鼠标直观很多装一下不亏。发现进程占CPU高不要直接kill先top -Hp PID看到底是哪个线程在消耗资源然后用strace -p PID跟踪系统调用看是不是卡在某个文件读写或网络等待上。这一步是区分“计算密集”和“IO阻塞”的核心手段。3.3 进程间通信的那些手段“linux进程间通信”是面试高频题现实中也是理解系统架构的关键。进程间通信的常见方式有管道、信号、共享内存、消息队列、套接字。管道最直观的就是cmd1 | cmd2前一个命令的输出是后一个的输入。信号kill -TERM PID发SIGTERMkill -9 PID发SIGKILL。TERM是礼貌地请进程收拾东西走人KILL是强制杀死。先尝试TERM不行再用KILL。共享内存多进程直接读写同一块内存效率最高但要处理同步问题。套接字既能本机通信也能网络通信Unix domain socket用于本机TCP socket用于跨机。消息队列进程之间通过队列传递结构化消息解耦生产者和消费者。初学阶段把管道和信号用好配合socket的理解就够用了。信号里还藏着一个特别实用的场景查看服务是都能平滑重载配置很多服务支持kill -HUP PID重读配置文件不需要重启进程。比如nginx就支持nginx -s reload实现同样的效果。4. 软件安装、源配置与编译环境4.1 apt、yum、dnf的底层逻辑Linux装软件无非三条路包管理器、源码编译、容器镜像。包管理器是主流Debian系的命令是aptRed Hat系新版是dnf老版本是yum。做源操作时习惯上先update再install。sudo apt update # 拉取软件索引 sudo apt install nginx # 安装软件 sudo apt remove nginx # 卸载但保留配置文件 sudo apt purge nginx # 卸载并清除配置有个细节我一直强调Ubuntu/Debian里通过apt安装的软件服务会被systemd自动接管所以装完nginx直接用systemctl status nginx就能查状态。如果手动编译安装的软件则要自己写service unit文件这是另一套玩法难度上了一个台阶。4.2 换源的正确姿势以Debian为例镜像源是软件安装的生命线默认官方源在国内下载速度感人换成国内开源镜像站体验提升巨大。“debian gnu/linux 13 trixie换清华源”就是典型场景。操作三步走sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo nano /etc/apt/sources.list sudo apt updateDebian 13 Trixie的源内容大致是deb https://mirrors.tuna.tsinghua.edu.cn/debian/ trixie main contrib non-free non-free-firmware deb https://mirrors.tuna.tsinghua.edu.cn/debian/ trixie-updates main contrib non-free non-free-firmware deb https://mirrors.tuna.tsinghua.edu.cn/debian-security/ trixie-security main contrib non-free non-free-firmware备份那步不是走过场出了问题最少能恢复到官方源。换完源apt update如果有GPG签名报错常见原因是网络中间层影响或系统时间不对先date看时间差得太远就直接影响签名校验。更新源之后如果遇到release文件过期其实也可能是镜像站同步延迟等十几分钟再update通常就好了。4.3 Linux下玩转Python和GCC“linux系统安装python”和“linux下载gcc编译器”这两个词条基本覆盖了开发环境搭建的两大件。现代Linux发行版默认都带Python3先验证python3 --version pip3 --version如果没带或者版本太老用apt装sudo apt install python3 python3-pip python3-venv装好之后强烈建议用venv隔离项目依赖。直接往系统Python里pip装包是个坏习惯不同项目依赖冲突了头大python3 -m venv myenv source myenv/bin/activate pip install requestsGCC编译器同理Debian系装build-essentialsudo apt install build-essential gcc --version装完之后写个hello world验证一手#include stdio.h int main(void) { printf(hello, linux\n); return 0; }编译、执行gcc hello.c -o hello ./hello补充一个工具链的概念。build-essential装的是编译器加make等构建工具源码安装Python时你需要的其实是它的依赖libssl-dev、zlib1g-dev这些缺了编译会报各种“找不到头文件”的错。这也是“源码编译”和“包管理器安装”的一个体验差距。5. 系统时间、日志与排错思路5.1 时间同步没配好证书先崩给你看“linux查看系统时间同步时间”这词条看着基础但现实里时间偏差导致的故障能让人debug到怀疑人生。HTTPS证书校验、Kerberos认证、数据库主从同步全依赖时间准确。时间管理这一块命令并不复杂date # 看系统时间 timedatectl # 看时区和NTP服务状态 timedatectl set-timezone Asia/Shanghai # 设时区服务端时间同步用chrony还是ntp取决于发行版Ubuntu新版默认chrony查看sudo systemctl status chronyd chronyc sources -v # 查同步源状态如果没配同步最简单的处理是sudo apt install chrony -y sudo systemctl enable --now chrony时间同步为什么值得花篇幅讲因为大部分“莫名其妙就报错”的场景最终都指向时间漂移。排查报错时顺手看一眼date和timedatectl成本极低收益极高。5.2 journalctl是日志排错的第一站“linux系统故障案例”搜索量很大说明大家遇到故障的第一反应是搜答案而不是系统地看日志。故障排查的第一站应该是systemd的journal日志。journalctl -xe # 查看最近的错误-x补解释 journalctl -u nginx.service -n 50 --no-pager # 看指定服务最近50条 journalctl -f # 实时跟踪日志流拿到日志之后怎么从一大片内容里提炼出关键信息先看错误级别error、fatal、critical优先处理。再看时间线把服务启动失败前后两分钟内的消息拉出来对比。最后把关键字丢进搜索引擎或者官方文档查。日志始终是排错的第一性原理比碰运气改配置靠谱得多。5.3 故障案例实录从根因到解决的三步走这节把我真实排过的几个故障完整写出来方便初学者感受整个思路。案例一Debian换源后apt update报GPG错误报错长这样The following signatures couldnt be verified because the public key is not available。排查思路先想清楚源地址变了签名密钥可能没变也可能新旧不匹配。处理方法是手动导入镜像站的密钥或者干脆用apt-get update --allow-unauthenticated临时绕过不推荐。更稳妥的做法是把sources.list切回官方源确认能正常update再考虑换源的事。案例二虚拟机安装Linux蓝屏这个热搜词基础但不失代表性。虚拟化环境里装Linux蓝屏第一排查点是CPU虚拟化功能没开BIOS里VT-x/AMD-V被关了第二排查点是下载的镜像文件不完整用校验工具核对SHA256第三是内存分配太小至少给2GB再启动桌面包。顺序是硬件虚拟化、镜像完整性、资源分配。案例三删除文件夹命令的教训“linux删除文件夹命令”也是热搜词。rm -rf /some/dir/是危险命令系统里不存在回收站删了就没了。我建议把危险操作的保护变成习惯先用ls -la确认路径没有拼错再改成rm -r /path/先不带-f看它列出来要删什么确认无误再加-f。命令层面更稳妥的是用trash-cli临时替代rm至少能救回一次手误。6. 命令之外的软技能6.1 文档和帮助是Linux自带的“说明书”学了这么多命令一定要养成查文档的习惯。任何命令先看help再看man pageman ls # 查看命令手册 info ls # 更详细的完整文档man页面里最实用的功能是搜索进/加关键字就能定位按q退出。再补充一个查询哪里装了什么命令的方法which nginx whereis nginxwhich返回命令的实际路径whereis还能同时告诉你二进制、源码、文档的位置。6.2 习惯一行一验证不要太相信记忆力初学者的通病是看完教程觉得懂了然后不练下次遇到又忘。我的建议是每学一个命令就在自己的虚拟机里跑一遍然后回忆一下这个命令输出的每一列是什么意思。比如ls -lh输出里文件大小显示4.0K它其实是4个512字节block还是别的什么想过一遍就明白了一个概念。漫无目的地刷命令列表没有意义有意义的是把一个命令在不同场景下的输出反复看到烂熟下次瞄一眼就能嗅出异常。6.3 写自己的笔记比收藏别人的笔记重要这个系列笔记是第三篇我写它的方式是把经验总结成一篇能回头看的东西。自己在踩坑之后写十条笔记比收藏别人的一百条技巧有用得多。原因很简单笔记是围绕你的知识缺口写的收藏夹里的内容是围绕别人的视角写的。我建议你建一个本地目录比如~/notes/linux/每个主题建一个markdown文件遇到问题就追加一条注明日期、现象、排查过程和最终结论。三个月后回看这基本就是你自己的“运维故障案例库”面试和排错都用得上。系统管理这条路没有捷径但走对方向能少绕很多弯。每一步操作前先想明白“为什么会这样”而不是“怎么才能把报错压下去”进步会快得多。