Ubuntu 更新“卡死”惊魂记：揪出占用 apt 锁的“隐形罪魁祸首”！
惊魂记：Ubuntu apt update 报错无法更新
今天照例用手机登录服务器日常维护一下，顺手敲下大家倒背如流的 sudo apt update && sudo apt upgrade，准备给系统更个新。结果直接被兜头浇了一盆冷水：
tjsky@vm1234:~# sudo apt update && sudo apt upgrade
Reading package lists... Done
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 31896 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to lock directory /var/lib/apt/lists/
我还是头一次遇到这种 Ubuntu apt update 报错的事情。于是只好起身打开电脑，在网上一搜，中文教程里都让我简单粗暴地执行 sudo rm -rf /var/lib/apt/lists/lock直接把带锁文件给删了，作为一个曾经干出《一行 rm -rf 删光了我的博客》，3年多的博客被炸到什么都不剩的人，对rm命令那是相当慎重的，果断找 AI 学习了一番相关知识。
果然，又是一如既往的：垃圾教程污染中文互联网！
而且其实系统提示里已经苦口婆心地警告过我了：removing the lock file is not a solution。强删锁文件和不弹出就直接热拔插 U 盘有啥区别。虽然确实能强行解决报错，但鬼知道文件系统里会变成什么样。
第一回合：排查 apt-get 进程卡死（寻找消失的 31896 进程）
那既然系统说锁现在是被 PID=31896 进程占用了，那我就来看看它到底在干嘛：
tjsky@vm1234:~# ps -f -p 31896
UID PID PPID C STIME TTY TIME CMD
root 31896 31868 0 Apr18 ? 00:00:50 apt-get -qq -y update
好家伙， STIME（启动时间）赫然写着 Apr18！。今天可是Apr28！ 已经在后台默默“挂机”了一个多星期了！（估计可能碰上了网络波动或者镜像源超时，然后就卡死了？）
看眼这进程是什么东西启动的，能不能干掉（虽然已经大致猜到是什么了）
tjsky@vm1234:~# pstree -aps 31896
systemd,1
└─systemd,1055
└─apt.systemd.dai,31868 /usr/lib/apt/apt.systemd.daily update
└─apt-get,31896 -qq -y update
额，这不是系统默认的每天自动刷新软件源的定时任务嘛，那就简单了，既然应该不是在下载安装中卡死，那直接干死就行：
tjsky@vm1234:~# sudo kill -9 31896
# 把它的父进程也送走
tjsky@vm1234:~# sudo kill -9 31868
# 虽然按说应该是卡在刷新软件列表了，不过以防万一，还是修复一下可能存在的安装状态
tjsky@vm1234:~# sudo dpkg --configure -a
没有任何输出直接回到命令提示符，不错，毕竟在 Linux 的世界里，有一条著名的“Unix 哲学”：没有消息就是好消息。
第二回合：查阅 systemd 日志，揭开 apt 更新锁死的真相
作为一个好奇心满满的折腾党，只是把僵尸进程干死了可不行，我要去看看这 10 天到底发生了什么。
首先，去翻 apt 自己的记录 /var/log/apt/history.log，结果发现 4 月 18 日这天没有任何记录。
诶，我去，不可能啊，没记录？那4月18号那天是什么东西启动的更新，见鬼了？
又往前翻了几天的日志，转念一想，哦，卡死的命令是 update，它只是去远程拉取最新的软件清单索引，并没有实际 install 或 upgrade 任何具体的软件包，搞不好这时候确实不写入history.log的，毕竟之前也没有看到过update的记录。
那既然 apt 的日志里没记录，那就去问问系统大管家 systemd呗。
tjsky@vm1234:~# sudo journalctl --since "2026-04-18" --until "2026-04-19" | grep -i apt
果然
Apr 18 06:29:39 vm1234 systemd[1]: Starting Daily apt upgrade and clean activities...
Apr 18 06:29:42 vm1234 systemd[1]: Finished Daily apt upgrade and clean activities.
# 上面是早上的正常升级检查，几秒钟就顺利跑完了。重点在下面：
Apr 18 14:43:39 vm1234 systemd[1]: Starting Daily apt download activities...
下午 14:43 分触发的 apt-daily.service（后台更新软件源），只有 Starting，没有 Finished。进程一直拿着 apt 的进程锁占着茅坑不拉屎，导致这 10 天内所有的后续更新都被堵在了门外。
第三回合：漫长的 Waiting for cache lock 报错
查明真相并清理完后，我信心满满地再次执行了手动更新命令。结果，屏幕上又开始疯狂刷屏：
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 47902 (unattended-upgr)
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 47902 (unattended-upgr)
...
不是，这难道又卡死了？我不是刚干死卡死的每日更新嘛，这又是啥东西在为难我。
仔细了一眼，看占用锁的进程变成了 unattended-upgr。于是就去查了一下这是个啥玩意，AI告诉我：“这是 Ubuntu 系统自带的后台自动安全更新服务。”
合着我手动更新的时候，恰好撞上了系统正在后台默默打安全补丁，用了快10年的Ubuntu，还是头一次碰到系统自动安全更新的😂。
那就只能等了，不过幸好也就等了1分钟不到，日志画风一转：
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 59297 (apt-get)
Reading package lists... Done
Building dependency tree... Done
...
锁被释放了，熟悉的 Do you want to continue? [Y/n] 终于弹了出来。按Y，回车，收工！
总结
要是你们碰到 /var/lib/apt/lists/lock 被占用，或者 apt 进程死锁，记住啊：
- 管住手，别删锁：我是真的被
rm搞怕了，直接把自己3年多的博客全删了的惨状还历历在目，当时吓的血都凉了。 - 查日志，找元凶：下次就别学我先
kill进程了，应该先journalctl看看系统最后在干啥，判断一下到底是真死锁了还是在跑大任务，然后再决定是否直接杀进程。 - 淡定，一定要淡定：如果看到
Waiting for cache lock，不慌，系统会帮着把队列排得明明白白的。毕竟Ubuntu 24.04 的代号是 Noble Numbat （高贵的食蚁兽）体现了系统的成熟与可靠（吗？）。
