我已经配置了无人值守升级来安装安全包,并在安装时通过邮件通知。
我注意到安装发生的时间非常随机。我知道最新版本从 cron.daily 执行时间开始添加了最长 30 分钟的随机延迟。
然而,我遇到的延迟远不止这些。我看到无人值守升级在上午 9 点、下午 3 点、晚上 12 点执行……日志显示的情况相同,因此不仅仅是电子邮件传递需要更长时间。
无人值守升级任务是 cron.daily 中的第一个任务,这意味着没有先前的执行时间很长的任务。
有人经历过类似的事情吗?
答案1
经过调试后我找到了解决方案。
该问题的根本原因在于,在 Ubuntu 16.04 及更新版本中,无人值守升级使用 systemd(而不是 cron)来安排具有巨大随机延迟的更新:
/lib/systemd/system/apt-daily.timer
配置有
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
这意味着它将每天运行两次,分别在 6:00 和 18:00,随机延迟最多 12 小时。由于这对于生产环境来说并不总是可接受的,因此我不得不覆盖这些设置。
为了保持包配置文件不受影响,我在/etc/systemd/system/apt-daily.timer.d/override.conf
(更新:请阅读此答案底部的编辑以获取有关文件名和位置的更多信息,因为它似乎略有变化)。
我在那里
[Timer]
OnCalendar=
OnCalendar=06:00
RandomizedDelaySec=1h
在 6:00 运行无人值守升级,外加最多一小时的随机延迟。
然后我简单地重新启动了计时器systemctl restart apt-daily.timer
(最终需要重新加载守护进程)。
无人值守更新现在又可以在可预测的时间运行了!
编辑:Ubuntu 18.04 的情况似乎有所改变。覆盖现在应该存储在/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
看起来像这样:
[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=1h
@PerlDuck 在下面的评论中提到了一种使用正确名称和位置创建覆盖文件的方法。请考虑运行,而不是手动创建文件sudo systemctl edit apt-daily.timer
答案2
更新无人值守升级时间的最佳方法是,正如我从各种来源编译并在我们的系统上测试的那样专门使用systemctl
命令并避免尝试寻找合适的文件进行编辑。
你唯一需要确定的是服务名称,在我们的例子中是apt-daily-upgrade
(如果不确定,请通过 搜索$ systemctl | grep apt
)。当 systemd 服务定义了计时器时,它被引用为#{service_name}.timer
,因此它对apt-daily-upgrade.timer
我们来说是这样的。
由于系统配置不能编辑,因此我们必须覆盖默认计时器配置在 systemd 中。为此,您需要复制编辑原始配置的某些部分,因此我们先展示一下:
$ systemctl cat apt-daily-upgrade.timer
# /lib/systemd/system/apt-daily-upgrade.timer
[Unit]
Description=Daily apt upgrade and clean activities
After=apt-daily.timer
[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=12h
Persistent=true
[Install]
WantedBy=timers.target
我们需要更新部分中的OnCalendar
和值。让我们通过以下命令创建覆盖配置文件:RandomizedDelaySec
[Timer]
$ systemctl edit apt-daily-upgrade.timer
这将打开一个带有空白文件的编辑器,我们[Timer]
至少需要将修改后的部分放在那里:
[Timer]
# Reset the system calendar config first
OnCalendar=
# Set a new calendar timer with a 60 minute threshold
OnCalendar=*-*-* 21:00
RandomizedDelaySec=60m
如您所见,我们已更新该OnCalendar
值以在晚上而不是早上触发自动更新。OnCalendar
其上方的空白行必须存在,因为此配置值是添加剂,即它可以被指定多次,并且只有将其设置为空白值才会重置所有先前的OnCalendar
值(来自系统配置的值)。
一旦我们保存了文件,我们就可以通过如上所述再次运行来验证 systemd 是否知道它(无需运行systemctl daemon-reload
,edit
命令会在离开编辑器时为我们执行此操作) :systemctl
$ systemctl cat apt-daily-upgrade.timer
# /lib/systemd/system/apt-daily-upgrade.timer
[Unit]
Description=Daily apt upgrade and clean activities
After=apt-daily.timer
[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=12h
Persistent=true
[Install]
WantedBy=timers.target
# /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
[Timer]
# Reset the system calendar config first
OnCalendar=
OnCalendar=*-*-* 21:00
RandomizedDelaySec=60m
现在它显示了两个配置,其中自定义配置覆盖了默认配置。很好!
list-timers
可以通过以下命令来最终检查一切是否按预期工作systemctl
:
$ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
...
Thu 2020-08-06 21:51:36 UTC 12h left Thu 2020-08-06 07:10:20 UTC 2h 20min ago apt-daily-upgrade.timer apt-daily-upgrade.service
...
在输出中找到正确的行并查看列NEXT
- 其中的值应该反映您新配置的无人值守升级的时间。
答案3
官方 Debian 文档https://wiki.debian.org/UnattendedUpgrades目前有一个错误,误导了很多人。它声称你可以通过创建一个名为的文件来覆盖升级时间
/etc/systemd/system/apt-daily-upgrade.d/override.conf
但正确的路径是
/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
答案4
这apt-daily.timer设置为每天运行两次,不会中断生产环境,因为它只会更新和下载需要更新的软件包。您只需覆盖apt-daily-upgrade.timer将其设置为不太可能影响您的生产环境的时间,因为这是实际安装更新的时间。此外,在 50unattended-upgrades 中有一个需要重新启动的设置,您应该考虑设置它以便它们真正得到应用,并且它还有一个计时器。此外,从 22.04 开始,升级计时器已更改为默认的上午 6 点 + 1 小时,因此大多数人不需要更改它。