管理Linux软件包和进程

Linux软件包管理从源码编译到YUM仓库再到进程管理 —— 原理与实战前言在Linux系统中软件包管理是运维人员最常打交道的操作之一。无论是安装Web服务器还是部署数据库环境都离不开它。但你有没想过为什么Linux有源码安装、RPM、YUM这么多种装软件的方式它们之间是什么关系YUM仓库里的repodata目录到底存了什么本文将以CentOS 7为操作环境从软件安装方式的演进历史讲起深入解析YUM仓库的核心机制特别是 repodata 目录的结构与原理再延伸到进程管理助你从原理到实战全方位掌握Linux软件包和进程管理的知识。一、软件安装方式的演进源码 → RPM → YUM在讲具体操作之前我们先理清这三者的由来与关系这能帮你建立起完整的认知框架。1.1 源码编译 —— 最原始的方式由来在Linux早期软件以源代码的形式发布。开发者用C/C等语言写好代码打包成.tar.gz或.tar.bz2压缩包用户下载后需要自行编译安装。为什么需要它早期Linux发行版如Slackware、早期Debian没有统一的包管理标准源码包可移植性好一套源码可以在不同架构的机器上编译可以自定义编译参数实现量体裁衣的性能优化痛点安装步骤繁琐——需要手动解压、运行configure检测环境、make编译、make install安装。最关键的是依赖关系要手动解决比如装A之前要先装BB又依赖C……。1.2 RPM —— 二进制包的标准化由来为了解决每次安装都要编译的问题红帽公司Red Hat提出了RPMRed Hat Package Manager红帽包管理器。它将软件在特定环境下预先编译好打包成.rpm格式用户直接安装二进制包即可无需编译。为什么需要它安装速度极快省去了编译时间软件包格式统一命名规范便于管理和查询产生了包数据库的概念RPM数据库位于/var/lib/rpm/可以查询已安装的包、文件归属等痛点致命缺陷依赖地狱Dependency Hell。RPM虽然解决了编译问题但依赖关系依然需要人工处理。假如你要装一个软件它依赖10个库每个库又依赖更多——手动逐一下载安装的工作量是不可接受的。这就催生了下一代的YUM。1.3 YUM —— 自动解决依赖的智慧由来YUMYellow dog Updater, Modified最初由Yellow Dog Linux发行版开发后被红帽采纳为RHEL/CentOS的默认包管理器。它的核心创新是引入了软件仓库repository的概念。为什么需要它将所有RPM包集中到仓库服务器上仓库中附带元数据数据库repodata提前计算好了每个包的依赖关系YUM客户端通过查表对比自动计算完整的依赖链一次性下载并安装所有需要的包管理员从手工找依赖变成了一条命令搞定1.4 三者的关系图┌─────────────────────────────────────────────────────┐ │ 软件安装方式演进 │ ├─────────────┬──────────────────┬─────────────────────┤ │ 源码编译 │ RPM安装 │ YUM/DNF安装 │ ├─────────────┼──────────────────┼─────────────────────┤ │ 手工编译 │ 预编译二进制包 │ 仓库元数据自动解析 │ │ 依赖手动 │ 依赖手动 │ 依赖自动解决 │ │ 灵活最高 │ 安装最快 │ 使用最便捷 │ │ 效率最高 │ 标准化 │ 支持批量管理 │ ├─────────────┴──────────────────┴─────────────────────┤ │ 时间/便捷度 → │ │ 越往后越方便但离源码越远 │ └──────────────────────────────────────────────────────┘一句话总结源码编译是自己做饭RPM是买速冻食品YUM是叫外卖还帮你配好套餐。二、源码编译安装理解软件的编译-安装全过程2.1 实战编译安装Nginx我们从官网获取Nginx源码包来演示。图中红色下划线标注了 wget 命令的下载地址和文件保存位置这是从Nginx官网获取源码的关键一步下载完成后解压可以看到源码目录的结构红色下划线标注了源码目录中最核心的三个部分configure可执行脚本、Makefile.in模板文件、以及源码的README文档2.2 configure —— 安装环境检测器这是源码安装的灵魂步骤。configure是一个Shell脚本由autoconf工具生成它的任务包括检查系统是否安装了所需的编译器gcc、g等检查依赖的库文件和头文件是否存在检查关键系统函数和特性的可用性根据检测结果生成 Makefile 文件后续make命令就靠它了执行./configure开始检测configure会逐项检查编译环境红色下划线标注了它正在检测的关键项如果环境中缺少依赖configure会报错并终止。例如编译Nginx需要PCRE库正则表达式支持和OpenSSL库HTTPS支持我们就先用yum安装它们图中使用了 yum install 而非 rpm 安装依赖——这恰好印证了YUM自动解决依赖的优势一条命令就把库及其所有子依赖全装好了所有依赖安装完毕后再次执行configure如果看到以下界面说明环境已就绪红色下划线标注了configure执行成功的标志性输出最后一行提示现在可以执行make了2.3 make make installconfigure生成Makefile后make命令读取Makefile中的指令调用编译器gcc将源码编译为二进制可执行文件。make install将这些文件安装到系统目录通常为/usr/local/。思考源码安装虽然步骤多但为什么还有人在用因为在本机编译的代码能针对当前CPU指令集做优化性能往往比通用RPM包高5%~15%。在追求极致性能的场景如高频交易、数据库内核中源码编译仍是首选。三、RPM包管理二进制包的标准化分发3.1 RPM解决了什么问题源码编译虽好但每次安装都要等编译大型软件如MySQL编译一次可能半小时。RPM将软件在特定环境下预编译好打包用户直接rpm -ivh 包名.rpm即可安装。RPM包命名规则以zsh-5.0.2-14.el7.x86_64.rpm为例zsh -5. 0. 2 -14 .el7 .x86 .64 软件名 主版本 次版本 修订 发布次数 系统版本 CPU架构 系统位数其中.el7表示该包是为RHEL 7 / CentOS 7编译的这保证了二进制包与操作系统的兼容性。3.2 RPM的依赖地狱RPM安装时会读取包头部的Requires字段检查系统是否满足依赖。如果不满足则报错退出。例如安装QQ Linux版时[rootserver /]# rpm -ivh linuxqq_3.1.1-11223_x86_64.rpm错误依赖检测失败 libXScrnSaver 被 linuxqq-3.1.1_11223-1.x86_64 需要你必须手动找到libXScrnSaver这个包先安装它[rootserver /]# yum install libXScrnSaver # 这里用yum因为libXScrnSaver本身也有依赖[rootserver /]# rpm -ivh linuxqq_3.1.1-11223_x86_64.rpm假如依赖链是 A → B → C → D → E你就得手动装5次——这就是依赖地狱Dependency Hell。关键转折RPM本身不具备自动处理依赖的能力它只是检查并拒绝。真正解决这个问题的是下一代的YUM。四、YUM —— 自动化解依赖的仓库机制核心重点4.1 YUM是什么YUMYellow dog Updater, Modified是在RPM之上构建的高层包管理工具。它仍然使用RPM包作为安装单元但通过引入软件仓库Repository的概念解决了依赖问题。一句话YUM RPM 仓库元数据 自动依赖解析。在 CentOS 7 中yum就是原生命令不是软链接[rootserver ~]# which yum/usr/bin/yum[rootserver ~]# rpm -qf /usr/bin/yumyum-3.4.3-168.el7.centos.noarch4.2 YUM的工作原理核心机制YUM的工作流程可以分解为以下步骤用户执行 yum install httpd │ ▼ 读取 /etc/yum.repos.d/*.repo 配置文件 │ ▼ 连接 baseurl 指定的仓库地址 │ ▼ 下载 repodata/repomd.xml仓库入口文件 │ ▼ 根据 repomd.xml 下载 primary.xml.gz 等元数据 │ ▼ 与本机 RPM 数据库/var/lib/rpm/比对 │ ▼ 计算完整的依赖树递归解析 requires 和 provides │ ▼ 一次性下载所有需要的 RPM 包并安装核心思想提前建好数据库repodata安装时查表比对一次解决所有依赖。4.3 深度解析repodataYUM仓库的核心这是本文最核心的章节——repodata目录到底存放了什么当一个目录被配置为YUM仓库时必须包含repodata/子目录该目录由createrepo命令生成。如果把YUM仓库比作一家超市RPM包是货架上的商品那么repodata就是超市的商品目录和索引——告诉你什么商品在哪个货架、商品之间有什么搭配关系。repodata/ ├── repomd.xml ← 仓库的总入口文件清单 ├── primary.xml.gz ← 所有RPM包的基本信息名称、版本、依赖、提供 ├── filelists.xml.gz ← 所有RPM包中包含的文件列表 ├── other.xml.gz ← 额外信息变更日志、包描述等 ├── primary.sqlite.bz2 ← SQLite格式的primary数据兼容旧版yum └── filelists.sqlite.bz2 ← SQLite格式的filelists数据repomd.xml —— 仓库清单这是YUM客户端第一个下载的文件。它的作用是告诉YUM这个仓库里有哪几个元数据文件每个元数据文件的文件名、路径每个文件的校验值checksum用于验证文件完整性文件的生成时间可以理解为超市门口的导购图——告诉你各个区域在哪里。primary.xml.gz —— 最核心的元数据这是最关键的元数据文件记录了仓库中每一个RPM包的完整信息信息类别内容作用包标识名称、版本号、架构、大小区分和识别包Requires依赖运行时需要哪些库/包YUM据此判断缺什么Provides提供提供了哪些库/能力YUM据此匹配依赖Conflicts冲突与哪些包不兼容避免安装冲突Obsoletes取代取代了哪些旧包处理包更名和升级filelists.xml.gz记录了每个RPM包安装后会产生哪些文件及其路径。当你使用yum provides /path/to/file查询某个文件由哪个包提供时YUM就是在这个文件中查找的。例如你误删了/bin/ls可以用yum provides /bin/ls# 返回coreutils-8.22-24.el7.x86_64# 说明/bin/ls由coreutils包提供重新安装即可依赖解析的完整示例我们来模拟一下YUM安装httpd时的依赖解析过程Step 1: YUM 读取 primary.xml.gz找到 httpd 的 Requires 发现需要libapr-1.so.0, libaprutil-1.so.0, libpcre.so, ... Step 2: YUM 在同一仓库中查找 Provides 这些库的包 找到apr-1.6.3 提供了 libapr-1.so.0 apr-util-1.6.1 提供了 libaprutil-1.so.0 pcre-8.44 提供了 libpcre.so Step 3: 递归检查这些依赖包自身是否还有依赖 apr 还需要libc.so.6, libpthread.so.0glibc提供系统已安装 ...递归直到全部满足 Step 4: 确定最终的安装集合httpd apr apr-util pcre ... 一次性下载并安装这就是YUM自动解决依赖的底层原理——基于预计算元数据的查表替换了人工递归查找。repodata的生成如果你搭建自己的YUM仓库使用createrepo命令生成repodatacreaterepo /path/to/repo/# 会自动在 /path/to/repo/ 下生成 repodata/ 目录初次生成较慢之后可以用--update增量更新createrepo--update/path/to/repo/4.4 CentOS 7的仓库结构在CentOS 7中ISO镜像挂载后是单一仓库结构/media/ ├── Packages/ ← 存放所有RPM包的目录数千个 ├── repodata/ ← 仓库元数据本文核心 ├── .discinfo ├── RPM-GPG-KEY-* ├── isolinux/ └── ...这与RHEL 8/CentOS 8不同——后者拆分为BaseOS和AppStream两个仓库双仓库架构。CentOS 7的单一仓库同时包含系统组件和应用程序的包由一个元数据集单个repodata统一管理。图中红色下划线标注了 CentOS 7 ISO 挂载后的关键目录结构Packages 目录存放所有RPM包repodata 目录存放元数据。这两个目录共同构成了一个完整的YUM仓库4.5 配置YUM本地源第一步挂载ISO镜像mount/dev/cdrom /media挂载前 /media 目录为空红色下划线标注了光驱设备文件 /dev/sr0第二步编写 .repo 配置文件YUM的所有仓库配置存放在/etc/yum.repos.d/目录下以.repo结尾。系统启动时会扫描该目录下所有.repo文件。# 先备份原有的repo文件使其失效mv/etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.back# 新建本地源配置文件vim/etc/yum.repos.d/local.repo写入以下内容[local-repo] nameLocal YUM Repository baseurlfile:///media/ gpgcheck0 enabled1图中红色下划线标注了三个关键参数baseurl 指向本地挂载路径、gpgcheck0 跳过GPG验证、enabled1 启用仓库。新手最容易犯错的就是路径写错或指向了repodata内部注意baseurl要指向包含repodata的那一层目录而不是repodata本身参数解读参数含义说明[local-repo]仓库ID唯一标识不能重复不能有空格name仓库描述名给人看的会显示在yum repolist中baseurl仓库地址file://本地路径、http://或https://网络路径、ftp://gpgcheck是否校验GPG签名1开启安全0关闭方便gpgkeyGPG公钥文件路径gpgcheck1时必须指定enabled是否启用0禁用1启用可缺省默认启用重要baseurl的路径要指向包含 repodata 目录的父目录。YUM会自动在 baseurl 路径下查找repodata/repomd.xml。如果路径写成了/media/repodata/YUM会找不到入口文件。第三步生成缓存并验证yum clean all# 清除旧缓存yum makecache# 重新生成缓存下载repodata到本地/var/cache/yum/yum repolist# 查看当前启用的仓库yuminstalltree-y# 测试安装4.6 配置YUM网络源相比本地源网络源只是将baseurl从file://换成了http://[base] nameCentOS-7 - Base baseurlhttp://mirrors.aliyun.com/centos/7/os/x86_64/ gpgcheck1 gpgkeyhttp://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7 [extras] nameCentOS-7 - Extras baseurlhttp://mirrors.aliyun.com/centos/7/extras/x86_64/ gpgcheck1 gpgkeyhttp://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7 [updates] nameCentOS-7 - Updates baseurlhttp://mirrors.aliyun.com/centos/7/updates/x86_64/ gpgcheck1 gpgkeyhttp://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7注意这里打开了gpgcheck1因为是从互联网下载需要验证包的签名以确保没有被篡改。gpgkey指定了公钥的下载地址。需要说明的是网络源的仓库目录结构在远端的镜像服务器上也是标准化的——每个子仓库base、extras、updates都独立拥有自己的Packages/和repodata/目录。红色下划线标注了网络源配置中的关键差异baseurl 从 file:// 换成了 http:// 网络地址且配置了 gpgkey 进行包签名验证4.7 验证配置结果执行yum repolist查看已生效的仓库图中红色下划线标注了配置成功的标志性输出repolist 正确显示了仓库ID和包数量。如果显示0或者报错通常是 baseurl 路径错误或网络不通4.8 常用YUM命令速查命令用途类比yum repolist查看启用的仓库列表查看外卖店列表yum list all列出所有可安装包翻看菜单yum list installed列出已安装的包看冰箱里有什么yum info 包名查看包详细信息看菜品的配料表yum install 包名安装包自动解依赖点一份套餐yum groupinstall 开发工具安装整个包组点一份全家桶yum update 包名升级包换新口味yum remove 包名卸载包扔掉yum provides /path查文件属于哪个包查这个零件从哪来yum search 关键词模糊搜索包名按关键词搜菜单yum clean all清除本地缓存清空手机缓存yum makecache重新生成缓存刷新页面yum reinstall 包名重新安装包重新下载修复用五、管理进程软件装好了要运行运行中的程序就是进程。下面我们来看看如何查看和管理进程。5.1 程序、进程与线程概念定义生活中的比喻程序存储在磁盘上的二进制文件静态一本菜谱进程程序的一次执行实例动态有生命周期按照菜谱做菜的过程线程进程内的最小执行单元多个厨师协作做同一道菜关键区别进程是资源分配的最小单位拥有独立的内存空间线程是CPU调度的最小单位共享进程的内存空间一个程序可以对应多个进程如Nginx Master Worker一个进程可以包含多个线程5.2 ps命令 —— 查看进程静态快照ps用于显示某个瞬间的系统进程状态。最经典组合是ps aux图中红色下划线标注了 ps aux 输出中最关键的几个字段PID进程标识符、%CPUCPU占用率、%MEM内存占用率、STAT进程状态、COMMAND进程命令。其中 PID 是管理进程的唯一标识STAT 反映了进程当前的生命周期状态输出字段详解字段含义说明USER运行该进程的用户root表示系统进程普通用户运行自己的进程PID进程ID唯一标识管理中最重要的字段kill时需要它%CPUCPU占用百分比多核下可能超过100%单个核最高100%%MEM物理内存占用百分比如果某个进程异常高可能是内存泄漏VSZ占用虚拟内存大小KB进程申请的虚拟地址空间RSS驻留物理内存大小KB实际占用的物理内存但这个值不准确TTY关联的终端?表示没有终端后台服务进程STAT进程状态R运行、S睡眠、D不可中断、T停止、Z僵尸START启动时间看系统已运行多久了TIME占用CPU的总时间不是运行时间是累计占用的CPU时间COMMAND进程命令名通常包含完整的命令路径STAT进程状态速查口诀状态码含义说明R运行中Running正在占用CPU或处于运行队列S可中断睡眠Sleeping等待某事件发生可被信号唤醒D不可中断睡眠通常是I/O等待杀不死连kill -9也不行T已停止Stopped通常被CtrlZ挂起Z僵尸Zombie已终止但父进程未回收占着PID不释放高优先级优先获得CPU时间N低优先级谦让CPU时间s会话领导者通常是进程的父进程l多线程进程包含多个线程前台进程组当前终端的前台进程僵尸进程特别说明子进程结束后会发送SIGCHLD信号给父进程父进程调用wait()系统调用回收子进程的资源。如果父进程没调用wait()子进程变成僵尸——它的资源已被释放但在进程表中仍占一个条目。僵尸无法被kill -9杀死只能杀掉它的父进程由init进程接管回收。5.3 top命令 —— 实时动态监控ps看到的是某一瞬间的快照top则提供持续刷新的动态视图图中红色下划线标注了 top 输出中最核心的指标第一行的负载平均值load average、第三行的CPU空闲率id、以及进程列表中的%CPU和%MEM。这是判断系统是否健康的首要观察点统计信息区前5行逐行解读第1行系统概况 ───────────────────────────────────────────────────────────── top - 17:21:03 up 4:32, 5 users, load average: 0.19, 0.08, 0.06 ↑当前时间 ↑运行时长 ↑登录用户数 ↑1分钟/5分钟/15分钟平均活跃进程数 load average 解读重要 - 数值 平均有多少进程在等待CPU包括正在运行的 排队等待的 - 判断标准与CPU核心数对比。4核CPU上 load 4.0 基本正常 - 4.0 表示有进程在排队系统过载 - 8.0 表示严重过载需要排查 - 三个值趋势如果1分钟 5分钟 15分钟说明负载在上升要关注第2行进程统计 ───────────────────────────────────────────────────────────── Tasks: 483 total, 3 running, 480 sleeping, 0 stopped, 0 zombie ↑进程总数 ↑运行中 ↑睡眠中 ↑停止 ↑僵尸 Zombie 不为 0 通常意味着程序有bug需要关注。第3行CPU使用率最重要 ───────────────────────────────────────────────────────────── %Cpu(s): 0.3 us, 0.7 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st us (user) : 用户空间程序占用的CPU → 高说明应用程序在干活 sy (system) : 内核空间占用的CPU → 高说明系统调用频繁可能有问题 ni (nice) : 被调整过优先级的进程占的CPU → 通常很低 id (idle) : 空闲CPU百分比 → 越低说明系统越忙 wa (iowait) : 等待I/O完成占用的CPU → 高说明磁盘/网络是瓶颈重要 hi (hardirq) : 硬件中断占用的CPU si (softirq) : 软件中断占用的CPU st (steal) : 被虚拟机偷走的CPU时间仅虚拟机有意义 排障口诀 us高 → 应用程序有问题或请求太多 wa高 → 磁盘I/O是瓶颈换SSD或加内存缓存 id高 系统卡 → 可能有锁竞争或进程挂起第4-5行内存使用率 ───────────────────────────────────────────────────────────── KiB Mem : 3865528 total, 1842620 free, 811540 used, 1211368 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 2743928 avail Mem total/free/used: 物理内存总量/空闲/已用 buff/cache: 内核用做缓存和缓冲的内存可被回收 avail Mem: 新进程实际可用的内存比 free 更准确的指标 Swap used: 如果 0说明物理内存不够用了系统在用磁盘当内存性能急剧下降进程信息区字段字段含义说明PID进程ID唯一标识USER进程所有者PR内核调度优先级由内核动态调整NInice值用户可调-20~19越低优先级越高VIRT虚拟内存KB进程申请的总内存含共享库RES常驻物理内存KB实际占用的物理内存SHR共享内存KB与其他进程共享的内存S进程状态R/S/D/T/Z%CPUCPU占用按核计算%MEM内存占用相对于物理内存总量TIMECPU累计时间进程启动以来占用CPU的总时间COMMAND命令名5.4 进程管理实战命令# 查找进程pgrep-lsshd# 按名字查PID-l显示名称pidof sshd# 直接查sshd的PIDpsaux|grepsshd# 经典组合grep过滤# 查看进程树pstree# 树形展示能清晰看到父子关系# 自定义查看字段psaxo user,pid,ppid,%mem,%cpu,comm--sort-%mem# 按内存占用排序# 结束进程kill-15PID# SIGTERM优雅终止默认kill-9PID# SIGKILL强制终止慎用killall进程名# 按名字批量终止pkill进程名# 按名字终止更灵活六、总结与思考知识脉络图软件安装方式的演进背后的逻辑是什么 ═══════════════════════════════════════ 没有包管理 → 源码编译手工解压 → configure → make → make install ↓ 痛点是每次都要编译依赖要自己找 RPM 诞生 → 二进制预编译包解决了编译问题 1997年 ↓ 痛点是依赖仍需手动解决陷入依赖地狱 YUM 诞生 → 仓库 repodata解决依赖问题 2003年 ↓ 核心创新预计算依赖数据库查表替代递归查找 DNF 迭代 → YUM的下一代RHEL 8 默认 2012年 ↓ 用libsolv库依赖解析性能提升 容器化 → Docker/Flatpak/Snap完全隔离未来趋势核心收获repodata 是YUM仓库的灵魂。它本质上是一个预计算的依赖数据库——primary.xml 记录每个包的 requires 和 providesYUM通过查表匹配一次性计算出完整的依赖链。这一设计思想预计算 → 存起来 → 查表重用在计算机科学中非常经典你可以在构建系统Make、缓存系统、甚至大型软件项目的模块管理中找到类似的设计。从源码到RPM到YUM每一次演进都在解决前一代的痛点编译太慢→用RPM预编译依赖太难→用YUM repodata自动解析。理解了这个演进逻辑你就不会觉得这些工具只是一堆命令。进程是程序的运行时实例是一切故障排查的起点。ps看静态快照、top看动态趋势、kill发信号控制。load average、CPU iowait、swap使用率是系统健康度的三大指标。延伸思考如果你管理多台服务器可以搭建本地YUM仓库镜像使用reposync同步官方源 createrepo生成repodata这样内网服务器从本地仓库安装速度快且不受外网影响。进阶可以结合nginx做HTTP仓库服务器或使用katello/foreman实现企业级的包生命周期管理。本文基于 CentOS 7 实战操作撰写所有截图均为作者实际运行环境所得。repodata 是YUM仓库的灵魂。它本质上是一个预计算的依赖数据库——primary.xml 记录每个包的 requires 和 providesYUM通过查表匹配一次性计算出完整的依赖链。这一设计思想预计算 → 存起来 → 查表重用在计算机科学中非常经典你可以在构建系统Make、缓存系统、甚至大型软件项目的模块管理中找到类似的设计。从源码到RPM到YUM每一次演进都在解决前一代的痛点编译太慢→用RPM预编译依赖太难→用YUM repodata自动解析。理解了这个演进逻辑你就不会觉得这些工具只是一堆命令。进程是程序的运行时实例是一切故障排查的起点。ps看静态快照、top看动态趋势、kill发信号控制。load average、CPU iowait、swap使用率是系统健康度的三大指标。延伸思考如果你管理多台服务器可以搭建本地YUM仓库镜像使用reposync同步官方源 createrepo生成repodata这样内网服务器从本地仓库安装速度快且不受外网影响。进阶可以结合nginx做HTTP仓库服务器。