简介本资源是面向Linux初学者与中级运维人员的实战型学习资料聚焦命令行操作、系统配置与常见故障排查通过100个典型实例覆盖网络调用、Apache服务配置、错误代码解析等核心应用场景。压缩包共204个文件以195个HTML文档为主体系统组织了参数索引、优化选项、函数属性、机器约束及警告配置等模块化内容辅以3份PDF技术说明、2个ZIP/RAR工具包、1份Word文档含经典教程和1个EXE格式人物自述整体容量40.19MB结构清晰、便于按需查阅。已有2180人学习下载读者可直接获取完整可运行的代码示例、分步骤功能调用说明、配置参数详解及典型错误解决方案尤其适合在真实环境中边练边查、快速定位问题根源并建立系统性排错思维。1. “Linux实战100例”不是题库而是你每天打开终端时该有的肌肉记忆它解决的是「命令知道但组合不会」「脚本能抄却改不动」「故障有报错却看不出哪一行在撒谎」这三类高频卡点适合刚脱离虚拟机练习、正接手真实开发/运维/测试环境的中级实践者——不是教你怎么输入ls而是教你在 CI 流水线崩掉的凌晨两点用三行管道快速定位是磁盘满、inode 耗尽还是日志轮转策略失效。这个标题背后没有神秘仓库、不绑定某本纸质书、也不依赖特定发行版。它是一套可裁剪、可验证、可嵌入日常工作的最小可行技能集每“一例”对应一个真实场景下的原子操作闭环——比如「查进程→杀残留→清锁文件→重启服务」四步必须连贯执行才算完成比如「用find找出 7 天前的大日志但跳过/proc和挂载点」这种边界必须显式处理。我带过的某高校实验室学生、某公司测试组新人、某跨平台系统交付团队在落地自动化部署前都曾用这 100 例中的前 32 例重构本地开发环境——不是为了考试是为了让make test不再因权限或路径问题失败三次才想起来要sudo。它不承诺“学完即高薪”但能确保你下次看到No space left on device报错时第一反应不是立刻df -h而是先df -i看 inode再lsof L1查被删除但未释放的句柄——这才是实战的起点。2. 用findxargsstat构建可复现的日志清理流水线从手动删到自动归档的完整闭环2.1 为什么不用rm -rf /var/log/*.log.*——时间精度、路径安全与原子性三重陷阱新手常把日志清理写成一句rm -f /var/log/nginx/*.log.*看似干净实则埋下三颗雷时间精度失控*.log.*匹配access.log.20240501.gz也匹配error.log.old.bak误删风险高路径越界若当前目录是/var/logrm -f *.log.*会删当前层所有匹配项但若脚本在别处执行且未加cd /var/log就可能删错位置原子性缺失rm删除后不可逆无压缩、无校验、无保留窗口一旦误操作无法回溯。真正可靠的清理必须满足按修改时间精确筛选 → 检查文件状态防误删 → 压缩归档而非直接删除 → 记录操作日志供审计。这四步缺一不可而find是唯一能同时承载时间判断、路径限定、动作委托的命令。提示find的-mtime参数易被误解。-mtime 7表示“修改时间超过 7 天”即 8 天及以上-mtime 7表示“恰好 7×24 小时内”但受系统时钟精度影响生产环境建议统一用-mmin 1008010080 分钟 7 天避免歧义。2.2 构建可验证的归档流水线四步命令链与每个参数的血泪经验以下命令在 Ubuntu 22.04 / CentOS 7 / Rocky 9 均验证通过无需额外安装包# 步骤1找出 /var/log 下所有修改时间超7天、后缀为 .log 或 .log.gz 的普通文件排除 /proc /sys /dev 等伪文件系统 find /var/log \ -xdev \ -type f \ \( -name *.log -o -name *.log.gz \) \ -mmin 10080 \ -print0 | \ # 步骤2用 xargs 安全传参对每个文件执行归档gzip 压缩为 .tar.gz保留原名日期 xargs -0 -I {} bash -c fname$(basename {}); dir$(dirname {}); datestr$(date %Y%m%d); tar -czf ${dir}/${fname}.${datestr}.tar.gz {} echo ARCHIVED: {} - ${dir}/${fname}.${datestr}.tar.gz | \ # 步骤3记录归档日志到 /var/log/cleaner.log含时间戳和文件数 tee -a /var/log/cleaner.log | \ # 步骤4统计本次归档总数xargs 后接 wc -l 会漏计故用 awk 计数 awk END {print Total archived:, NR, files at, strftime(%Y-%m-%d %H:%M:%S)} /var/log/cleaner.log关键参数说明-xdev强制不跨文件系统避免误入挂载的 NFS 或容器卷-print0xargs -0用\0分隔文件名彻底解决含空格、换行、括号的路径问题这是线上翻车最高发点-I {}定义占位符{}比默认的{}更明确避免与内部脚本变量冲突bash -c ...包裹复杂逻辑否则xargs无法执行多命令strftime()GNU awk 内置函数比date命令更轻量避免子 shell 开销。验证方法# 模拟生成测试日志 mkdir -p /tmp/testlog cd /tmp/testlog touch -d 2023-01-01 old.log touch -d 2024-05-01 new.log # 运行上述 find 链将 /var/log 替换为 /tmp/testlog # 预期old.log 被归档new.log 保留2.3 将流水线封装为可调度的 systemd timer告别 crontab 的 PATH 和环境变量玄学Crontab 在非交互式环境下常因$PATH缺失tar或awk而静默失败。systemd timer 则可显式声明环境、工作目录与超时策略# /etc/systemd/system/log-archive.service [Unit] DescriptionArchive old log files Afternetwork.target [Service] Typeoneshot Userroot WorkingDirectory/root EnvironmentPATH/usr/local/bin:/usr/bin:/bin ExecStart/usr/local/bin/archive-logs.sh StandardOutputjournal StandardErrorjournal TimeoutSec300 # /etc/systemd/system/log-archive.timer [Unit] DescriptionRun log archive daily at 02:00 Requireslog-archive.service [Timer] OnCalendar*-*-* 02:00:00 Persistenttrue [Install] WantedBytimers.target配套脚本/usr/local/bin/archive-logs.sh需chmod x#!/bin/bash # 此脚本必须用绝对路径调用 find/xargs/tar避免 PATH 问题 /usr/bin/find /var/log \ -xdev -type f \( -name *.log -o -name *.log.gz \) \ -mmin 10080 -print0 | \ /usr/bin/xargs -0 -I {} /bin/bash -c fname$(basename {}); dir$(dirname {}); datestr$(date %Y%m%d); /bin/tar -czf ${dir}/${fname}.${datestr}.tar.gz {} 2/dev/null echo $(date): ARCHIVED {} /var/log/cleaner.log 2/dev/null启用方式systemctl daemon-reload systemctl enable --now log-archive.timer systemctl list-timers --all | grep log-archive # 查看下次触发时间3. 用systemctljournalctlgrep快速定位服务启动失败根因从Active: inactive (dead)到Loaded: error的三层穿透法3.1 为什么systemctl status xxx只显示结果却不告诉你哪里错了systemctl status nginx输出中常见的Active: inactive (dead)或Failed状态本质是 systemd 对 unit 文件加载、依赖解析、进程启动三阶段的汇总反馈。但错误根源可能藏在任意一层Layer 1Unit 加载层nginx.service文件语法错误、路径不存在、WantedBy指向无效 targetLayer 2依赖解析层Afternetwork.target但 network.target 未激活或Requiresredis.service但 redis 未安装Layer 3进程执行层ExecStart/usr/sbin/nginx启动后立即退出因配置文件语法错误或端口被占。若只看status你会卡在「服务没起来」的表象必须用systemctl showjournalctl组合穿透三层。3.2 三层穿透命令链每一步输出都指向下一个排查方向Step 1检查 Unit 加载状态确认文件是否被正确读取systemctl show nginx.service --propertyLoadState,FragmentPath,UnitFileState若LoadStateerror说明 unit 文件本身有语法错误如[Service少了]若FragmentPath为空说明该 service 文件未被 systemd 发现路径不在/etc/systemd/system/或/usr/lib/systemd/system/若UnitFileStatedisabled需先systemctl enable nginx。Step 2检查依赖解析结果确认前置条件是否满足systemctl list-dependencies --reverse --all nginx.service | grep -E (failed|not-found|inactive)输出含network.target: failed说明网络服务未就绪需查systemctl status network.target输出含redis.service: not-found说明依赖服务未安装需apt install redis-server或补全 unit 文件。Step 3抓取进程启动时的原始 stderr定位执行层崩溃点# 获取最近一次启动的 journal 日志-n 100 防止刷屏 journalctl -u nginx.service -n 100 --no-pager | grep -E (error|fail|exit|panic|address|bind|permission) # 若无输出扩大时间范围并过滤进程 PID journalctl -u nginx.service --since 2024-05-01 | grep -A 5 -B 5 nginx:关键线索nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)→ 端口冲突nginx: [emerg] open() /etc/nginx/nginx.conf failed (13: Permission denied)→ SELinux 或文件权限问题。3.3 自动化诊断脚本三分钟输出结构化根因报告将上述三步封装为diag-service.sh支持任意 service 名#!/bin/bash SERVICE${1:-nginx} echo Diagnosing $SERVICE echo 1. Unit Load State: systemctl show $SERVICE --propertyLoadState,FragmentPath,UnitFileState 2/dev/null || echo NOT FOUND echo -e \n2. Dependency Check: systemctl list-dependencies --reverse --all $SERVICE 2/dev/null | grep -E (failed|not-found|inactive) | head -5 || echo All dependencies OK echo -e \n3. Last 20 Error Lines from Journal: journalctl -u $SERVICE -n 20 --no-pager 2/dev/null | grep -E (error|fail|exit|panic|bind|permission) | tail -10 || echo No recent errors found echo -e \n4. Process Status (if running): systemctl is-active $SERVICE /dev/null 21 ps aux | grep $SERVICE | grep -v grep || echo Service not active使用sudo ./diag-service.sh nginx输出示例 Diagnosing nginx 1. Unit Load State: LoadStateloaded FragmentPath/lib/systemd/system/nginx.service UnitFileStateenabled 2. Dependency Check: All dependencies OK 3. Last 20 Error Lines from Journal: May 05 02:15:03 server nginx[12345]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) 4. Process Status (if running): Service not active→ 根因清晰端口 80 被占下一步执行sudo lsof -i :80即可。4. 避坑Linux 实战中 5 个高频翻车点与可验证的解决路径4.1 现象find /path -name *.log -delete删除后磁盘空间未释放原因文件被某个进程打开如 tail -f /var/log/app.logdelete只移除目录项inode 仍被进程持有空间未回收。解决先lsof L1查找被删除但未释放的文件再kill对应进程或重启服务。验证命令lsof /var/log | grep deleted。4.2 现象crontab -e添加0 2 * * * /path/script.sh但脚本不执行原因crontab 默认PATH/usr/bin:/bin脚本中调用的python3或jq不在此路径或脚本无#!/bin/bash头导致解释器错误。解决在 crontab 中显式声明 PATH或改用绝对路径调用命令。验证crontab -l后手动执行env -i PATH/usr/local/bin:/usr/bin:/bin /path/script.sh。4.3 现象ssh userhost提示Permission denied (publickey)但公钥已追加到~/.ssh/authorized_keys原因~/.ssh目录权限过宽如755OpenSSH 要求700或authorized_keys文件权限非600或 SELinux 上下文异常。解决chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys restorecon -R ~/.sshSELinux 环境。验证ssh -v userhost查看 debug 日志中Offering public key是否出现。4.4 现象docker run -v /host/path:/container/path挂载后容器内文件权限为root:root应用无法写入原因Docker 默认以 root 用户挂载容器内非 root 用户如node无权访问。解决用:z或:Z标签让 SELinux 重标上下文RHEL/CentOS或在运行时指定用户--user $(id -u):$(id -g)。验证docker run --rm -v $(pwd):/test alpine ls -ld /test。4.5 现象rsync -avz /src/ userhost:/dst/传输中断后重试大量文件被重新复制原因未启用--partial保留部分传输文件和--progress显示进度且目标端时间戳未同步导致 rsync 无法判断增量。解决添加--partial --progress --delete-after并确保源/目标端tzdata一致。验证rsync -avn /src/ userhost:/dst/dry-run 模式预览变更。5. 进阶技巧用stracelsofss三件套定位「连接建立慢」的隐形瓶颈5.1 为什么curl -v http://api.example.com显示Connected to api.example.com (192.168.1.100) port 80 (#0)要等 3 秒网络层ping通、telnet 192.168.1.100 80瞬连但应用层 HTTP 请求建立连接耗时长——这通常不是网络问题而是本地 DNS 解析、glibc NSS 配置、或 socket 选项阻塞所致。strace是唯一能捕获进程级系统调用耗时的工具。Step 1用 strace 捕获连接建立全过程# 记录 curl 建立 TCP 连接的系统调用-e tracenetwork 过滤网络相关 strace -e traceconnect,sendto,recvfrom,getaddrinfo -s 200 -o curl.trace curl -s -o /dev/null http://api.example.com关键观察点getaddrinfo(api.example.com, http, ...)耗时是否 1s→ DNS 解析慢connect(3, {sa_familyAF_INET, sin_porthtons(80), sin_addrinet_addr(192.168.1.100)}, 16)返回0前是否等待→ 目标端 SYN ACK 延迟若connect后立即sendto但recvfrom长时间无返回 → 应用层协议协商问题。Step 2交叉验证 DNS 解析路径# 查看 glibc 使用的 resolver 配置 cat /etc/nsswitch.conf | grep hosts # 若为 files dns检查 /etc/hosts 是否有错误条目 grep api.example.com /etc/hosts # 直接测试 DNS 查询耗时 time dig short api.example.com 8.8.8.8 time getent hosts api.example.com # 使用系统 resolverStep 3检查本地 socket 限制与 TIME_WAIT 状态# 查看当前 ESTABLISHED 连接数是否接近 ulimit -n ss -s | grep TCP: # 查看 TIME_WAIT 连接是否堆积可能耗尽端口 ss -tan state time-wait | wc -l # 检查 net.ipv4.ip_local_port_range 是否过窄 sysctl net.ipv4.ip_local_port_range5.2 一张表锁定四类连接延迟根因现象特征strace关键线索验证命令解决方向DNS 解析慢getaddrinfo(...)耗时 1sdig快但getent慢getent hosts api.example.comvsdig api.example.com检查/etc/nsswitch.conf顺序禁用mdns4_minimalSYN 重传connect()返回前多次sendto(..., MSG_NOSIGNAL)tcpdump -i any host 192.168.1.100 and port 80检查防火墙丢包、中间设备限速TIME_WAIT 泛滥connect()失败率高ss -tan state time-wait3wss -tan state time-waithead -20glibc NSS 阻塞getaddrinfo()卡住strace -e traceopenat显示打开/etc/resolv.conf后无响应strace -e traceopenat getent hosts api.example.com检查/etc/resolv.conf权限应为 644禁用systemd-resolved干扰5.3 我的日常习惯把strace当作ps一样随身带我不再假设“网络没问题”而是把strace -e traceconnect,sendto,recvfrom -p $(pgrep -f your_app)设为快捷命令。它像黑匣子不告诉你业务逻辑但忠实地记录每一帧系统调用——当同事说“服务响应慢”我第一反应不是查日志而是 attach 进程看connect是否卡住。有一次某模拟项目X 的 API 网关在凌晨 3 点偶发 5s 延迟strace显示getaddrinfo耗时 4.8s最终定位到/etc/resolv.conf中配置了已下线的 DNS 服务器glibc 默认超时 5s 才 fallback。改掉这一行故障消失。这种确定性比任何监控图表都可靠。希望帮到你。本文还有配套的精品资源点击获取
