1. 从一次磁盘告警说起snapd 是怎么把根分区吃满的那天下午监控面板突然弹出一条磁盘使用率告警某台跑着 Ubuntu 18.04 的构建机根分区使用率冲到了 100%。第一反应是日志爆了结果du -sh一层层扒下来发现/var/lib/snapd这个目录大得离谱再往下看/var/lib/snapd/snaps里堆了几十个.snap文件每个动辄几百 MB还有一堆带_xxx.snap后缀的旧版本残留。更离谱的是/var/lib/snapd/cache里还躺着不少下载了一半或者下载完没清理的包。这就是 snap 在 Ubuntu 18.04 上的典型表现它默认保留每个 snap 应用的两个历史版本用于回滚加上自动刷新机制会周期性拉取新版本时间一长磁盘就被这些看不见的包给撑爆了。很多人装完系统后压根没注意过 snapd 这个后台服务直到磁盘告警才想起来还有这么个东西。这篇内容就是围绕Ubuntu 18 上 snap 占用 100% 该怎么处理、要不要直接卸载 snap这个真实场景展开的。我会把 snap 的磁盘占用来源拆清楚讲明白为什么它这么能占空间然后给出从清理瘦身到彻底卸载的完整操作路径包括卸载过程中那些容易把系统搞出问题的坑。适合所有用 Ubuntu 18.04/20.04 做服务器、构建机、开发机的朋友参考尤其是磁盘空间紧张、又不想重装系统的场景。先说结论snap 不是不能用但如果你不需要它卸载是完全可行的只是 Ubuntu 18.04 上卸载 snap 有几个必须注意的依赖关系处理不好会导致某些软件装不上或者系统组件异常。下面一步步来。2. snap 到底把磁盘空间花在哪了在动手清理之前得先搞清楚空间到底被什么吃掉了。盲目rm -rf是运维大忌尤其是/var/lib/snapd这种被系统服务管理的目录删错了轻则 snap 命令报错重则影响依赖 snap 的系统组件。2.1 三个主要的空间消耗点snap 的磁盘占用主要集中在三个地方我用一台典型的 Ubuntu 18.04 构建机举例数据是实测的目录路径内容说明典型占用/var/lib/snapd/snaps已安装的 snap 包文件含历史版本5-15 GB/var/lib/snapd/cache下载缓存安装完通常不自动清理1-5 GB/var/lib/snapd/seed及/snap系统预装 snap 及挂载点数百 MB/var/lib/snapd/snaps是大头。关键在于 snap 的版本管理策略每次 snap 应用更新旧版本不会立即删除而是保留下来作为回滚点。默认情况下snapd会保留最近的两个版本当前版 上一个版本。如果你机器上装了十几个 snap 应用每个应用多留一个几百 MB 的旧版本几个 GB 就这么没了。/var/lib/snapd/cache则是另一个隐形杀手。snapd 在下载新版本时会先把包缓存到这里安装完成后这个缓存并不总是被清理。我见过一台机器上这个目录堆了 3 GB 多的缓存文件全是已经安装过的包的副本。2.2 为什么 snap 的包这么大很多人会问同样一个应用deb 包可能就几十 MB为什么 snap 包动辄几百 MB原因在于 snap 的打包哲学是自包含每个 snap 包都自带运行时依赖包括它需要的库、甚至部分基础运行时。这样做的好处是跨发行版兼容、依赖隔离代价就是体积膨胀。打个比方deb 包像是共享工具箱里的零件大家共用系统里的库snap 包则像是自带工具箱的整套工具走到哪都能用但每个都背着一整套家伙什。对于磁盘紧张的服务器来说这个代价往往不划算。2.3 先做一次体检别急着删动手前先跑几条命令摸清现状# 查看 snapd 整体占用 sudo du -sh /var/lib/snapd # 分别看 snaps 和 cache sudo du -sh /var/lib/snapd/snaps sudo du -sh /var/lib/snapd/cache # 列出所有已安装的 snap 及其版本 snap list --all # 查看磁盘整体情况 df -h /snap list --all这条命令很关键它会列出每个应用的所有已安装版本被禁用的旧版本会标注disabled。这些 disabled 的版本就是可以安全清理的对象。提示如果snap命令本身响应很慢甚至卡住说明 snapd 服务可能有问题可以先sudo systemctl status snapd看看服务状态必要时重启服务再操作。体检完之后你心里就有数了如果只是历史版本和缓存占空间清理就能解决如果确实不需要 snap那就走卸载路线。两条路我都讲。3. 不卸载也能救清理历史版本和缓存的实操如果你的系统里有正在用的 snap 应用或者某些组件依赖 snap那优先考虑清理而不是卸载。清理的核心思路就两条删掉 disabled 的旧版本清掉下载缓存。3.1 用 snap 自带命令清理旧版本snap 提供了set命令来调整保留策略把历史版本保留数设为 1这样每次更新后旧版本会被自动清理# 全局设置只保留 1 个版本即当前版本 sudo snap set system refresh.retain2这里解释一下refresh.retain这个参数它的值表示保留的版本总数最小值是 2最大值是 20。设成 2 意味着保留当前版本加一个回滚版本。注意它不能设成 1这是 snapd 的硬性限制因为至少要留一个回滚点。设置完之后已经存在的旧版本不会立即消失需要触发一次清理。可以手动执行# 手动触发一次刷新让 snapd 重新评估版本保留 sudo snap refresh如果旧版本还在可以逐个删除。先找出所有 disabled 的版本# 列出所有 disabled 的 snap 版本 snap list --all | awk /disabled/{print $1, $3}然后针对每个结果执行删除格式是snap remove 应用名 --revision版本号# 示例删除某个应用的旧版本 sudo snap remove firefox --revision1234一条条删太累的话可以用循环批量处理# 批量删除所有 disabled 版本 snap list --all | awk /disabled/{print $1, $3} | while read name rev; do sudo snap remove $name --revision$rev done注意snap remove删除的是指定 revision 的包不会影响当前正在使用的版本。但执行前最好确认一下当前版本号避免误删。用snap list看当前版本和--all里的 disabled 版本区分开。3.2 清理下载缓存/var/lib/snapd/cache里的缓存文件可以直接删snapd 不会因此出问题它只是下载中转站# 查看缓存占用 sudo du -sh /var/lib/snapd/cache # 清空缓存目录内容 sudo rm -rf /var/lib/snapd/cache/*删完之后再df -h看一下通常能回收不少空间。我实测过一台机器光清缓存就释放了 2.3 GB。3.3 清理后验证清理完做一次验证确认 snap 功能正常# 确认 snapd 服务正常 sudo systemctl status snapd # 确认已安装应用列表正常 snap list # 再次查看占用 sudo du -sh /var/lib/snapd如果snap list能正常输出服务状态是 active那就说明清理没伤到系统。这套清理方案适合想留着 snap 但磁盘紧张的场景风险低、见效快。不过说实话如果你的机器上压根没在用任何 snap 应用那清理只是治标卸载才是治本。下面重点讲卸载。4. 彻底卸载 snapUbuntu 18.04 上的完整路径卸载 snap 这件事网上很多教程只给了三条命令就完事但实际执行时会遇到各种依赖问题。Ubuntu 18.04 上尤其要注意因为系统里有些组件是通过 snap 安装的比如snapd本身、某些版本的gnome相关组件甚至lxd。直接暴力卸载可能导致系统组件缺失。4.1 卸载前必须确认的三件事第一确认没有正在使用的 snap 应用。跑snap list如果列表里有你日常在用的东西比如某些编辑器、工具先想清楚替代方案。Ubuntu 18.04 上常见的预装 snap 有core、snapd、gnome-*系列、lxd等。第二确认系统里没有依赖 snap 的关键组件。Ubuntu 18.04 的桌面版里部分 GNOME 组件是通过 snap 分发的。如果你用的是服务器版无桌面这个顾虑小很多。可以用下面这条命令看看哪些包依赖 snapd# 查看依赖 snapd 的已安装包 dpkg -l | grep -i snap apt-cache rdepends snapd第三确认你有 root 权限并且做好了快照或者备份。卸载 snap 涉及删除系统目录和卸载 apt 包操作不可逆生产环境务必先备份关键数据。4.2 分步卸载流程确认无误后按下面的顺序操作。顺序很重要先删应用再删服务最后清目录。第一步删除所有已安装的 snap 应用# 列出所有应用名 snap list | awk NR1 {print $1} # 逐个删除把 app 替换成实际应用名 sudo snap remove app如果应用多同样可以循环# 批量删除所有 snap 应用 snap list | awk NR1 {print $1} | while read app; do sudo snap remove $app done注意snap remove有些应用会失败比如core、snapd这类基础组件它们需要单独处理。第二步停止并禁用 snapd 服务# 停止 snapd 相关服务 sudo systemctl stop snapd.service snapd.socket snapd.seeded.service # 禁用开机自启 sudo systemctl disable snapd.service snapd.socket snapd.seeded.service # 屏蔽服务防止被其他依赖拉起 sudo systemctl mask snapd.servicemask这一步很关键。Ubuntu 18.04 上有些 apt 包会通过依赖关系把 snapd 重新拉起来mask能彻底阻断这种可能。第三步卸载 snapd 的 apt 包# 卸载 snapd sudo apt-get remove --purge snapd -y # 清理不再需要的依赖 sudo apt-get autoremove --purge -y--purge参数会同时删除配置文件autoremove会清理 snapd 带进来的依赖包。第四步删除残留目录# 删除 snap 相关目录 sudo rm -rf /var/lib/snapd sudo rm -rf /var/cache/snapd sudo rm -rf /snap sudo rm -rf /var/snap第五步阻止 apt 自动重装 snapd。Ubuntu 18.04 上有个坑某些 apt 操作会触发 snapd 被重新安装因为系统里存在一个snapd的推荐依赖。需要创建一个 apt 配置文件来阻止# 创建 apt 配置禁止自动安装 snapd sudo tee /etc/apt/apt.conf.d/99-no-snapd EOF Package: snapd Pin: release a* Pin-Priority: -10 EOF这个配置的作用是把 snapd 的安装优先级设为负数apt 就不会主动安装它了。4.3 卸载后的验证与收尾卸载完成后验证一下# 确认 snap 命令已不存在 which snap # 确认 snapd 服务已消失 systemctl status snapd # 确认目录已清理 ls /var/lib/snapd 2/dev/null || echo 已清理 # 查看磁盘空间 df -h /如果which snap返回空服务查询报 not found目录不存在那就说明卸载干净了。这时候再看df -h根分区的使用率应该明显下降。提示卸载 snap 后如果你之前用 snap 装过某些应用需要找 deb 版本或者官方二进制包替代。比如某些浏览器、编辑器官方都提供 deb 包或 tar 包提前准备好替代方案再卸载避免影响工作。5. 卸载过程中最容易踩的四个坑这一节是我在实际操作中踩过的坑也是很多教程不会提的地方。每一条都对应一个具体的失败场景照着排查能省不少时间。5.1 坑一卸载后 apt 又偷偷把 snapd 装回来这是 Ubuntu 18.04 上最烦人的问题。你明明卸载了 snapd结果某次apt install某个软件时它作为推荐依赖又被装回来了。原因在于 Ubuntu 的 apt 配置里很多包把 snapd 列为Recommends而 apt 默认会安装推荐依赖。解决办法就是上面提到的Pin-Priority: -10配置。如果已经装回来了先按卸载流程再走一遍然后加上这个配置。验证方法# 检查 snapd 是否被标记为自动安装 apt-mark showauto | grep snapd # 如果存在手动标记为不自动安装 sudo apt-mark manual snapd更彻底的做法是检查/etc/apt/apt.conf.d/下有没有其他配置在拉 snapd以及/var/lib/dpkg/status里 snapd 的状态。5.2 坑二删除 /snap 目录后某些命令报错/snap是个挂载点目录snap 应用运行时会在这里挂载。如果你在 snapd 服务还在运行的时候直接rm -rf /snap可能会遇到device or resource busy的报错因为目录被挂载占用了。正确顺序是先停服务、卸载应用再删目录。如果已经卡住了用mount命令看看有没有残留挂载# 查看 snap 相关挂载 mount | grep snap # 如果有残留手动卸载 sudo umount /snap/core/xxxx把所有 snap 挂载卸载掉之后再删目录就顺畅了。5.3 坑三桌面版卸载 snap 后 GNOME 组件异常Ubuntu 18.04 桌面版里部分 GNOME 组件比如某些版本的软件中心、计算器等是通过 snap 分发的。如果你把这些删了桌面可能会出现功能缺失。这种情况建议不要全量卸载而是保留必要的 GNOME snap 组件只清理不用的应用和缓存。判断方法snap list里带gnome前缀的以及core、snapd本身桌面版要谨慎处理。服务器版则基本可以放心全卸。5.4 坑四磁盘空间没释放df 和 du 对不上有时候你删了文件du显示目录变小了但df显示磁盘还是满的。这通常是因为有进程还持有已删除文件的句柄空间没真正释放。用lsof找出来# 查找持有已删除文件的进程 sudo lsof | grep deleted | grep snap # 或者更通用地找 sudo lsof L1 | grep snap找到之后重启对应进程或者直接重启系统空间就会释放。snapd 服务是常见的占着茅坑的进程卸载前先停服务能避免这个问题。6. 卸载之后替代方案与长期维护建议snap 卸掉了原来用 snap 装的东西怎么办这是必须提前想好的问题。另外卸载只是第一步长期来看还得有套机制防止它卷土重来。6.1 常见 snap 应用的 deb 替代Ubuntu 生态里绝大多数常用软件都提供 deb 包或者官方 apt 源。下面列几个典型替代snap 应用deb/apt 替代方案FirefoxMozilla 官方 apt 源或系统自带 deb 版Chromium部分发行版提供 deb或用官方二进制VS Code微软官方 apt 源DockerDocker 官方 apt 源Node.jsNodeSource apt 源或 nvm核心思路是优先找官方 apt 源其次用官方提供的二进制包最后才考虑第三方打包。apt 源的好处是能跟着系统更新依赖管理也统一。6.2 防止 snapd 复活的长期配置前面提到的Pin-Priority: -10是基础。此外还可以定期检查apt-mark showauto | grep snapd发现被自动安装就处理掉。在apt upgrade前先apt list --upgradable | grep snap看看有没有 snap 相关更新。如果是批量管理的机器把禁用 snapd 的配置写进基础镜像或者配置管理脚本里一次性解决。6.3 磁盘监控的小建议这次磁盘告警的根源其实是缺乏对/var/lib/snapd这类隐形大户的监控。建议在监控系统里加几条针对性的检查对/var/lib/snapd单独做容量监控设置阈值告警。定期跑snap list --all统计 disabled 版本数量超过阈值就清理。把du -sh /var/lib/snapd/*纳入日常巡检脚本。我在实际运维中的体会是snap 的问题往往不是它本身有多糟而是它的空间占用不透明默认策略又偏向多留版本导致很多人直到磁盘满了才发现。与其被动救火不如主动监控。最后分享一个我常用的小脚本放在 cron 里定期清理 snap 缓存和旧版本适合那些必须保留 snap 的机器#!/bin/bash # snap 清理脚本建议每周执行一次 set -e # 清理下载缓存 sudo rm -rf /var/lib/snapd/cache/* # 删除所有 disabled 版本 snap list --all | awk /disabled/{print $1, $3} | while read name rev; do sudo snap remove $name --revision$rev || true done # 输出清理后占用 echo 清理完成当前 snapd 占用 sudo du -sh /var/lib/snapd这个脚本我用了挺长时间配合监控告警基本没再遇到过 snap 把磁盘吃满的情况。至于到底卸不卸 snap我的建议是服务器和构建机如果不用 snap 应用果断卸桌面版如果依赖 GNOME snap 组件就保留但做好清理和监控。没有一刀切的答案关键是把空间去向搞清楚把控制权拿回自己手里。
