служба не работает учётные данные секреты версии

status=243/CREDENTIALS в systemd

Код 243/CREDENTIALS относится к механизму учётных данных systemd — способу передать службе секрет файлом, не выкладывая его в окружение. Отказ значит, что нужный файл не найден, недоступен или не расшифровывается.

Что это значит

Учётные данные монтируются службе в каталог, путь к которому она получает в переменной CREDENTIALS_DIRECTORY. Это заметно надёжнее, чем Environment= с паролем: переменные окружения видны в systemctl show и в /proc, а каталог учётных данных доступен только процессу службы.

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

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

Файл из LoadCredential= не существует

Путь указывается после двоеточия: LoadCredential=db-pass:/etc/myapp/db.pass. Если файла нет, запуск не проходит.
Зашифрованные данные не расшифровываются

Для LoadCredentialEncrypted= нужен тот же ключ, которым данные шифровались. При переносе на другую машину или после смены TPM-состояния расшифровка не пройдёт.
Версия systemd не поддерживает указанный способ

Механизм учётных данных появился в systemd 247 и развивался постепенно: ImportCredential= доступен только с версии 254. На более старой системе параметр окажется незнакомым.

Диагностика

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

Показывает шаг CREDENTIALS и имя данных, которое не удалось подготовить.

journalctl -xeu myapp.service --no-pager -n 20

Все объявленные учётные данные службы в одном выводе.

systemctl show myapp.service | grep -i credential

Показывает учётные данные, доступные системе.

sudo systemd-creds list

Решение

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

1. Файл из LoadCredential= не существует

Почему происходит: Путь указывается после двоеточия: LoadCredential=db-pass:/etc/myapp/db.pass. Если файла нет, запуск не проходит.

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

Посмотрите значение и проверьте путь.

systemctl show myapp.service -p LoadCredential
sudo ls -l /etc/myapp/db.pass

Как исправить

Создайте файл с секретом и закройте права: читать его будет systemd от root, поэтому доступ остальным не нужен.

sudo install -m 0600 /dev/null /etc/myapp/db.pass

2. Зашифрованные данные не расшифровываются

Почему происходит: Для LoadCredentialEncrypted= нужен тот же ключ, которым данные шифровались. При переносе на другую машину или после смены TPM-состояния расшифровка не пройдёт.

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

Попробуйте расшифровать данные вручную.

sudo systemd-creds decrypt /etc/myapp/db.cred -

Как исправить

Перешифруйте секрет на этой машине.

sudo systemd-creds encrypt --name=db-pass plain.txt /etc/myapp/db.cred

3. Версия systemd не поддерживает указанный способ

Почему происходит: Механизм учётных данных появился в systemd 247 и развивался постепенно: ImportCredential= доступен только с версии 254. На более старой системе параметр окажется незнакомым.

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

Посмотрите версию systemd.

systemctl --version | head -1

Как исправить: Используйте LoadCredential=, доступный в вашей версии, либо обновите systemd.

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

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

× myapp.service - My application
     Active: failed (Result: exit-code) since Mon 2026-09-15 09:41:52 MSK; 1s ago
    Process: 5300 ExecStart=/usr/local/bin/myapp (code=exited, status=243/CREDENTIALS)

systemd[1]: myapp.service: Failed to set up credentials: No such file or directory
systemd[1]: myapp.service: Main process exited, code=exited, status=243/CREDENTIALS

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

status=237/KEYRING в systemd Код 237/KEYRING: не удалось подготовить связку ключей ядра для службы. Обычно ограничение окружения или исчерпание квоты.
status=226/NAMESPACE в systemd Код 226/NAMESPACE: не удалось настроить пространства имён монтирования, UTS или IPC. Частая причина — путь в ReadOnlyPaths= или ProtectHome=.
status=216/GROUP в systemd Код 216/GROUP: systemd не смог определить или сменить группу из Group= или SupplementaryGroups=. Причины и как проверить.
status=217/USER в systemd Код 217/USER означает, что systemd не смог определить или сменить пользователя из User=. Разбор причин: пользователя нет, имя недопустимо, конфликт с DynamicUser.
status=224/PAM в systemd Код 224/PAM: не удалось открыть сеанс PAM для службы. Обычно нет нужного файла настроек в /etc/pam.d.
status=244/BPF в systemd Код 244/BPF: не удалось применить ограничения через BPF, например RestrictFileSystems=. В man-странице systemd этот код указан неверно.
status=245/KSM в systemd Код 245/KSM: не удалось включить объединение одинаковых страниц памяти через MemoryKSM=. Код появился в systemd 254.
Параметр не работает: он появился в более новой версии systemd Настройка из документации не действует, потому что версия systemd на сервере старше. Как проверить версию и найти замену.

Источники

systemd.exec(5)
243 EXIT_CREDENTIALS: не удалось подготовить учётные данные службы. официальная документация, systemd 255
сверено 15 сентября 2026
systemd-creds(1)
Работа с учётными данными: создание, шифрование, просмотр. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено с LoadCredential на несуществующий файл. собственная проверка, systemd 255
сверено 15 сентября 2026