☰

Systemd: /tmp または /run 内のファイルが数秒後に削除されるのはなぜですか?

tag-icon • tag-icon linux centos7 systemd systemd-service
Systemd: /tmp または /run 内のファイルが数秒後に削除されるのはなぜですか?

私は systemd を使用して、Kerberos を使用する Windows 共有をマウントしています。これを機能させるには、まずkinit.service ファイルを実行して Kerberos 認証情報キャッシュ (ccache) を作成します。ccache は root によって所有される必要があるため (journalctl -xeが役立ちました)、.service は root として実行されます。mount.cifs には root が必要です。.mount (および .automount) は ccache を使用して Kerberos マウントを実行します。ccache を対話的に作成すると、これはうまく機能します。ただし、サービス ユニット内で実行すると、ccache はすぐに削除され、(自動) マウントが失敗します。/tmp に保存しても、/run/user/0 に保存しても問題ありません。

  1. /tmp または /run 内のファイルが自動的に削除されるのはなぜですか?
  2. これらの ccache ファイルの推奨される場所はどこですか?PrivateTmpより良い解決策はありますか? もしそうなら、サービス ファイル内のプライベート tmp ディレクトリを参照するにはどうすればよいですか? 試しましたが%T/krb5cc_root.ccache、systemctl でエラーが発生します。JoinsNamespaceOfマウント ファイルで同じプライベート tmp を使用する方法はありますか?

私は Linux CentOS 7 で systemd 219 を使用しています。以下は私の .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 内のファイルが自動的に削除されるのはなぜですか?

あなたのサービスはすぐに終了する「デーモン」を起動しますしたがって、サービスは開始後数秒以内に「停止」としてマークされ、kdestroyExecStop= が実行されることになります。

  • オプション2: .service定義を変更してsystemdにこれを通知する察するに以下のオプションを使用して、すぐに終了するタスク:

    [Service]
Type=oneshot
RemainAfterExit=yes

    このType=oneshotモードはさらに便利です。サービスが「アクティブ」としてマークされる前に、systemd が ExecStart= が完全に完了するまで待機するため、任意の を追加する必要がなくなります。言い換えると、他のものが「早すぎる」開始になることを心配せずにsleep 2使用できます。After=kinit.service

  • オプション1: kinitをk5start以下のデーモンに置き換えるhttps://www.eyrie.org/~eagle/software/kstart/これは実際のデーモン（長時間実行されるプロセス）であり、そのように追跡されます。定期的な更新も処理します。

    オプション (「起動時にデタッチ」)付きで k5start を使用し-b、それに応じて .service をType=forkingモードに変更すると、同じ「成功するまで遅延」動作も得られます。

(すべてのチケットを処理させる 3 番目のオプションもありますgssproxyが、CentOS の cifs.upcall はまだこれをサポートしていません。ファイルシステムのマウント以外の用途では、KRB5_CLIENT_KTNAMEプログラム自体が必要に応じて keytab からチケットを取得できるようにしますが、この場合は機能しません。)

これらの ccache ファイルの推奨される場所はどこですか?

/tmp/krb5cc_*個人的には、または を使用します/run/user/<uid>/krb5cc_*。(これらは NFS rpc.gssd がチェックする唯一の場所です。)

SMB の場合、cifs.upcall はマウントを実行している UID (つまり、krb5.conf で定義されているもの) のシステム デフォルトの場所を参照します。これは通常、/tmp/krb5cc_0systemd がマウントを実行しているときです。(cifs.upcall は呼び出し元の環境から KRB5CCNAME を取得できますが、cifs.upcall は呼び出し元として systemd または autofsd のみを認識するため、自動マウントが関係している場合は役に立ちません。)

PrivateTmp はより良い解決策でしょうか?

PrivateTmp は役に立ちません。ファイルを削除するのは外部タスクではなく、サービス自体だからです。

関連情報