SystemdDoctor
служба не работает секреты порядок запуска

Хранилище секретов после перезапуска закрыто и не отдаёт данные

Хранилища секретов после запуска находятся в закрытом состоянии: ключи шифрования не в памяти, данные не отдаются. Это не сбой, а защита. Проблема возникает, когда от службы ждут автоматической готовности после перезагрузки, а зависящие от неё службы падают на пустых секретах.

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

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

  1. Хранилище не открыто после перезапуска

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

  2. Зависящие службы стартуют раньше готовности

    Служба считается запущенной, как только слушает порт. Закрытое состояние для systemd неотличимо от готового.

  3. Данные хранилища на непостоянном разделе

    Если каталог состояния попадает во временную файловую систему, после перезагрузки хранилище оказывается пустым, а не просто закрытым.

Диагностика

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

Состояние хранилища в виде ответа проверки здоровья.

curl -s http://127.0.0.1:8200/v1/sys/health

Сообщения о запуске и состоянии.

journalctl -u vault -n 30 --no-pager | grep -iE "seal|unseal|core"

Где хранятся данные и от кого работает служба.

systemctl show vault -p StateDirectory -p User

Решение

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

1. Хранилище не открыто после перезапуска
Почему происходит
Состояние закрыто по умолчанию. Служба отвечает на проверки здоровья, но отдаёт отказ на запросы данных.
Как проверить
Посмотрите состояние хранилища. 
curl -s http://127.0.0.1:8200/v1/sys/health | head -c 300; echo
journalctl -u vault -n 20 --no-pager | grep -i seal
Как исправить
Откройте хранилище штатной процедурой. Для автоматического открытия применяют внешний хранитель ключа — держать ключ рядом со службой на диске означает потерю смысла шифрования.
2. Зависящие службы стартуют раньше готовности
Почему происходит
Служба считается запущенной, как только слушает порт. Закрытое состояние для systemd неотличимо от готового.
Как проверить
Посмотрите порядок запуска зависящих служб. 
systemctl list-dependencies --reverse vault --no-pager 2>/dev/null | head
systemctl show myapp.service -p After
Как исправить
Добавьте в зависящие службы ожидание реальной готовности: отдельная проверяющая команда перед запуском или перезапуск при сбое с задержкой.
3. Данные хранилища на непостоянном разделе
Почему происходит
Если каталог состояния попадает во временную файловую систему, после перезагрузки хранилище оказывается пустым, а не просто закрытым.
Как проверить
Посмотрите, где лежат данные и какая там файловая система. 
systemctl show vault -p StateDirectory -p WorkingDirectory
findmnt -T /opt/vault/data -o TARGET,FSTYPE 2>/dev/null
Как исправить
Перенесите данные на постоянный раздел и объявите каталог состояния через StateDirectory=: systemd создаст его с верными правами и не потеряет при перезагрузке.

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

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

vault[5000]: ==> Vault server started! Log data will stream in below:
vault[5000]: core: security barrier not initialized
myapp[5100]: fatal: read secret: 503 Service Unavailable (Vault is sealed)
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

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

Источники

  • Документация Vault: состояние хранилища документация программы
    сверено 15 сентября 2026
  • systemd.exec(5)
    StateDirectory= и постоянное хранение данных службы.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено перезагрузкой машины с хранилищем и зависящей службой.     собственная проверка, systemd 255
    сверено 15 сентября 2026