另一天我发现我的 Docker 容器已被杀死因为 docker 守护进程已经在我正在运行的 AWS 机器上自动升级了。
journald
在相应的时间段内显示了这些消息:
Aug 06 05:56:01 ip-192-168-3-117 systemd[1]: Starting Daily apt download activities...
Aug 06 05:56:11 ip-192-168-3-117 systemd[1]: Started Daily apt download activities.
Aug 06 06:06:39 ip-192-168-3-117 systemd[1]: Starting Daily apt upgrade and clean activities...
Aug 06 06:06:48 ip-192-168-3-117 systemd[1]: Reloading.
Aug 06 06:06:48 ip-192-168-3-117 systemd[1]: Starting Message of the Day...
Aug 06 06:06:48 ip-192-168-3-117 systemd[1]: Reloading.
Aug 06 06:06:49 ip-192-168-3-117 systemd[1]: Reloading.
Aug 06 06:06:49 ip-192-168-3-117 systemd[1]: Stopping Docker Application Container Engine...
我怎么知道这个计划什么时候运行?我查看了各种 cron 作业,/etc
我认为其中/etc/cron.daily/apt-compat
涉及了这些,因为它最后包含了以下内容:
# delay the job execution by a random amount of time
random_sleep
# ensure we don't do this on battery
check_power || exit 0
# run daily job
exec /usr/lib/apt/apt.systemd.daily
但事实证明它永远不会走到这一步,因为它实际上只是使用了systemd
。我在开始时忽略了这一点cron.daily/apt-compat
:
# Systemd systems use a systemd timer unit which is preferable to
# run. We want to randomize the apt update and unattended-upgrade
# runs as much as possible to avoid hitting the mirrors all at the
# same time. The systemd time is better at this than the fixed
# cron.daily time
if [ -d /run/systemd/system ]; then
exit 0
fi
因此,systemd 以某种方式安排它运行。
该文件/usr/lib/apt/apt.systemd.daily
基本上看起来像是负责的脚本,尽管我找不到上述任何字符串,例如“Starting .*activities”。
那么 systemd 正在调度这个,但它存储在哪里?它被告知在哪里运行/usr/lib/apt/apt.systemd.daily
?
答案1
这是一个 systemd 定时器。您可以使用以下命令检查 systemd 定时器的状态:
systemctl list-timers
它应该列出apt-daily.timer
。您可以使用以下方式检查其规范:
systemctl show apt-daily.timer
该文件位于/lib/systemd/system/apt-daily.timer
(如果要修改计时器,请不要直接编辑该文件。请参阅如何覆盖或配置 systemd 服务?)