unattended-upgrades механизм Ubuntu для автоматической установки обновлений пакетов в фоне

unattended-upgrades — стандартный механизм Ubuntu для автоматической установки обновлений пакетов в фоне, без участия администратора. Устанавливается по умолчанию на большинстве образов Ubuntu Server (Чек лист по настройке VPS/VDS, выделенного сервера Linux с нуля).

Важно понимать, что это не одна служба, а связка из нескольких systemd-юнитов:

1. `unattended-upgrades.service` — не выполняет установку пакетов сам. Он всегда в состоянии `active (running)`, пока система работает, и ждёт сигнала завершения (`–wait-for-signal`), чтобы успеть докатить уже начатые обновления перед выключением или перезагрузкой хоста.
2. `apt-daily.timer` / `apt-daily.service` — обновляет списки пакетов (аналог `apt update`).
3. `apt-daily-upgrade.timer` / `apt-daily-upgrade.service` — реально запускает установку разрешённых обновлений (аналог `apt upgrade`, но с фильтром по источникам).

Именно второй таймер отвечает за фактическую установку пакетов — на нём стоит сосредоточиться, если нужно понять, когда сервер что-то себе ставит.

Узнать расписание на конкретном сервере:

systemctl list-timers | grep apt

Пример вывода:

Tue 2026-09-22 05:37:23 UTC  apt-daily.timer          apt-daily.service
Tue 2026-09-22 06:24:15 UTC  apt-daily-upgrade.timer  apt-daily-upgrade.service

Время не фиксированное — systemd-таймеры используют рандомизацию в пределах окна, поэтому точный момент запуска будет немного плавать день ото дня.

Конфиг лежит в /etc/apt/apt.conf.d/50unattended-upgrades. Из коробки на LTS-релизах Ubuntu (проверено на 24.04/26.04) он уже настроен разумно:

• Разрешённые источники (`Allowed-Origins`) ограничены security-каналами (`-security`, `ESMApps…-apps-security`, `ESM…-infra-security`) плюс базовый `"${distro_id}:${distro_codename}"`, который на практике почти не матчит новые пакеты — после релиза обновления идут через `-security` или `-updates` (последний в дефолтной конфигурации закомментирован).
• Автоматическая перезагрузка (`Automatic-Reboot`) по умолчанию не включена: если директива не задана в конфиге явно, `unattended-upgrades` трактует это как `false`. То есть сервер сам себя не перезагрузит.

Менять конфиг без конкретной причины не обязательно — стандартные настройки Ubuntu уже покрывают базовый сценарий «ставить только патчи безопасности, не трогая аптайм».

Если вручную запустить apt install / `apt upgrade в момент, когда фоновый таймер уже занял блокировку `dpkg`, можно получить:

Could not get lock /var/lib/dpkg/lock-frontend

Это не ломает систему и не роняет сервисы — apt либо подождёт освобождения лока, либо завершится с ошибкой, если запущен без retry. Чтобы не сталкиваться с этим, старайтесь не запускать ручные обновления в окно срабатывания apt-daily-upgrade.time` (в примере выше — около 05:30–06:30 UTC; на вашем сервере может отличаться).

Проверить, что реально настроено сейчас (без комментариев и пустых строк):

cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -v '^[[:space:]]*//' | grep -v '^[[:space:]]*$'

Проверить, какие пакеты были бы обновлены при следующем запуске, без реальной установки (dry-run):

sudo unattended-upgrade --dry-run --debug

Полезно, чтобы убедиться, что в списке кандидатов только security-пакеты, а не что-то лишнее.

Применить изменения после правки конфига:

sudo systemctl restart unattended-upgrades

Проверить статус:

systemctl status unattended-upgrades

Active (running) с `–wait-for-signal` в логе — это нормальное, штатное состояние, не признак проблемы.

На большинстве VPS с дефолтным конфигом Ubuntu unattended-upgrades можно оставить как есть: ставятся только патчи безопасности, автоперезагрузки нет. Вмешательство в конфиг оправдано только если требуется более строгий контроль (например, полностью ручное управление обновлениями через Ansible) или если фактическое окно срабатывания таймера пересекается с вашими собственными операциями на сервере.