мешает работе облако загрузка

cloud-init не применяет изменения при перезагрузке

Первичная настройка выполняется один раз за жизнь экземпляра и помечает себя выполненной. Правка описания после этого ничего не меняет, и попытки «перезапустить настройку» вводят в заблуждение: службы завершаются успешно, но ничего не делают.

Вероятные причины

По порядку: сверху то, что встречается чаще.

Этапы уже выполнены и помечены

Состояние хранится в каталоге службы. Пока метка на месте, этапы не повторяются.
Изменения ждут от неподходящего этапа

Служба разбита на этапы с разным моментом запуска. Действие, помещённое в поздний этап, может не успеть повлиять на нужную службу.
Настройку путают с постоянным управлением

Первичная настройка не предназначена для поддержания состояния. Для этого нужны средства управления конфигурацией или собственные unit-файлы.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Состояние первичной настройки и её этапов.

sudo cloud-init status --long

Какие этапы есть и в каком они состоянии.

systemctl list-units "cloud-*" --no-legend

Что делали этапы в текущую загрузку.

sudo journalctl -u cloud-init -u cloud-config -u cloud-final -b --no-pager | tail -30

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Этапы уже выполнены и помечены

Почему происходит: Состояние хранится в каталоге службы. Пока метка на месте, этапы не повторяются.

Как проверить

Посмотрите состояние и метки.

sudo cloud-init status --long 2>/dev/null
sudo ls /var/lib/cloud/instance/sem/ 2>/dev/null | head

Как исправить: Для проверки описания очищайте состояние на тестовой машине и перезагружайте её. На боевой машине правьте настройки штатными средствами, а не через первичную настройку.

2. Изменения ждут от неподходящего этапа

Почему происходит: Служба разбита на этапы с разным моментом запуска. Действие, помещённое в поздний этап, может не успеть повлиять на нужную службу.

Как проверить

Посмотрите этапы и их время.

systemd-analyze blame --no-pager 2>/dev/null | grep -i cloud-init
systemctl list-units "cloud-*" --no-legend

Как исправить: Разнесите действия по этапам осознанно: настройка сети и дисков делается раньше, установка пакетов и команды — позже.

3. Настройку путают с постоянным управлением

Почему происходит: Первичная настройка не предназначена для поддержания состояния. Для этого нужны средства управления конфигурацией или собственные unit-файлы.

Как проверить

Посмотрите, что именно пытаются применять при каждой загрузке.

sudo cloud-init query userdata 2>/dev/null | head -20

Как исправить: Перенесите повторяющиеся действия в обычную службу с нужной целью запуска. Так поведение станет предсказуемым и видимым в журнале.

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

Этапы помечены выполненными, правки не применяются. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

$ sudo cloud-init status --long
status: done
boot_status_code: enabled-by-generator
last_update: Mon, 15 Sep 2026 09:12:33 +0000

systemd[1]: Started cloud-final.service - Execute cloud user/final scripts.
cloud-init[820]: Cloud-init v. 24.1 finished at Mon, 15 Sep 2026 09:12:33 +0000. Up 21.42 seconds

Связанные ошибки

Одноразовая задача: как не получить ложный сбой Правильная настройка Type=oneshot: RemainAfterExit, коды возврата, зависимости и вызов по таймеру.
A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.
Цель не достигнута: служба ждёт target, который не наступает Служба не запускается, потому что не достигнута цель из After= или Requires=. Разбор целей multi-user, network-online, graphical.
Cannot assign requested address при привязке Ошибка 99 при привязке: адрес не принадлежит машине или ещё не поднят. Разбор с network-online.target и ip_nonlocal_bind.
Dependency failed for … и результат 'dependency' Сообщение Dependency failed for: служба не запускалась, потому что упала её зависимость. Как найти настоящего виновника.
Failed with result 'exec-condition' и condition failed Состояния exec-condition и condition failed: запуск не состоялся, потому что условие не выполнено. Это не сбой, а задуманное поведение.
Found ordering cycle: циклическая зависимость при загрузке systemd нашёл цикл в порядке запуска и разорвал его, отбросив одну зависимость. Как найти цикл и правильно расставить After и Requires.
Mount process exited, code=exited, status=32: не найдено устройство Монтирование не проходит: устройство или UUID не найдены, неверная файловая система, недоступен сетевой ресурс. Код 32 от команды mount.

Источники

Документация cloud-init: этапы загрузки документация программы
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено на тестовой машине: повторная загрузка не выполняет этапы заново. собственная проверка, systemd 255
сверено 15 сентября 2026