Systemd: почему файлы в /tmp или /run удаляются через несколько секунд?
Я использую systemd для монтирования общего ресурса Windows с помощью Kerberos. Чтобы это работало, я сначала запускаюkinit
в файле .service для создания кэша учетных данных Kerberos (ccache). Служба .service запускается от имени пользователя root, поскольку ccache должен принадлежать пользователю root (journalctl -xe
помог мне в этом), так как для mount.cifs требуется root. .mount (и .automount) используют ccache для монтирования с использованием Kerberized. Когда я создаю ccache в интерактивном режиме, это работает хорошо. Однако при запуске внутри сервисного модуля ccache быстро удаляется, и (авто)монтирование завершается сбоем. Не имеет значения, сохраню ли я его в /tmp или /run/user/0.
- Почему файлы в /tmp или /run автоматически удаляются?
- Какое предпочтительное расположение для этих файлов ccache? Является
PrivateTmp
лучшее решение? Если да, то как мне обратиться к этому частному каталогу tmp внутри служебного файла? Я пытался%T/krb5cc_root.ccache
, но systemctl выдает ошибку. ЯвляетсяJoinsNamespaceOf
способ использовать один и тот же частный tmp в файле монтирования?
Я использую systemd 219 в Linux CentOS 7. Ниже приведен мой модуль .service. Заранее спасибо!
[Unit]
Description=Kinit keytab for /mnt/windows_staging
After=network.target
Requires=network.target
[Service]
Restart=always
RestartSec=30
PrivateTmp=yes
User=root
Group=users
ExecStartPre=-/bin/mkdir -p /mnt/windows_staging
ExecStartPre=-/bin/mkdir -p /run/user/0
Environment=KRB5_KTNAME=/home/albertjan@domain/myproject/etc/keytabs/albertjan.keytab
Environment=KRB5CCNAME=/run/user/0/krb5cc_root.ccache
ExecStart=/bin/kinit albertjan -kt ${KRB5_KTNAME} -c ${KRB5CCNAME}
ExecStartPost=/bin/sleep 2
ExecStop=-/bin/kdestroy -c ${KRB5CCNAME}
[Install]
WantedBy=multi-user.target
1 ответ
Почему файлы в /tmp или /run автоматически удаляются?
Поскольку ваша служба запускает «демон», который немедленно завершает работу , помечая службу как «остановленную» в течение нескольких секунд после запуска, что приводит кkdestroy
из ExecStop= для запуска.
Вариант 2. Измените определение .service, чтобы сообщить systemd, что это должна быть задача, которая немедленно завершается, используя следующие параметры:
[Service] Type=oneshot RemainAfterExit=yes
The
Type=oneshot
Режим дополнительно полезен, поскольку заставляет systemd ждать полного завершения ExecStart=, прежде чем служба будет помечена как «активная», избегая необходимости добавлять произвольныйsleep 2
. Другими словами, он позволяет вам использоватьAfter=kinit.service
не беспокоясь о том, что другие дела начнутся «слишком рано».Вариант 1. Замените kinit на
k5start
демон с https://www.eyrie.org/~eagle/software/kstart/. Это настоящий демон – длительный процесс – и он будет отслеживаться как таковой. Он также будет обрабатывать периодическое обновление.Если вы используете k5start с
-b
вариант («Отключить при запуске») и измените .service наType=forking
соответственно, вы также получите такое же поведение «задержка до успеха».
(Есть также третий вариант позволитьgssproxy
обрабатывать все билеты, но cifs.upcall в CentOS пока этого не поддерживает. Для других целей, помимо монтирования файловых систем,KRB5_CLIENT_KTNAME
позволит программе самой получать билеты из keytab по мере необходимости, но в этом случае это не сработает.)
Какое предпочтительное расположение для этих файлов ccache?
Лично я бы придерживался/tmp/krb5cc_*
или/run/user/<uid>/krb5cc_*
. (Это единственные места, которые проверяет NFS rpc.gssd.)
Для SMB cifs.upcall будет искать системное расположение по умолчанию для UID, выполняющего монтирование (то есть того, что определено в krb5.conf), которое обычно/tmp/krb5cc_0
когда systemd делает это. (Хотя cifs.upcall может извлечь KRB5CCNAME из среды вызывающего, это не помогает при использовании автоматического монтирования, поскольку cifs.upcall будет видеть в качестве вызывающего только systemd или autofsd.)
Является ли PrivateTmp лучшим решением?
PrivateTmp не поможет, потому что ваш файл удаляет не внешняя задача, а сама служба.