Linux系统环境与基本命令这块内容我断断续续在服务器上折腾了六七年从最开始只会敲ls和cd到现在能独立排查线上问题、写点自动化脚本过程中踩过的坑确实不少。网上关于Linux的教程一抓一大把但大多数要么是零散命令的堆砌要么是纯理论的书本知识看完还是不知道在真实环境里该怎么用。这篇内容我打算换一种讲法——不按命令字典的顺序去罗列而是从“我来一台新机器接下来会做什么”的视角把系统环境搭建、账号管理、目录规划、软件安装、网络排查、进程管理这些最常用场景串起来把基本命令融入真实操作里顺带解释清楚每条命令背后的思路和原理。1. Linux环境怎么来先从搞到一台可用的系统开始1.1 环境准备的三条主流路线没环境就没法谈命令。初学者问得最多的问题其实是“我在Windows上怎么练Linux”。根据我自己的经历有三条路线适合不同情况路线一虚拟机方案适合零基础系统学习用VirtualBox或VMware装一个Ubuntu Server或Rocky Linux内存分配2到4GB磁盘按30到50GB给。这个方案的好处是随便折腾密码忘了、系统崩了直接删除重装不影响宿主机。我早期就是拿虚拟机练手前前后后装了不下二十次系统每次重装后手动配置一遍环境不知不觉就把系统安装、分区、网络配置这些基础全练熟了。路线二云服务器适合有真实部署需求花钱买一台按量付费的云主机地域选离自己近的系统镜像选CentOS Stream、Rocky Linux或Ubuntu LTS版本都可以。这条路更贴近生产环境因为云服务器是固定公网IP要自己配置安全组规则要处理SSH密钥登录后面部署服务的时候还涉及防火墙、域名解析这些。相比虚拟机云服务器需要考虑的东西更多但也正是这种“不稳定感”逼人成长。路线三WSL适合只写代码不想折腾的开发者Windows下跑WSL确实轻量启动快和Windows文件系统互通也做得好。但要注意版本问题镜像里“wsl needs updating”那个提示通常是WSL版本过旧在管理员PowerShell里执行wsl --update就能解决。WSL适合日常写脚本、跑Python服务但它和原生Linux环境在systemd支持、网络模式上有差异如果目标岗位是服务器运维我不太建议只依赖WSL学命令。提示我遇到不少用虚拟机装Linux时蓝屏的情况排除硬件兼容问题之后多半是Hyper-V和VirtualBox的虚拟化冲突。安装前先确认Windows功能里Hyper-V是否开启如果开启就关掉或者直接改用Hyper-V自带的虚拟机创建。1.2 登录进系统后第一件事看版本和环境信息装好系统登录进去那一刻先别急着敲各种命令花两分钟确认自己到底在什么环境上干活。命令本身很简单# 查看内核版本 uname -a # 查看操作系统发行版本 cat /etc/os-release # 查看CPU、内存、磁盘信息 lscpu free -h df -hT # 查看网络IP ip addr show这些信息在后续配置软件源、安装驱动、排查性能问题时会反复用到。比如用cat /etc/os-release看到系统是Rocky Linux 9.3那软件源就要用对应版本的AppStream和BaseOS仓库看到内核是5.14开头就能判断系统里某些老模块可能不兼容。整体思路就是先知道自己站在哪块地基上再决定下一步怎么走。2. 命令体系的核心逻辑别死记硬背先理解结构2.1 命令行输入的三段式结构接触过一段时间Linux之后我发现几乎所有命令都遵循同一个结构命令名 选项 参数。比如分析这句useradd -m -s /bin/bash zhangsanuseradd是命令名表示创建用户-m和-s是选项-m表示自动创建家目录-s表示指定登录shellzhangsan是参数表示要操作的用户名把命令拆成这个三段式遇到没见过的命令第一反应就不是死记整条命令的意思而是分别去查“这个命令是干什么的、有哪些选项、后面跟什么参数”。用man命令可以查看最详细的说明但有时信息量太大我更常用命令名 --help快速过一遍关键选项。比如useradd --help输出会明确列出每个选项的用途。看多了之后慢慢会发现很多命令的选项是有共性的-f通常与配置文件相关-v通常是显示版本或详细输出-y在安装类命令里表示跳过确认。有了这个通用意识上手新命令的效率会高很多。2.2 绝对路径与相对路径文件系统导航的基础认知文件系统是Linux命令操作的重头戏。理解绝对路径和相对路径的差别决定了你写的脚本能不能在任何目录下正常运行。绝对路径是从根目录/开始描述的完整路径比如/etc/nginx/nginx.conf不管当前在哪个目录这个路径指向的文件都是同一个。相对路径则是相对于当前目录的位置比如../logs/app.log表示上一层目录里的logs文件夹下的app.log。实际业务里最常见的错误之一脚本里写了相对路径用cron定时任务执行时却找不着文件。原因就是cron执行时的工作目录通常不是脚本所在目录而是root的家目录。我自己写脚本涉及文件操作的路径一律用绝对路径除非是纯交互式操作确认当前目录没问题。文件路径相关的命令就几个组合起来基本能覆盖日常工作pwd # 查看当前所在绝对路径 ls -lah # 查看目录内容按人类可读格式显示大小 cd /opt/apps # 切换目录 tree -L 2 # 查看两层目录树结构顺便说一个细节ls -lah里的-a会显示以点开头的隐藏文件比如.env、.gitignore。很多配置文件的坑都在隐藏文件上刚接触时忘了加-a参数翻来覆去找不到文件到底在哪。2.3 英文帮助读不懂怎么办定位关键选项的实用方法必须承认全英文的 man 手册和--help输出对初学者有门槛。我的方法是先不看解释直接执行一遍看效果再对照选项反推。比如ls -l输出会显示一个7到10列的列表第一列是权限位第三第四列是属主和属组最后一列是文件名。执行几次之后列的含义自然就记住了完全不用背。还有一个技巧是用grep过滤帮助文本快速定位自己关心的选项。比如不知道怎么用tar排除某个目录时tar --help | grep exclude输出里会明确给出--exclude的写法。这个习惯帮我节省了大量查资料的时间靠的是“先知道有这个东西再精确看用法”的思路。3. 目录规划与文件操作一套能用于生产环境的通用模型3.1 Linux目录结构里你真正需要记住的五个位置Linux的FHS文件系统层次结构标准定义了整个目录树的用途。但刚上手时没必要全记真正高频的是这几个目录用途我的使用习惯/etc配置文件目录改任何服务配置之前先备份改完查验证/var/log日志文件目录排查问题第一站tail -f跟踪日志/opt第三方软件安装目录手动解压安装的软件放这里统一管理/tmp临时文件目录系统重启会清理不能放重要数据/home普通用户家目录源码编译、个人脚本都放自己家目录下写代码或者部署服务时我也会遵守一个约定程序代码放/opt或家目录下日志数据放/var/log下临时文件放/tmp下。这样做的好处是磁盘空间排查时一眼就能定位应用日志如果异常膨胀直接看/var/log下对应服务的文件大小部署包版本迭代时/opt下每个版本一个目录回滚就是切换软链接的事。3.2 文件创建、复制、移动、删除权限意识是第一课常用文件操作命令我从实际场景出发列一下怎么配着用# 创建多级目录 mkdir -p /opt/apps/backend/logs # 创建空文件 touch /opt/apps/backend/start.sh # 复制文件并保留权限属性 cp -a /opt/apps/backend/start.sh /opt/apps/backend/start.sh.bak # 移动文件到另一目录 mv /opt/apps/backend/config.yml /opt/apps/backend/config.yml.local # 删除前先看清楚 ls -lah /opt/apps/backend/ rm -rf /opt/apps/backend/logs/这里比较关键的意识就是rm -rf的杀伤力。我在生产环境删除任何东西之前都会先ls确认一遍路径和内容尤其是变量拼接绝对路径的场景。早期有一次写清理脚本变量没取到值结果rm -rf /差点把系统文件全删了。再强调一遍注意在脚本或命令行中凡是删除操作先确认变量非空再用set -u把未定义变量当成错误处理或者用test -d检查路径确实存在后再执行。3.3 权限位、属主和属组chmod与chown实操口径权限问题几乎每天都碰到跑个脚本提示 Permission denied启动服务说日志目录写不进去十有八九就是权限位或属主不对。Linux权限模型的基础是一个文件的权限分三组属主u、属组g、其他用户o每组有读r4、写w2、执行x1三种权限。数字表示法就是这三组数字拼起来比如755代表属主可读可写可执行属组和其他用户可读可执行。# 赋予脚本文件执行权限 chmod x /opt/apps/backend/start.sh # 修改属主和属组 chown -R appuser:appgroup /opt/apps/backend/ # 递归修改目录权限 chmod -R 750 /opt/apps/backend/实际中我比较推荐用750和640这类更严格的权限而不是一上来就777。用777虽然省事但任何用户都能改你的文件这在生产环境是安全隐患。工作里的规范是文件一般644目录一般755如果涉及敏感配置比如数据库密码就收紧为640或600。3.4 文本处理三件套grep、awk与sed的真实用法日常运维中处理文本的频率非常高最核心的三个命令是grep、awk、sed其定位可以大致这么理解grep按关键字过滤行awk按列取内容做统计和格式化sed按规则替换文本做增删改举一个我处理线上日志的真实例子。某个服务高峰期报错多我需要统计接口报错次数Top5的原因命令可以这样写grep ERROR /var/log/backend/app.log | awk {print $NF} | sort | uniq -c | sort -rn | head -5分步拆解一下grep ERROR过滤出所有报错行awk {print $NF}取每行最后一个字段通常是错误码sort排序让相同错误码相邻uniq -c统计出现次数sort -rn按次数从大到小排head -5取前五。这个管道链的思路比单独记某一条命令更有价值——遇到新的日志格式改一下字段位置就行。sed在批量替换时更高效。比如要把配置文件里旧域名换成新域名sed -i s/old-domain.com/new-domain.com/g /etc/nginx/conf.d/app.conf-i表示直接写入原文件s表示替换操作g表示全部替换。日常改配置时我会先不加-i执行一遍确认输出结果没问题再加上-i真正写入文件避免一次改错回不去的尴尬。4. 用户与权限管理多人共用服务器时必备的安全边界4.1 新建用户与组基于角色的分配思路服务器不可能只有root一个人用。多人团队共用的机器最基础的安全隔离就是为每个人创建独立账号按项目组去划分权限边界。常用的命令组合# 创建组 groupadd ops # 创建用户并指定家目录和shell useradd -m -s /bin/bash zhangsan # 设置密码 passwd zhangsan # 将用户加到附加组 usermod -aG ops zhangsan # 查看用户所属组 id zhangsan这里有两点经验值得多说一句。一是usermod -aG一定要带-aappend参数不加的话会把用户从原来的附加组中全部移除只保留当前指定的组这个坑很容易造成用户权限突然丢失二是新用户刚创建时建议先设置一个临时密码要求其首次登录后自行修改避免长期使用同一个共享密码。4.2 sudo与提权控制root权限使用红线很多初学者图方便长期用root直接操作服务器我强烈建议不要这样。root的权限太大一个命令失误就可能造成整个系统不可用。更合理的方式是给需要管理权限的人开sudo权限并且精细化控制。在/etc/sudoers.d/目录下建一个独立配置文件比如10-ops内容可以这样写zhangsan ALL(ALL) NOPASSWD: ALL这表示zhangsan可以在任何主机上以任何用户身份执行任何命令且不要求输入密码。但实际更安全的做法是按需授予比如只允许执行系统更新和重启服务的权限zhangsan ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/dnf update -y需要强调的一点团队里不同角色对服务器的操作需求差异很大。开发同学可能只需要查看日志、重启特定服务测试同学只需要操作测试环境。把sudo权限精确到命令级别能明显减少误操作和配置被乱改的风险。执行visudo之前会自动校验语法所以修改完千万别手动直接改/etc/sudoers规范做法是visudo -f /etc/sudoers.d/10-ops语法不对时会拒绝保存这样能避免把自己锁在门外。4.3 密码过期与登录控制安全策略的落地团队服务器上一个容易被忽视的策略是密码过期提醒。默认情况下系统账户密码可以长期不修改但安全意识强一点的环境里通常会要求定期改密。用chage命令可以管理密码过期策略# 查看密码过期信息 chage -l zhangsan # 设置密码90天后过期过期前7天提醒 chage -M 90 -W 7 zhangsan如果在系统日志或登录提示里看到密码过期的相关信息不要觉得只是烦人的提醒这是安全策略在生效。操作上普通用户登录时被提示密码过期需要立即改密这个交互流程本身也是系统密码策略的一部分配合双因子验证效果更好。提示在配置自动化任务时如果用了服务账号比如svc_app建议把它的密码过期策略设为永久有效chage -M -1否则某天凌晨3点cron突然跑不了任务排查半天发现是密码过期导致认证失败就很被动了。5. 软件安装与仓库管理从yum/dnf到源码编译5.1 用系统包管理器装软件仓库选对是第一步大多数Linux发行版都自带成熟的软件包管理器。Debian系用aptRed Hat系RHEL、Rocky、CentOS Stream用yum或dnf。安装软件的第一原则就是能用系统包的用系统包能在官方仓库找到的绝不额外下载安装包。以Rocky Linux 9为例一些常用操作# 更新软件源缓存 sudo dnf makecache # 安装常用工具 sudo dnf install -y vim wget curl net-tools unzip # 搜索某个包 sudo dnf search nginx # 查看已安装包 sudo dnf list installed | grep nginx # 卸载软件 sudo dnf remove -y nginx系统包管理器的好处是依赖关系自动处理卸载也干净升级维护都统一走包管理渠道。但是仓库自带的软件版本通常偏旧比如某些开发工具需要更新的版本这时就需要考虑第三方的软件源或者直接用官方提供的安装脚本。配置第三方源时关键是找官方和可信的源。比如安装Docker方法就是在官网下载对应的仓库配置文件放到/etc/yum.repos.d/下然后执行dnf install docker-ce docker-ce-cli containerd.io。我之前碰到过从乱七八糟的源安装Docker结果服务一直报奇怪的依赖错误折腾一天后换成官方源半小时就解决了。配置源之后一定要dnf makecache更新缓存再装包。5.2 离线环境安装没有外网也能装软件的办法很多公司内网服务器并不能访问外网软件安装就成了一个麻烦点。离线安装有两条路一是在有网的机器上下载好安装包再拷贝进去二是在内网搭建本地软件仓库。以CentOS/Rocky环境跑离线安装Python包为例若目标机器上没有外网却要装requests库可以在有网的机器上执行pip download requests -d /tmp/packages/然后把/tmp/packages整个目录拷到离线机器上pip install --no-index --find-links/tmp/packages/ requests系统级RPM包同理可以用dnf download下载指定包及其依赖再拷贝到目标机器上用rpm -ivh *.rpm安装。离线机器上最常遇到的问题就是依赖链太长漏掉一个依赖包就会导致安装失败。经验做法是下载时把依赖关系完整列出来dnf download --resolve --alldeps nginx5.3 源码编译安装为什么仍然值得学虽然系统包管理器便捷但源码编译安装这个技能我一直建议掌握。原因很简单某些软件版本发行时只发布源码包而且编译安装能自定义编译参数软件安装路径也更灵活。标准流程大致是# 下载源码包 wget https://example.com/app-1.2.3.tar.gz # 解压 tar -xzf app-1.2.3.tar.gz cd app-1.2.3 # 配置编译参数 ./configure --prefix/opt/app # 编译并安装 make -j4 make install编译过程中最常踩的坑就是缺少依赖库报错信息里通常都会明确指出缺哪个头文件或库。比如提示libssl-dev没找到那就先通过包管理器把对应的devel包装上再重新编译。./configure --prefix/opt/app指定安装目录这个习惯我从一开始就坚持这样卸载时直接删掉整个目录即可不会污染系统其他位置。6. 网络排查与远程管理分离机和远程两种情况6.1 网络配置基础IP、网关、DNS与连通性排查服务器网络问题排查算是日常工作中最高频的场景之一。网络命令不需要记很多但核心几个必须熟练# 查看当前IP和网卡状态 ip addr show # 检查默认路由 ip route show # 测试到某个IP的连通性 ping -c 4 8.8.8.8 # 查看DNS解析是否正常 nslookup example.com # 追踪网络路径 traceroute example.com排查网络问题的一个通用思路是从底层往上走。先确认网卡和IP配置ip addr再检查网关ip route然后测试外层连通ping网络通了再测DNS解析nslookup。如果IP配置对了还是Ping不通网关就要关注物理链路和驱动了嵌入式环境里还涉及phy芯片是否工作、网口是否up这类问题可以查网卡状态中的state UP字样并留意内核日志中是否有网口link down的记录。6.2 SSH远程登录从密码到密钥的安全演进远程管理Linux服务器最常用的方式是SSH。刚入门的时候可能直接用密码登录但生产环境一定要换成密钥登录。基本操作# 生成本机密钥对 ssh-keygen -t ed25519 -C your_emailexample.com # 将公钥上传到服务器 ssh-copy-id userserver_ip # 登录服务器 ssh userserver_ip生成密钥时建议用ED25519算法长度短、安全性足够兼容性也广。上传公钥之后可以在服务器上修改SSH配置vim /etc/ssh/sshd_config将密码登录关掉PasswordAuthentication no PubkeyAuthentication yes修改完记得执行sudo systemctl restart sshd。这里强调一个实操习惯修改SSH配置前先保留一个已登录会话等新配置验证没问题再退出否则密钥配置出错又关了密码认证那你只能通过管理终端去救非常被动。如果登录特别慢卡在输入密码前好几秒常见原因是DNS反向解析超时在sshd配置里加一行UseDNS no再重启服务即可。6.3 端口监听与服务检查案发第一现场排查服务是不是真的在运行单看进程存在是不够的必须看端口监听状态。最常用的是# 查看端口监听情况 ss -lntp # 查看指定端口 ss -lntp | grep 8080 # 测试本地端口是否可达 curl -v http://127.0.0.1:8080/healthss的输出里能明确看到监听地址、端口以及对应的进程名。比如数据库默认在3306端口Nginx在80和443如果端口没监听多半是服务没起来或者配置的监听地址不对。curl -v还会显示完整的请求响应头和连接过程是定位HTTP服务问题的利器比如查看响应状态码、以及TLS握手是否正常。7. 进程与日志定位系统异常的两把钥匙7.1 查看进程与资源占用top和ps配合使用服务跑着跑着变慢了第一件事就是看系统和进程的资源占用。常用命令是top和ps。# 实时查看系统资源占用按CPU或内存排序 top # 查看特定进程的详细信息 ps -ef | grep nginx # 动态查看某进程的线程情况 top -H -p 12345实际使用中top的交互命令值得记几个按P按CPU使用率排序按M按内存使用率排序按c显示完整命令行。排查服务器负载过高时我会先把top打开按CPU排序如果某个进程CPU占用接近100%再结合ps -ef看清楚完整启动参数和对应的工作目录判断是正常业务流量升高还是代码出现了死循环或异常请求。还有一种情况是内存问题。free -h看到可用内存很低但进程本身不大可能是缓存占用。Linux内存策略里释放内存最安全的方式是通过echo 3 /proc/sys/vm/drop_caches清理缓存但这只是临时手段真要排查还得看具体是哪个进程在持续吃内存用ps aux --sort-rss | head能看到内存占用最高的进程排行。7.2 日志文件分析从tail到journalctl日志是无声的证人。排查问题永远是从日志开始找线索而不是瞎猜。最常用的日志操作# 实时跟踪日志输出 tail -f /var/log/app/app.log # 查看最后100行 tail -100 /var/log/app/app.log # 按关键字过滤日志 grep -i error /var/log/app/app.log | tail -20 # 使用systemd日志 journalctl -u nginx --since 10 minutes agojournalctl在systemd系统上用得很普遍-u指定服务名--since按时间段过滤比翻/var/log/messages方便不少。日志分析最重要的能力是把零散的信息串成时间线什么时间服务开始报错报错之前系统发生了什么操作比如发布版本、修改配置、磁盘写满顺着时间线找根因基本都能浮出来。注意日志文件磁盘占用过高的时候不能用rm直接删正在被进程写入的日志文件否则空间不会真正释放。正确做法是cat /dev/null /var/log/app/app.log清空文件但保持文件句柄有效。7.3 进程间通信与后台任务Linux进程管理的几个侧面理解进程管理光会kill肯定不够。实际运维中经常会用到“进程间通信”和“后台运行”这两个概念。Linux进程间通信的常见方式有管道|、信号kill -HUP、共享内存、Socket等。管道我们前面已经用过了比如grep和awk之间的组合就是在做进程间数据传递。信号机制里kill -HUP pid经常被用来让守护进程重新加载配置而不中断服务Nginx graceful reload用的就是这个信号。实际调试时查看某进程暴露的Socket和文件描述符可以用lsof -p pid。后台运行任务也有讲究。直接执行命令会占用当前终端关闭终端任务就被挂断。正确做法是# 使用nohup后台运行 nohup python run.py /var/log/app/run.log 21 # 使用systemd管理服务 sudo systemctl start myappnohup是为了让进程在终端退出后继续运行21是把标准错误也重定向到同一个日志文件如果不加这个报错信息不会进日志排查问题时会少一半线索。生产环境里工作能用systemd管理服务就尽量别用nohup服务异常退出时systemd可以自动拉起崩了也有状态可以查询。8. 环境变量与Shell脚本从手动到自动化的跨越8.1 环境变量PATH和JAVA_HOME这类配置为什么重要环境变量是Shell和程序之间的桥梁。最常遇到的就是“明明安装了软件却提示命令找不到”这大多是因为PATH环境变量没有包含软件安装目录。比如把软件装在/opt/maven/bin那当前输入mvn找不到是正常的因为Shell不在PATH指定的目录里找。解决办法就是在环境变量配置文件中追加路径。系统级可以改/etc/profile用户级改~/.bashrc或~/.bash_profile# 编辑用户级配置 vim ~/.bashrc # 在文件末尾追加 export PATH/opt/maven/bin:$PATH export JAVA_HOME/opt/jdk17 export PATH$JAVA_HOME/bin:$PATH # 让配置立即生效 source ~/.bashrc # 确认生效 echo $PATH which mvn有一个细微但重要的区别/etc/profile对登录Shell生效而~/.bashrc对交互式非登录Shell生效。按我的习惯用户级自定义环境变量统一放~/.bashrc系统级全局变量放/etc/profile.d/下新建独立脚本文件而不是直接改/etc/profile这样维护起来结构清晰也不会因为个别配置写错影响全局登录。8.2 一个能用在服务器上的自动化脚本示例手动执行命令只能解决一次性的问题真正提升效率的是把常用操作封装成脚本。我来写一个实际可复用的清理脚本示例它的功能是清理指定目录下N天前的日志文件并记录清理结果到日志#!/bin/bash # 需要清理的日志目录 LOG_ROOT/var/log/backend # 清理7天前的文件 DAYS7 # 清理记录 CLEAN_LOG/var/log/cleanup.log # 判断目录是否存在 if [ ! -d $LOG_ROOT ]; then echo $(date %Y-%m-%d %H:%M:%S) [ERROR] $LOG_ROOT 目录不存在 $CLEAN_LOG exit 1 fi # 统计待清理文件数量 file_count$(find $LOG_ROOT -type f -mtime $DAYS | wc -l) # 执行清理 find $LOG_ROOT -type f -mtime $DAYS -exec rm -f {} \; # 记录结果 echo $(date %Y-%m-%d %H:%M:%S) [INFO] 清理完成本次清理文件数: $file_count $CLEAN_LOG几个值得琢磨的细节一是-mtime 7表示修改时间距今超过7天注意单位和逻辑容易写反二是先用wc -l统计数量再实际删除日志里能看出每次清理的量方便判断业务日志增长趋势三是关键路径一定要判断存在性再操作这是从“删库”惨案里吸取的教训。把脚本放到cron定时任务里每天凌晨执行一次0 2 * * * /opt/scripts/clean_old_logs.sh /var/log/cleanup_cron.log 21这里顺手提醒一下cron环境下PATH环境变量比交互式Shell少很多如果在脚本里用了某个程序的命令最好在脚本开头写明完整路径。比如Python的路径可以先用which python3查出来然后脚本里直接用/usr/bin/python3。9. 常见问题与排错实录这些坑我替你踩过9.1 权限拒绝类问题现象运行脚本提示Permission denied执行sudo命令也提示没有权限。排查步骤先ls -l确认文件的执行位是否存在再看属主是否是当前用户。如果是自己创建的脚本chmod x即可如果是在别人目录下的脚本则要考虑是否用对用户或者通过sudo执行。踩坑经历有一次线上服务的启停脚本在处理备份时一直报错排查发现是脚本执行用户对备份目录没有写权限而之前一直没注意到是因为测试环境用了root跑的到了生产环境换成普通用户就暴露了。从这个教训之后我写部署脚本都默认以普通用户身份检查一遍全部流程再交给运维。9.2 端口占用问题现象服务启动时报Address already in use。排错方法# 找到占用端口的进程 ss -lntp | grep 8080 # 根据PID查看进程详情 ps -ef | grep PID # 确认后再结束进程 kill -9 PID有一种容易误判的情况ss查到端口被一个PID为1的进程占用systemd这通常是其他进程通过socket传递给了systemd或者之前有进程被强行kill但socket没释放。此时需要结合进程启动时间和上下文排查不要盲目kill掉PID 1。9.3 软件源与架构不匹配问题现象dnf install提示找不到包或者安装的包无法使用提示架构不兼容。排查思路uname -m确认系统架构x86_64还是aarch64对照软件源配置文件里的baseurl是否匹配当前架构。还要确认系统版本是否在源支持范围里。比如在Rocky Linux 9上用Rocky 8的源装包时经常报依赖冲突。经验服务器迁移到国产CPU架构如ARM环境时很多二进制包没有对应架构的版本。遇到这种情况一方面看系统包仓库是否提供该架构的RPM另一方面考虑用源码编译安装但编译过程可能需要调整依赖库的安装方式尽量先找官方文档适配当前架构的说明。9.4 系统服务启动异常现象systemctl start nginx后状态是failed但没有太多信息。排错方法# 查看详细状态 systemctl status nginx -l # 查看最近的系统日志 journalctl -u nginx --no-pager -n 50status输出里如果有Main process exited, codeexited, status1/FAILURE那重点接着看journal日志中该服务启动前后的报错。我排查Nginx起不来的问题十次有八次是配置文件语法错误先执行nginx -t验证配置再重启就能避免服务挂掉的情况。9.5 系统环境变量不生效现象明明在~/.bashrc里配置了环境变量开新终端却还是找不到命令。排查方向区分登录Shell和非登录Shell有区别一些发行版的终端默认不是登录Shell所以要看~/.bash_profile和~/.profile是否source了~/.bashrc。还有一种可能是某个进程比如桌面环境启动的进程没有继承最新环境变量需要完全登出重新登录。小技巧如果只是给某一次执行临时加上环境变量可以用env VARvalue command的方式而不需要改全局配置文件。比如env JAVA_HOME/tmp/jdk /opt/app/start.sh这种方式在测试不同版本JDK时非常方便。10. 给新手的学习路径建议10.1 从最小闭环开始不要陷入命令泥潭学Linux最容易陷入的误区就是想背下所有命令再开始动手。我的建议是完全颠倒过来先给自己定一个小目标然后遇到什么需求就现查什么命令边用边记。比如第一周的小目标就是“用命令行完成如下任务”创建一个目录在里面新建一个文本文件写入几行内容然后查看文件内容、修改文件权限、打包压缩。这个小闭环做完mkdir、touch、echo、cat、chmod、tar这些命令就都自然掌握了而且知道它们分别解决什么问题。第二个小目标可以定为“在一台服务器上部署一个静态网站”从系统更新开始安装Nginx配置站点目录修改Nginx配置文件放一个HTML文件最后通过IP访问到页面。这个过程会自然用到dnf、systemctl、vim、firewall-cmd或iptables、curl还会理解HTTP服务的目录和端口概念。10.2 培养用日志和错误信息找答案的习惯新手提问时最常犯的问题是把错误信息裁剪掉只发一句“我的Nginx启动失败了”。这会让排查的人很难给出准确判断。Linux的经验积累很大程度上就是锻炼怎么从报错信息里提取关键线索。比如启动失败时先看服务状态详情再翻日志把报错原样记录下来然后按关键字搜索。这个“看日志-搜关键字-找解决方案”的方法比盲目百度“Linux命令大全”有效得多。我现在遇到陌生错误第一反应仍然是看日志和--help输出而不是去问别人。10.3 日常使用中刻意练习的几条命令根据我的经验下面这些命令在真实工作中使用频率最高值得花时间刻意练到不用思考ls、cd、pwd文件系统导航基础cat、less、tail、grep查看文件内容与过滤cp、mv、rm、mkdir、ln文件操作chmod、chown权限管理ps、ss、top、free、df系统状态查看systemctl、journalctl服务管理ssh、scp远程登录与文件传输这些命令不需要记所有选项但核心参数要能顺手就写对。比如tar -xzf解压gzip压缩的tar包、tar -czf创建gzip压缩的tar包这两个组合我用了很多年基本不需要思考。10.4 打造属于自己的命令速查手册我建议每个学习者准备一个Markdown文件按照自己的分类记录命令。不同于官方手册这个文档只记自己实际用过的命令和踩过的坑。比如我会记录“某个目录下找最大的10个文件”的命令find /var/log -type f -exec du -h {} | sort -rh | head -10这种方式有两个好处一是写下来的过程本身就是一次深度记忆二是下次遇到相似场景直接复制自己验证过的命令减少试错成本。文档不需要很长贵在坚持积累。我个人在实际操作中的体会是Linux命令水平的提高不是靠死记硬背而是靠真实项目里的一次次排查和整理。刚开始可能会觉得记不住这很正常我的笔记本上至今还留着三年前的速查笔记很多命令虽然已经烂熟于心但偶尔翻看还会发现当时遗漏的细节。最后再分享一个小技巧虚拟机环境里大胆做实验不要怕把系统搞坏反正重装也就十几分钟的事把每个报错解决掉的那一瞬间才是真正长进的时候。 Linux系统环境与基本命令实战：从零搭建到线上排查
Linux系统环境与基本命令这块内容我断断续续在服务器上折腾了六七年从最开始只会敲ls和cd到现在能独立排查线上问题、写点自动化脚本过程中踩过的坑确实不少。网上关于Linux的教程一抓一大把但大多数要么是零散命令的堆砌要么是纯理论的书本知识看完还是不知道在真实环境里该怎么用。这篇内容我打算换一种讲法——不按命令字典的顺序去罗列而是从“我来一台新机器接下来会做什么”的视角把系统环境搭建、账号管理、目录规划、软件安装、网络排查、进程管理这些最常用场景串起来把基本命令融入真实操作里顺带解释清楚每条命令背后的思路和原理。1. Linux环境怎么来先从搞到一台可用的系统开始1.1 环境准备的三条主流路线没环境就没法谈命令。初学者问得最多的问题其实是“我在Windows上怎么练Linux”。根据我自己的经历有三条路线适合不同情况路线一虚拟机方案适合零基础系统学习用VirtualBox或VMware装一个Ubuntu Server或Rocky Linux内存分配2到4GB磁盘按30到50GB给。这个方案的好处是随便折腾密码忘了、系统崩了直接删除重装不影响宿主机。我早期就是拿虚拟机练手前前后后装了不下二十次系统每次重装后手动配置一遍环境不知不觉就把系统安装、分区、网络配置这些基础全练熟了。路线二云服务器适合有真实部署需求花钱买一台按量付费的云主机地域选离自己近的系统镜像选CentOS Stream、Rocky Linux或Ubuntu LTS版本都可以。这条路更贴近生产环境因为云服务器是固定公网IP要自己配置安全组规则要处理SSH密钥登录后面部署服务的时候还涉及防火墙、域名解析这些。相比虚拟机云服务器需要考虑的东西更多但也正是这种“不稳定感”逼人成长。路线三WSL适合只写代码不想折腾的开发者Windows下跑WSL确实轻量启动快和Windows文件系统互通也做得好。但要注意版本问题镜像里“wsl needs updating”那个提示通常是WSL版本过旧在管理员PowerShell里执行wsl --update就能解决。WSL适合日常写脚本、跑Python服务但它和原生Linux环境在systemd支持、网络模式上有差异如果目标岗位是服务器运维我不太建议只依赖WSL学命令。提示我遇到不少用虚拟机装Linux时蓝屏的情况排除硬件兼容问题之后多半是Hyper-V和VirtualBox的虚拟化冲突。安装前先确认Windows功能里Hyper-V是否开启如果开启就关掉或者直接改用Hyper-V自带的虚拟机创建。1.2 登录进系统后第一件事看版本和环境信息装好系统登录进去那一刻先别急着敲各种命令花两分钟确认自己到底在什么环境上干活。命令本身很简单# 查看内核版本 uname -a # 查看操作系统发行版本 cat /etc/os-release # 查看CPU、内存、磁盘信息 lscpu free -h df -hT # 查看网络IP ip addr show这些信息在后续配置软件源、安装驱动、排查性能问题时会反复用到。比如用cat /etc/os-release看到系统是Rocky Linux 9.3那软件源就要用对应版本的AppStream和BaseOS仓库看到内核是5.14开头就能判断系统里某些老模块可能不兼容。整体思路就是先知道自己站在哪块地基上再决定下一步怎么走。2. 命令体系的核心逻辑别死记硬背先理解结构2.1 命令行输入的三段式结构接触过一段时间Linux之后我发现几乎所有命令都遵循同一个结构命令名 选项 参数。比如分析这句useradd -m -s /bin/bash zhangsanuseradd是命令名表示创建用户-m和-s是选项-m表示自动创建家目录-s表示指定登录shellzhangsan是参数表示要操作的用户名把命令拆成这个三段式遇到没见过的命令第一反应就不是死记整条命令的意思而是分别去查“这个命令是干什么的、有哪些选项、后面跟什么参数”。用man命令可以查看最详细的说明但有时信息量太大我更常用命令名 --help快速过一遍关键选项。比如useradd --help输出会明确列出每个选项的用途。看多了之后慢慢会发现很多命令的选项是有共性的-f通常与配置文件相关-v通常是显示版本或详细输出-y在安装类命令里表示跳过确认。有了这个通用意识上手新命令的效率会高很多。2.2 绝对路径与相对路径文件系统导航的基础认知文件系统是Linux命令操作的重头戏。理解绝对路径和相对路径的差别决定了你写的脚本能不能在任何目录下正常运行。绝对路径是从根目录/开始描述的完整路径比如/etc/nginx/nginx.conf不管当前在哪个目录这个路径指向的文件都是同一个。相对路径则是相对于当前目录的位置比如../logs/app.log表示上一层目录里的logs文件夹下的app.log。实际业务里最常见的错误之一脚本里写了相对路径用cron定时任务执行时却找不着文件。原因就是cron执行时的工作目录通常不是脚本所在目录而是root的家目录。我自己写脚本涉及文件操作的路径一律用绝对路径除非是纯交互式操作确认当前目录没问题。文件路径相关的命令就几个组合起来基本能覆盖日常工作pwd # 查看当前所在绝对路径 ls -lah # 查看目录内容按人类可读格式显示大小 cd /opt/apps # 切换目录 tree -L 2 # 查看两层目录树结构顺便说一个细节ls -lah里的-a会显示以点开头的隐藏文件比如.env、.gitignore。很多配置文件的坑都在隐藏文件上刚接触时忘了加-a参数翻来覆去找不到文件到底在哪。2.3 英文帮助读不懂怎么办定位关键选项的实用方法必须承认全英文的 man 手册和--help输出对初学者有门槛。我的方法是先不看解释直接执行一遍看效果再对照选项反推。比如ls -l输出会显示一个7到10列的列表第一列是权限位第三第四列是属主和属组最后一列是文件名。执行几次之后列的含义自然就记住了完全不用背。还有一个技巧是用grep过滤帮助文本快速定位自己关心的选项。比如不知道怎么用tar排除某个目录时tar --help | grep exclude输出里会明确给出--exclude的写法。这个习惯帮我节省了大量查资料的时间靠的是“先知道有这个东西再精确看用法”的思路。3. 目录规划与文件操作一套能用于生产环境的通用模型3.1 Linux目录结构里你真正需要记住的五个位置Linux的FHS文件系统层次结构标准定义了整个目录树的用途。但刚上手时没必要全记真正高频的是这几个目录用途我的使用习惯/etc配置文件目录改任何服务配置之前先备份改完查验证/var/log日志文件目录排查问题第一站tail -f跟踪日志/opt第三方软件安装目录手动解压安装的软件放这里统一管理/tmp临时文件目录系统重启会清理不能放重要数据/home普通用户家目录源码编译、个人脚本都放自己家目录下写代码或者部署服务时我也会遵守一个约定程序代码放/opt或家目录下日志数据放/var/log下临时文件放/tmp下。这样做的好处是磁盘空间排查时一眼就能定位应用日志如果异常膨胀直接看/var/log下对应服务的文件大小部署包版本迭代时/opt下每个版本一个目录回滚就是切换软链接的事。3.2 文件创建、复制、移动、删除权限意识是第一课常用文件操作命令我从实际场景出发列一下怎么配着用# 创建多级目录 mkdir -p /opt/apps/backend/logs # 创建空文件 touch /opt/apps/backend/start.sh # 复制文件并保留权限属性 cp -a /opt/apps/backend/start.sh /opt/apps/backend/start.sh.bak # 移动文件到另一目录 mv /opt/apps/backend/config.yml /opt/apps/backend/config.yml.local # 删除前先看清楚 ls -lah /opt/apps/backend/ rm -rf /opt/apps/backend/logs/这里比较关键的意识就是rm -rf的杀伤力。我在生产环境删除任何东西之前都会先ls确认一遍路径和内容尤其是变量拼接绝对路径的场景。早期有一次写清理脚本变量没取到值结果rm -rf /差点把系统文件全删了。再强调一遍注意在脚本或命令行中凡是删除操作先确认变量非空再用set -u把未定义变量当成错误处理或者用test -d检查路径确实存在后再执行。3.3 权限位、属主和属组chmod与chown实操口径权限问题几乎每天都碰到跑个脚本提示 Permission denied启动服务说日志目录写不进去十有八九就是权限位或属主不对。Linux权限模型的基础是一个文件的权限分三组属主u、属组g、其他用户o每组有读r4、写w2、执行x1三种权限。数字表示法就是这三组数字拼起来比如755代表属主可读可写可执行属组和其他用户可读可执行。# 赋予脚本文件执行权限 chmod x /opt/apps/backend/start.sh # 修改属主和属组 chown -R appuser:appgroup /opt/apps/backend/ # 递归修改目录权限 chmod -R 750 /opt/apps/backend/实际中我比较推荐用750和640这类更严格的权限而不是一上来就777。用777虽然省事但任何用户都能改你的文件这在生产环境是安全隐患。工作里的规范是文件一般644目录一般755如果涉及敏感配置比如数据库密码就收紧为640或600。3.4 文本处理三件套grep、awk与sed的真实用法日常运维中处理文本的频率非常高最核心的三个命令是grep、awk、sed其定位可以大致这么理解grep按关键字过滤行awk按列取内容做统计和格式化sed按规则替换文本做增删改举一个我处理线上日志的真实例子。某个服务高峰期报错多我需要统计接口报错次数Top5的原因命令可以这样写grep ERROR /var/log/backend/app.log | awk {print $NF} | sort | uniq -c | sort -rn | head -5分步拆解一下grep ERROR过滤出所有报错行awk {print $NF}取每行最后一个字段通常是错误码sort排序让相同错误码相邻uniq -c统计出现次数sort -rn按次数从大到小排head -5取前五。这个管道链的思路比单独记某一条命令更有价值——遇到新的日志格式改一下字段位置就行。sed在批量替换时更高效。比如要把配置文件里旧域名换成新域名sed -i s/old-domain.com/new-domain.com/g /etc/nginx/conf.d/app.conf-i表示直接写入原文件s表示替换操作g表示全部替换。日常改配置时我会先不加-i执行一遍确认输出结果没问题再加上-i真正写入文件避免一次改错回不去的尴尬。4. 用户与权限管理多人共用服务器时必备的安全边界4.1 新建用户与组基于角色的分配思路服务器不可能只有root一个人用。多人团队共用的机器最基础的安全隔离就是为每个人创建独立账号按项目组去划分权限边界。常用的命令组合# 创建组 groupadd ops # 创建用户并指定家目录和shell useradd -m -s /bin/bash zhangsan # 设置密码 passwd zhangsan # 将用户加到附加组 usermod -aG ops zhangsan # 查看用户所属组 id zhangsan这里有两点经验值得多说一句。一是usermod -aG一定要带-aappend参数不加的话会把用户从原来的附加组中全部移除只保留当前指定的组这个坑很容易造成用户权限突然丢失二是新用户刚创建时建议先设置一个临时密码要求其首次登录后自行修改避免长期使用同一个共享密码。4.2 sudo与提权控制root权限使用红线很多初学者图方便长期用root直接操作服务器我强烈建议不要这样。root的权限太大一个命令失误就可能造成整个系统不可用。更合理的方式是给需要管理权限的人开sudo权限并且精细化控制。在/etc/sudoers.d/目录下建一个独立配置文件比如10-ops内容可以这样写zhangsan ALL(ALL) NOPASSWD: ALL这表示zhangsan可以在任何主机上以任何用户身份执行任何命令且不要求输入密码。但实际更安全的做法是按需授予比如只允许执行系统更新和重启服务的权限zhangsan ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/dnf update -y需要强调的一点团队里不同角色对服务器的操作需求差异很大。开发同学可能只需要查看日志、重启特定服务测试同学只需要操作测试环境。把sudo权限精确到命令级别能明显减少误操作和配置被乱改的风险。执行visudo之前会自动校验语法所以修改完千万别手动直接改/etc/sudoers规范做法是visudo -f /etc/sudoers.d/10-ops语法不对时会拒绝保存这样能避免把自己锁在门外。4.3 密码过期与登录控制安全策略的落地团队服务器上一个容易被忽视的策略是密码过期提醒。默认情况下系统账户密码可以长期不修改但安全意识强一点的环境里通常会要求定期改密。用chage命令可以管理密码过期策略# 查看密码过期信息 chage -l zhangsan # 设置密码90天后过期过期前7天提醒 chage -M 90 -W 7 zhangsan如果在系统日志或登录提示里看到密码过期的相关信息不要觉得只是烦人的提醒这是安全策略在生效。操作上普通用户登录时被提示密码过期需要立即改密这个交互流程本身也是系统密码策略的一部分配合双因子验证效果更好。提示在配置自动化任务时如果用了服务账号比如svc_app建议把它的密码过期策略设为永久有效chage -M -1否则某天凌晨3点cron突然跑不了任务排查半天发现是密码过期导致认证失败就很被动了。5. 软件安装与仓库管理从yum/dnf到源码编译5.1 用系统包管理器装软件仓库选对是第一步大多数Linux发行版都自带成熟的软件包管理器。Debian系用aptRed Hat系RHEL、Rocky、CentOS Stream用yum或dnf。安装软件的第一原则就是能用系统包的用系统包能在官方仓库找到的绝不额外下载安装包。以Rocky Linux 9为例一些常用操作# 更新软件源缓存 sudo dnf makecache # 安装常用工具 sudo dnf install -y vim wget curl net-tools unzip # 搜索某个包 sudo dnf search nginx # 查看已安装包 sudo dnf list installed | grep nginx # 卸载软件 sudo dnf remove -y nginx系统包管理器的好处是依赖关系自动处理卸载也干净升级维护都统一走包管理渠道。但是仓库自带的软件版本通常偏旧比如某些开发工具需要更新的版本这时就需要考虑第三方的软件源或者直接用官方提供的安装脚本。配置第三方源时关键是找官方和可信的源。比如安装Docker方法就是在官网下载对应的仓库配置文件放到/etc/yum.repos.d/下然后执行dnf install docker-ce docker-ce-cli containerd.io。我之前碰到过从乱七八糟的源安装Docker结果服务一直报奇怪的依赖错误折腾一天后换成官方源半小时就解决了。配置源之后一定要dnf makecache更新缓存再装包。5.2 离线环境安装没有外网也能装软件的办法很多公司内网服务器并不能访问外网软件安装就成了一个麻烦点。离线安装有两条路一是在有网的机器上下载好安装包再拷贝进去二是在内网搭建本地软件仓库。以CentOS/Rocky环境跑离线安装Python包为例若目标机器上没有外网却要装requests库可以在有网的机器上执行pip download requests -d /tmp/packages/然后把/tmp/packages整个目录拷到离线机器上pip install --no-index --find-links/tmp/packages/ requests系统级RPM包同理可以用dnf download下载指定包及其依赖再拷贝到目标机器上用rpm -ivh *.rpm安装。离线机器上最常遇到的问题就是依赖链太长漏掉一个依赖包就会导致安装失败。经验做法是下载时把依赖关系完整列出来dnf download --resolve --alldeps nginx5.3 源码编译安装为什么仍然值得学虽然系统包管理器便捷但源码编译安装这个技能我一直建议掌握。原因很简单某些软件版本发行时只发布源码包而且编译安装能自定义编译参数软件安装路径也更灵活。标准流程大致是# 下载源码包 wget https://example.com/app-1.2.3.tar.gz # 解压 tar -xzf app-1.2.3.tar.gz cd app-1.2.3 # 配置编译参数 ./configure --prefix/opt/app # 编译并安装 make -j4 make install编译过程中最常踩的坑就是缺少依赖库报错信息里通常都会明确指出缺哪个头文件或库。比如提示libssl-dev没找到那就先通过包管理器把对应的devel包装上再重新编译。./configure --prefix/opt/app指定安装目录这个习惯我从一开始就坚持这样卸载时直接删掉整个目录即可不会污染系统其他位置。6. 网络排查与远程管理分离机和远程两种情况6.1 网络配置基础IP、网关、DNS与连通性排查服务器网络问题排查算是日常工作中最高频的场景之一。网络命令不需要记很多但核心几个必须熟练# 查看当前IP和网卡状态 ip addr show # 检查默认路由 ip route show # 测试到某个IP的连通性 ping -c 4 8.8.8.8 # 查看DNS解析是否正常 nslookup example.com # 追踪网络路径 traceroute example.com排查网络问题的一个通用思路是从底层往上走。先确认网卡和IP配置ip addr再检查网关ip route然后测试外层连通ping网络通了再测DNS解析nslookup。如果IP配置对了还是Ping不通网关就要关注物理链路和驱动了嵌入式环境里还涉及phy芯片是否工作、网口是否up这类问题可以查网卡状态中的state UP字样并留意内核日志中是否有网口link down的记录。6.2 SSH远程登录从密码到密钥的安全演进远程管理Linux服务器最常用的方式是SSH。刚入门的时候可能直接用密码登录但生产环境一定要换成密钥登录。基本操作# 生成本机密钥对 ssh-keygen -t ed25519 -C your_emailexample.com # 将公钥上传到服务器 ssh-copy-id userserver_ip # 登录服务器 ssh userserver_ip生成密钥时建议用ED25519算法长度短、安全性足够兼容性也广。上传公钥之后可以在服务器上修改SSH配置vim /etc/ssh/sshd_config将密码登录关掉PasswordAuthentication no PubkeyAuthentication yes修改完记得执行sudo systemctl restart sshd。这里强调一个实操习惯修改SSH配置前先保留一个已登录会话等新配置验证没问题再退出否则密钥配置出错又关了密码认证那你只能通过管理终端去救非常被动。如果登录特别慢卡在输入密码前好几秒常见原因是DNS反向解析超时在sshd配置里加一行UseDNS no再重启服务即可。6.3 端口监听与服务检查案发第一现场排查服务是不是真的在运行单看进程存在是不够的必须看端口监听状态。最常用的是# 查看端口监听情况 ss -lntp # 查看指定端口 ss -lntp | grep 8080 # 测试本地端口是否可达 curl -v http://127.0.0.1:8080/healthss的输出里能明确看到监听地址、端口以及对应的进程名。比如数据库默认在3306端口Nginx在80和443如果端口没监听多半是服务没起来或者配置的监听地址不对。curl -v还会显示完整的请求响应头和连接过程是定位HTTP服务问题的利器比如查看响应状态码、以及TLS握手是否正常。7. 进程与日志定位系统异常的两把钥匙7.1 查看进程与资源占用top和ps配合使用服务跑着跑着变慢了第一件事就是看系统和进程的资源占用。常用命令是top和ps。# 实时查看系统资源占用按CPU或内存排序 top # 查看特定进程的详细信息 ps -ef | grep nginx # 动态查看某进程的线程情况 top -H -p 12345实际使用中top的交互命令值得记几个按P按CPU使用率排序按M按内存使用率排序按c显示完整命令行。排查服务器负载过高时我会先把top打开按CPU排序如果某个进程CPU占用接近100%再结合ps -ef看清楚完整启动参数和对应的工作目录判断是正常业务流量升高还是代码出现了死循环或异常请求。还有一种情况是内存问题。free -h看到可用内存很低但进程本身不大可能是缓存占用。Linux内存策略里释放内存最安全的方式是通过echo 3 /proc/sys/vm/drop_caches清理缓存但这只是临时手段真要排查还得看具体是哪个进程在持续吃内存用ps aux --sort-rss | head能看到内存占用最高的进程排行。7.2 日志文件分析从tail到journalctl日志是无声的证人。排查问题永远是从日志开始找线索而不是瞎猜。最常用的日志操作# 实时跟踪日志输出 tail -f /var/log/app/app.log # 查看最后100行 tail -100 /var/log/app/app.log # 按关键字过滤日志 grep -i error /var/log/app/app.log | tail -20 # 使用systemd日志 journalctl -u nginx --since 10 minutes agojournalctl在systemd系统上用得很普遍-u指定服务名--since按时间段过滤比翻/var/log/messages方便不少。日志分析最重要的能力是把零散的信息串成时间线什么时间服务开始报错报错之前系统发生了什么操作比如发布版本、修改配置、磁盘写满顺着时间线找根因基本都能浮出来。注意日志文件磁盘占用过高的时候不能用rm直接删正在被进程写入的日志文件否则空间不会真正释放。正确做法是cat /dev/null /var/log/app/app.log清空文件但保持文件句柄有效。7.3 进程间通信与后台任务Linux进程管理的几个侧面理解进程管理光会kill肯定不够。实际运维中经常会用到“进程间通信”和“后台运行”这两个概念。Linux进程间通信的常见方式有管道|、信号kill -HUP、共享内存、Socket等。管道我们前面已经用过了比如grep和awk之间的组合就是在做进程间数据传递。信号机制里kill -HUP pid经常被用来让守护进程重新加载配置而不中断服务Nginx graceful reload用的就是这个信号。实际调试时查看某进程暴露的Socket和文件描述符可以用lsof -p pid。后台运行任务也有讲究。直接执行命令会占用当前终端关闭终端任务就被挂断。正确做法是# 使用nohup后台运行 nohup python run.py /var/log/app/run.log 21 # 使用systemd管理服务 sudo systemctl start myappnohup是为了让进程在终端退出后继续运行21是把标准错误也重定向到同一个日志文件如果不加这个报错信息不会进日志排查问题时会少一半线索。生产环境里工作能用systemd管理服务就尽量别用nohup服务异常退出时systemd可以自动拉起崩了也有状态可以查询。8. 环境变量与Shell脚本从手动到自动化的跨越8.1 环境变量PATH和JAVA_HOME这类配置为什么重要环境变量是Shell和程序之间的桥梁。最常遇到的就是“明明安装了软件却提示命令找不到”这大多是因为PATH环境变量没有包含软件安装目录。比如把软件装在/opt/maven/bin那当前输入mvn找不到是正常的因为Shell不在PATH指定的目录里找。解决办法就是在环境变量配置文件中追加路径。系统级可以改/etc/profile用户级改~/.bashrc或~/.bash_profile# 编辑用户级配置 vim ~/.bashrc # 在文件末尾追加 export PATH/opt/maven/bin:$PATH export JAVA_HOME/opt/jdk17 export PATH$JAVA_HOME/bin:$PATH # 让配置立即生效 source ~/.bashrc # 确认生效 echo $PATH which mvn有一个细微但重要的区别/etc/profile对登录Shell生效而~/.bashrc对交互式非登录Shell生效。按我的习惯用户级自定义环境变量统一放~/.bashrc系统级全局变量放/etc/profile.d/下新建独立脚本文件而不是直接改/etc/profile这样维护起来结构清晰也不会因为个别配置写错影响全局登录。8.2 一个能用在服务器上的自动化脚本示例手动执行命令只能解决一次性的问题真正提升效率的是把常用操作封装成脚本。我来写一个实际可复用的清理脚本示例它的功能是清理指定目录下N天前的日志文件并记录清理结果到日志#!/bin/bash # 需要清理的日志目录 LOG_ROOT/var/log/backend # 清理7天前的文件 DAYS7 # 清理记录 CLEAN_LOG/var/log/cleanup.log # 判断目录是否存在 if [ ! -d $LOG_ROOT ]; then echo $(date %Y-%m-%d %H:%M:%S) [ERROR] $LOG_ROOT 目录不存在 $CLEAN_LOG exit 1 fi # 统计待清理文件数量 file_count$(find $LOG_ROOT -type f -mtime $DAYS | wc -l) # 执行清理 find $LOG_ROOT -type f -mtime $DAYS -exec rm -f {} \; # 记录结果 echo $(date %Y-%m-%d %H:%M:%S) [INFO] 清理完成本次清理文件数: $file_count $CLEAN_LOG几个值得琢磨的细节一是-mtime 7表示修改时间距今超过7天注意单位和逻辑容易写反二是先用wc -l统计数量再实际删除日志里能看出每次清理的量方便判断业务日志增长趋势三是关键路径一定要判断存在性再操作这是从“删库”惨案里吸取的教训。把脚本放到cron定时任务里每天凌晨执行一次0 2 * * * /opt/scripts/clean_old_logs.sh /var/log/cleanup_cron.log 21这里顺手提醒一下cron环境下PATH环境变量比交互式Shell少很多如果在脚本里用了某个程序的命令最好在脚本开头写明完整路径。比如Python的路径可以先用which python3查出来然后脚本里直接用/usr/bin/python3。9. 常见问题与排错实录这些坑我替你踩过9.1 权限拒绝类问题现象运行脚本提示Permission denied执行sudo命令也提示没有权限。排查步骤先ls -l确认文件的执行位是否存在再看属主是否是当前用户。如果是自己创建的脚本chmod x即可如果是在别人目录下的脚本则要考虑是否用对用户或者通过sudo执行。踩坑经历有一次线上服务的启停脚本在处理备份时一直报错排查发现是脚本执行用户对备份目录没有写权限而之前一直没注意到是因为测试环境用了root跑的到了生产环境换成普通用户就暴露了。从这个教训之后我写部署脚本都默认以普通用户身份检查一遍全部流程再交给运维。9.2 端口占用问题现象服务启动时报Address already in use。排错方法# 找到占用端口的进程 ss -lntp | grep 8080 # 根据PID查看进程详情 ps -ef | grep PID # 确认后再结束进程 kill -9 PID有一种容易误判的情况ss查到端口被一个PID为1的进程占用systemd这通常是其他进程通过socket传递给了systemd或者之前有进程被强行kill但socket没释放。此时需要结合进程启动时间和上下文排查不要盲目kill掉PID 1。9.3 软件源与架构不匹配问题现象dnf install提示找不到包或者安装的包无法使用提示架构不兼容。排查思路uname -m确认系统架构x86_64还是aarch64对照软件源配置文件里的baseurl是否匹配当前架构。还要确认系统版本是否在源支持范围里。比如在Rocky Linux 9上用Rocky 8的源装包时经常报依赖冲突。经验服务器迁移到国产CPU架构如ARM环境时很多二进制包没有对应架构的版本。遇到这种情况一方面看系统包仓库是否提供该架构的RPM另一方面考虑用源码编译安装但编译过程可能需要调整依赖库的安装方式尽量先找官方文档适配当前架构的说明。9.4 系统服务启动异常现象systemctl start nginx后状态是failed但没有太多信息。排错方法# 查看详细状态 systemctl status nginx -l # 查看最近的系统日志 journalctl -u nginx --no-pager -n 50status输出里如果有Main process exited, codeexited, status1/FAILURE那重点接着看journal日志中该服务启动前后的报错。我排查Nginx起不来的问题十次有八次是配置文件语法错误先执行nginx -t验证配置再重启就能避免服务挂掉的情况。9.5 系统环境变量不生效现象明明在~/.bashrc里配置了环境变量开新终端却还是找不到命令。排查方向区分登录Shell和非登录Shell有区别一些发行版的终端默认不是登录Shell所以要看~/.bash_profile和~/.profile是否source了~/.bashrc。还有一种可能是某个进程比如桌面环境启动的进程没有继承最新环境变量需要完全登出重新登录。小技巧如果只是给某一次执行临时加上环境变量可以用env VARvalue command的方式而不需要改全局配置文件。比如env JAVA_HOME/tmp/jdk /opt/app/start.sh这种方式在测试不同版本JDK时非常方便。10. 给新手的学习路径建议10.1 从最小闭环开始不要陷入命令泥潭学Linux最容易陷入的误区就是想背下所有命令再开始动手。我的建议是完全颠倒过来先给自己定一个小目标然后遇到什么需求就现查什么命令边用边记。比如第一周的小目标就是“用命令行完成如下任务”创建一个目录在里面新建一个文本文件写入几行内容然后查看文件内容、修改文件权限、打包压缩。这个小闭环做完mkdir、touch、echo、cat、chmod、tar这些命令就都自然掌握了而且知道它们分别解决什么问题。第二个小目标可以定为“在一台服务器上部署一个静态网站”从系统更新开始安装Nginx配置站点目录修改Nginx配置文件放一个HTML文件最后通过IP访问到页面。这个过程会自然用到dnf、systemctl、vim、firewall-cmd或iptables、curl还会理解HTTP服务的目录和端口概念。10.2 培养用日志和错误信息找答案的习惯新手提问时最常犯的问题是把错误信息裁剪掉只发一句“我的Nginx启动失败了”。这会让排查的人很难给出准确判断。Linux的经验积累很大程度上就是锻炼怎么从报错信息里提取关键线索。比如启动失败时先看服务状态详情再翻日志把报错原样记录下来然后按关键字搜索。这个“看日志-搜关键字-找解决方案”的方法比盲目百度“Linux命令大全”有效得多。我现在遇到陌生错误第一反应仍然是看日志和--help输出而不是去问别人。10.3 日常使用中刻意练习的几条命令根据我的经验下面这些命令在真实工作中使用频率最高值得花时间刻意练到不用思考ls、cd、pwd文件系统导航基础cat、less、tail、grep查看文件内容与过滤cp、mv、rm、mkdir、ln文件操作chmod、chown权限管理ps、ss、top、free、df系统状态查看systemctl、journalctl服务管理ssh、scp远程登录与文件传输这些命令不需要记所有选项但核心参数要能顺手就写对。比如tar -xzf解压gzip压缩的tar包、tar -czf创建gzip压缩的tar包这两个组合我用了很多年基本不需要思考。10.4 打造属于自己的命令速查手册我建议每个学习者准备一个Markdown文件按照自己的分类记录命令。不同于官方手册这个文档只记自己实际用过的命令和踩过的坑。比如我会记录“某个目录下找最大的10个文件”的命令find /var/log -type f -exec du -h {} | sort -rh | head -10这种方式有两个好处一是写下来的过程本身就是一次深度记忆二是下次遇到相似场景直接复制自己验证过的命令减少试错成本。文档不需要很长贵在坚持积累。我个人在实际操作中的体会是Linux命令水平的提高不是靠死记硬背而是靠真实项目里的一次次排查和整理。刚开始可能会觉得记不住这很正常我的笔记本上至今还留着三年前的速查笔记很多命令虽然已经烂熟于心但偶尔翻看还会发现当时遗漏的细节。最后再分享一个小技巧虚拟机环境里大胆做实验不要怕把系统搞坏反正重装也就十几分钟的事把每个报错解决掉的那一瞬间才是真正长进的时候。