Linux 的知识点太碎了。这是我写在笔记第一页的话。从最初只会敲ls和cd到后来敢改systemd服务、写自动化脚本这个过程里帮我最久的不是搜索引擎而是自己的笔记。这份 Linux 笔记不是某个课程的讲义也不是网上抄来的命令大全而是我日常折腾服务器时一点点记下来的排错思路、命令细节和踩坑记录。今天把它整理出来分享适合刚接触 Linux 的新手看也适合已经用过一段时间、却总在奇怪问题上卡住的朋友直接做参考。1. 为什么我坚持用笔记记 Linux1.1 Linux 知识点太碎记忆力靠不住我记得第一次接触 Linux 的时候光是一个tar打包解压的参数就背了三天什么czf、xzf、zxf背完第二天再看又是一脸懵。这不是什么问题Linux 本身就不是靠死记硬背学会的因为它涉及的命令数量太多参数组合又多而且不同发行版之间还有细微差异光靠脑子记肯定不现实。后来我形成了一个习惯凡是让我犹豫过的命令、凡是查了资料才搞明白的配置、凡是花了一整天才解决的报错都必须写进自己的 Linux 笔记里。不是那种“命令解释”的抄写而是“我从哪个方向排查、为什么是这个原因、下次遇到怎么快速判断”。这样记下来之后虽然不能保证永远不忘但至少下次碰到类似的问题我能很快在笔记里找到线索而不是又从man开始摸。1.2 记笔记的真正价值是逼自己理清原理很多时候你以为自己会用某个命令其实只是把别人的教程复制粘贴成功了一次。为什么find用-exec后面要加{} \;为什么crontab里写相对路径经常不好使这些细节如果不在笔记里写一遍永远都是模模糊糊的。我的做法是强迫自己在记笔记的时候补一段“为什么”。哪怕只有一句话也要写得像给同事讲解一样清楚。写不出来的地方往往是理解还没到位那就查清楚再写。这个过程非常痛苦但效果也是真的大。慢慢地我发现记 Linux 笔记逼着我把之前零散的碎片知识串成了一条线文件系统、权限、进程、网络、服务这些本来割裂的知识点被我自己的文字串到了一起。1.3 好的 Linux 笔记应该长什么样如果一份笔记只是把网上的“Linux 命令大全”搬下来那就没意义了。我自己整理笔记的时候遵循三个原则按场景分类。比如“磁盘排查”、“网络排查”、“服务排查”而不是按命令字母排序。每条笔记都写明触发条件和现象。遇到问题时先在笔记里找“对得上号”的现象。同一个问题最多留一个最终版本。解决之后再回过头来把当初折腾的中间过程删掉只留下干净有效的步骤。这样整理出来的笔记才真正变成可查询的“运维手册”。它可能不像命令大全那么全面但它保存了每一个命令在我这台机器上真实的、跑通过的用法这一点是任何网上教程都给不了的。2. 做 Linux 笔记的方法与工具2.1 我用 Markdown 按场景组织笔记工欲善其事必先利其器。我现在所有笔记都用 Markdown 记录文件分散存放在一个目录里目录下面按“系统基础”、“常见故障”、“脚本模板”等子目录划分。Markdown 的好处很明显纯文本任何机器上都能打开不用装复杂的软件可以和代码保持同样的管理方式改坏了能回滚在终端里用grep就能快速检索这个特性非常适合 Linux 人。我通常一个二级目录就是一种场景比如排查、系统、脚本。每个主题一个独立的.md文件文件名就直接写问题比如排查-cpu飙高.md、volumes满-找不到大文件.md。找的时候不用打开就大概知道里面有什么。标题用词要具体别叫问题1.md那样过一个月自己都懒得翻。2.2 笔记要记录“为什么”不只记命令举个例子。很多人笔记里写df -h查看磁盘空间du -sh查看目录大小。但如果只是这样记遇到“磁盘明明满了df -h却看不到大文件”的问题时你依然不知道怎么解决。真正有价值的笔记应该是“磁盘满了先df -h看哪个分区满再du -sh 目录/*找大目录如果都找不到可能是有已经被删除但还被进程占用的文件用lsof L1查”。这种写法的好处是把所有关联的命令放在同一个上下文里记录的是“解决一个问题的完整思路”而不是孤立的一个命令。到真正用的时候你脑子里浮现的不只是一个df -h而是一条解决问题的路径。2.3 把错误和排查过程写进笔记我在笔记里专门建了一个“报错墙”分区每一条都按固定的模板记录原始报错信息截屏或复制完整保留出问题的环境发行版、内核版本、软件版本我的排查过程每一步试了什么最终原因和解决操作预防措施这套模板看着简单但非常有效。遇到问题的时候第一件事不是百度或群里问而是先去自己的报错墙里搜关键字很多时候会发现这个问题我半年前就踩过一遍这次只要照着笔记操作就能解决。复查还可以发现当初记录的排查过程是否冗余顺便把笔记优化得更精简。3. Linux 笔记里的核心基础文件系统和权限3.1 文件系统目录每个目录到底干嘛的很多新手一上来就被/etc、/var、/usr这些东西搞晕。其实不需要背全部细节重点记住几个常用的/etc配置文件目录软件的配置大多在这里。/var动态数据比如日志在/var/log缓存经常在/var/cache。/usr系统程序和用户安装的软件很多软件装完在这里/usr/local。/tmp临时文件重启可能被清空。/home普通用户的家目录/root是管理员的。/proc虚拟文件系统展示内核和进程信息比如/proc/meminfo。/dev设备文件磁盘在/dev/sda、分区分/dev/sda1。判断一个文件该放哪里我的经验是先看它是什么性质的。配置文件放在/etc可执行程序放在/usr/local/bin日志和数据文件放在/var临时文件放/tmp。这样理解目录结构会比死记快很多。3.2 权限管理的几个关键点权限这块最容易出问题。别去死记chmod 777我会把权限理解成一串开关前三位是属主中间三位是属组最后三位是其他用户。r是读w是写x是执行。数字符号是二进制换算出来的r4,w2,x1所以 7 421代表可读可写可执行6 42代表可读可写5 41代表可读可执行。为什么要理解这个因为一个常见的坑是给配置文件执行权限其实没必要可视化目录需要执行权限才能进入。有时候你费了半天劲发现“文件能看不能打开”就是目录的x权限没了。chmod -R 755适合给目录整体统一权限但给单个私钥文件千万别这样必须chmod 600。关于属主变更chown命令很关键比如chown -R root:root /opt/app把应用目录所属统一收归 root。注意chown后面的目录如果是个服务的数据目录先想清楚里面的文件属主会不会影响服务正常工作。有些程序写不了文件不是权限问题是属主不对。这时候正确的做法是chown 服务运行用户:运行组 数据目录而不是盲目改成 root。3.3 磁盘与挂载操作笔记磁盘问题的排查大多数人都知道df -h先看分区使用率再用du -sh 目录/*一层层找大文件。我再补几个容易忽略的查看最占空间的几个文件find / -type f -size 1G -exec ls -lh {} \;查看挂载是否异常mount | grep 对应目录或者看cat /proc/mounts。手动挂载设备mount /dev/sdb1 /mnt注意别乱挂到系统目录上。修改/etc/fstab之前先备份cp /etc/fstab /etc/fstab.bak这个文件写错可能让机器起不来。还有一个超经典的坑“磁盘满了df -h显示 100%但du -sh /*加起来却对不上总额”。这通常是有大文件被删除但某个进程还攥着它的文件句柄没松手用lsof L1就能看到带 deleted 标记的进程重启对应服务或者 kill 掉它空间才会真正释放。这个经验我已经在笔记里标了五颗星。4. Linux 笔记里最常用的操作记录4.1 系统信息与硬件信息查看排查之前先确认自己在哪台机器、什么系统这句话听起来像废话但真的很重要。我常在排查到一半才发现系统版本和手册对不上。用这几个命令可以快速摸清环境查看内核和发行版uname -a和cat /etc/os-release查看 CPU 信息lscpu查看内存大小free -h查看磁盘块设备lsblk查看硬件日志dmesg | less我这里把它当成硬件层问题的第一现场。有时候你看到的报错特别诡异比如 IO 错误这时候别急着去折腾应用先看看dmesg里有没有磁盘或者内存相关的异常。硬件没查清楚就改应用配置很容易把问题搞大。4.2 排查 CPU 占用过高的三个命令这个问题出现频率很高。我的排查套路是固定的先top按大写P按 CPU 排序立刻锁定最像的那个进程。再用ps aux --sort-%cpu | head -20看完整命令行确认它到底是谁。有些进程会隐藏自己命令行看起来像正常服务名要仔细看路径。如果是多线程程序占用高还要精确定位线程top -H -p PID看到带线程号的占用列表再配合printf %x\n PID转成十六进制去日志里搜线程号。遇到 CPU 一直 100% 的情况别急着 kill。它可能是正常的批处理任务也可能是一个死循环。举个例子我之前遇到一个统计脚本因为while true的退出条件写错启动之后直接把 CPU 占满业务接口全部超时。这种问题后知后觉的话损失不小。所以看到高占用先看一眼日志和进程启动时间确认是不是业务窗口期的正常任务再决定要不要处理。4.3 服务管理与开机自启现在大部分发行版都在用 systemd服务管理基本就是一套命令启动 / 停止 / 重启systemctl start xxx、stop xxx、restart xxx设置开机自启systemctl enable xxx取消是disable查看状态systemctl status xxx它会显示运行状态、PID、最近的日志这个输出非常有用。看连续日志journalctl -u xxx -f跟tail -f一样可以实时跟踪。需要注意的是如果你自己写了一个 systemd service 文件比如放在/etc/systemd/system/demo.service修改完必须执行systemctl daemon-reload否则systemctl restart用的还是旧配置。这个坑我踩过改了半天配置重启服务一直没反应差点把服务文件重置了。[Unit] DescriptionDemo Service Afternetwork.target [Service] Typesimple ExecStart/usr/local/bin/demo --config /etc/demo.conf Restarton-failure [Install] WantedBymulti-user.target这是一个最简 service 模板记在笔记里很有用。Restarton-failure表示非正常退出才重启应付偶发崩溃非常合适。5. Shell 脚本笔记从记录到复用5.1 为什么脚本是笔记的最佳落点把一串重复执行的命令写成脚本本质上就是把操作经验固化下来。这其实就是笔记的高级形式——不是给人看的笔记而是可以直接给机器执行的笔记。我建议所有运维相关的手工操作如果要做第二次就考虑写成脚本。脚本里每一行命令都是一步操作的记录注释写着为什么这么做这样脚本本身就成了一份可执行的文档。写脚本别觉得难。只要你能在终端里手动敲通一串命令把它们按顺序写好加几个变量和判断就是一个合格脚本。遇到“明明手动能执行放到脚本里就不行”基本都是环境变量的问题。脚本执行时环境和你登录终端不一样解决方法是脚本开头显式写export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin或者把脚本里需要用到的命令都用绝对路径。5.2 常用脚本片段记录我笔记里收集了不少小片段抄几个实用的备份目录并带日期tar czf /backup/data_$(date %Y%m%d_%H%M%S).tar.gz /data等待某个端口出现再继续for i in {1..30}; do if ss -tln | grep -q :8080; then echo port 8080 is ready break fi sleep 1 done判断上一条命令是否成功command if [ $? -eq 0 ]; then echo ok else echo fail fi带颜色输出提示echo -e \033[32m[OK]\033[0m done。这些小片段看着简单组合起来就能装下很多逻辑。比如写一个启动前先检查磁盘空间、再检查端口、最后备份旧包的部署脚本整个部署流程就被你固化成了脚本不会再手忙脚乱。5.3 脚本调试经验写脚本最痛苦的是出错我把调试心得也记进了笔记执行前先做语法检查bash -n script.sh能查出语法问题不跑逻辑。跟踪执行过程bash -x script.sh它会每执行一行就打印一行对于定位变量值不对、路径错了非常有用。过滤只看关键行bash -x script.sh 21 | grep 部署。脚本开头加上set -e和set -u。前者表示有命令返回非零就立即退出后者表示使用未定义变量就报错能在错误发生的第一时间停下而不是带着错误继续跑。更严格一点可以写set -euo pipefail加上 pipefail 之后管道命令里只要有一个环节失败整体就判失败避免“命令明明出错结果还继续往下走”的尴尬。关于$?很多人判断失败习惯写成if [ $? -eq 0 ]但要注意$?只要被中间任何一条命令使用过值就变了。比如你写一行注释没问题但如果你在判断之前执行了 echo那$?就是 echo 的结果。所以建议把$?马上存到变量里再用。6. 网络排查笔记实录6.1 网络连通性排查思路网络问题的排查我有一条固定的路径先看本机网卡再看网关再看 DNS最后看目标端口。跳步容易误判。本机网卡是否正常ip addr看接口有没有 IP状态是不是 UP。网关是否通ip route查默认网关然后 ping 网关 IP。DNS 是否能把域名解析成 IPdig或nslookup。到远程主机的端口是否通telnet 目标IP 端口或nc -zv 目标IP 端口。一个很常见的现象是 ping 外网 IP 是通的但 ping 域名不通那就基本锁定是 DNS 的问题。还有个坑是ping 不通不代表网络不通有些主机或网络策略会丢弃 ICMP 包。所以排查时千万别把“ping 不通”直接等同于“断网”。6.2 端口与连接状态检查端口问题几乎是日常最高的频率。我会用的核心命令是ss它比老的netstat快信息也更清楚查监听端口和对应进程ss -tlnp这里t是 TCPl是监听n不解析服务名p显示进程。查连接状态ss -tnp能看见 ESTAB、TIME_WAIT 等各种状态。查某个端口被谁占用ss -tlnp | grep :80如果没显示进程可能权限不够换成 root 执行。端口被占用的时候先看清楚占用端口的是什么进程再决定要不要处理。别上来就kill -9万一是别人的业务服务后果很严重。如果发现一堆 TIME_WAIT 或 CLOSE_WAIT别急着调内核参数先看是不是应用没关连接或者连接池配置不对。6.3 DNS 问题排查DNS 问题表现很迷惑有时是链接缓慢有时是域名解析到错 IP。排查思路我也写在笔记里查看当前系统使用的 DNScat /etc/resolv.conf注意这个文件可能被网络管理工具覆盖。用dig short 域名快速看解析结果。用nslookup 域名 指定公共DNS对比不同 DNS 的解析结果判断是不是本地 DNS 缓存问题。用getent hosts 域名看系统调用的解析结果这个和dig不一样它会命中/etc/hosts更贴近应用实际得到的结果。排查的时候先看/etc/hosts是否写入了什么重定向再看系统 DNS 配置最后再对比公共 DNS 的解析结果。很多时候问题就出在/etc/hosts里写了一行错误的映射导致域名被指向了错误 IP。7. 常见问题排查技巧速查表7.1 权限类问题的共性“Permission denied” 是新手最容易遇到的报错排查思路其实非常固定先确认执行命令的用户是谁whoami。再看文件/目录的属主和权限ls -l。确认目标目录有没有进入权限这里最容易漏掉目录有r没x能看到文件名但进不去。如果是软件包安装写文件失败检查目标目录是否只读可以用mount看挂载参数ro就是只读。如果是执行二进制文件报权限错误检查是不是没给x权限别急着改 777先chmod x。这类问题往往不是一条命令能解决的但只要抓住用户、文件、挂载三个维度基本不会跑偏。我自己的经验是权限类报错里超过一半都是因为“目录的 x 权限缺失”或“文件属主不对”造成的真正需要改 777 的少之又少。7.2 服务起不来的排查顺序服务起不来的场景我建议按这个顺序查systemctl status 服务名看当前状态和最开始的报错。journalctl -u 服务名 -n 50看最近 50 行日志重点看stderr。查端口是否冲突ss -tlnp | grep 端口。查配置文件语法不同服务有专门的检查命令比如nginx -t、sshd -t、bash -n。如果服务文件是你自己写的确认服务名和路径都正确路径别写错ExecStart的程序要存在且有执行权限。还有一种“起一下就崩查日志没有明显错误”的情况可以试试手动执行ExecStart里的原命令前台跑一遍真实的报错通常会直接打在屏幕上这比看journalctl还要直观。7.3 记录问题时的好习惯和速查表我在前面提到过报错墙实际维护下来发现最有用的习惯有三个报错信息要完整复制不要只记一句“启动失败”。必须把错误代码和上下文一起贴上否则以后根本看不懂。把环境信息写在前面。同一段报错在旧内核和新内核上解决方法可能完全不同。每次解决完之后立刻写一句“本次教训”强制自己总结。哪怕只有一句话也比什么都不写强。笔记积累到一定量一定要做“问题索引”就是把几十个问题提炼成一个速查表每行是“现象-可能原因-参考笔记”。下面是我目前速查表的一部分现象优先检查常用命令权限拒绝属主、权限、挂载方式whoami、ls -l、mount服务起不来状态与日志systemctl status、journalctl磁盘满但空间找不回被删除但仍被占用的文件df -h、du -sh、lsof L1域名解析异常hosts 和 DNS 配置cat /etc/hosts、dig、getent hostsCPU 飙高进程和线程定位top、ps aux --sort-%cpu端口被占用占用进程和监听状态ss -tlnp、lsof -i:端口这个速查表可以放在首页一眼就能看到。每次遇到新问题我都会先确认速查表里有没有对应行没有再深入排查解决之后补上。8. 我的 Linux 笔记整理心得8.1 笔记不是抄写手册而是维护自己的索引坚持记笔记一两年后我最大的体会是笔记真正重要的不是内容本身而是你自己的索引结构。别人写的命令大全再全也不如你笔记本里那几十条亲手解决的问题记录。因为每条记录都带着你当时的上下文、当时的搜索路径、当时的坑这些是任何通用文档都无法给你的。我现在的目录结构大概是系统基础/文件系统、权限、用户管理日常操作/常用命令、脚本模板故障排查/按服务分类的排错笔记速查表/用 Markdown 表格做的索引偶尔我会发现某条笔记其实有更好的解决方案就顺手改掉旧内容。这个过程不是在维护笔记是在维护我自己的操作系统。记录的是给未来的自己看的事当然得认真。8.2 让我长期坚持的三个小技巧如果让我总结到底是怎么坚持下来的大概是这三点不追求一次写全遇到什么记什么。先记下来再慢慢完善。不要过度整理。整理笔记没有尽头够用就行。把时间留给真正的问题。定期回顾。我习惯每周五晚上翻一遍这周的笔记顺手改错别字、补细节下周碰到类似问题心里就有底。我个人现在解决 Linux 问题的标准流程是问题出现先看自己的笔记没有去查资料解决后立刻补一条笔记。这套循环一旦跑起来知识库就会越滚越厚遇到问题的底气也越来越足。最后再分享一个小技巧如果你的笔记已经有了几十条故障记录尝试照着它写几个自动化检查脚本把高频问题变成一键输出。你会发现笔记不仅帮你记忆还能帮你把经验变成工具。这是我下一步打算做的事也是我目前认为 Linux 笔记最大价值的体现。