☰

Systemd：為什麼 /tmp 或 /run 中的檔案會在幾秒鐘後被刪除？

tag-icon • tag-icon linux centos7 systemd systemd-service
Systemd：為什麼 /tmp 或 /run 中的檔案會在幾秒鐘後被刪除？

我正在使用 systemd 透過 Kerberos 掛載 Windows 共用。為了完成這項工作，我首先kinit在 .service 檔案中運行以建立 Kerberos 憑證快取 (ccache)。 .service 以 root 身份運行，因為 ccache 需要由 root 擁有（journalctl -xe這幫助了我），因為 mount.cifs 需要 root。 .mount（和.automount）使用ccache 進行Kerberized 掛載。當我以互動方式創建 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。先致謝！

[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運行 from ExecStop= 。

  • 選項 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/。這是一個真正的守護進程——一個長期運行的進程——並且將被如此追蹤。它還將處理定期更新。

    -b如果您使用帶有選項（「啟動時分離」）的 k5start並Type=forking相應地將 .service 更改為模式，您還將獲得相同的「延遲直到成功」行為。

（還有第三個選擇，讓gssproxy處理所有票證，但 CentOS 中的 cifs.upcall 還不支援這一點。對於除了掛載檔案系統之外的其他用途，KRB5_CLIENT_KTNAME可以讓程式本身根據需要從keytab 取得票證，但它不起作用在這種情況下。

這些 ccache 檔案的首選位置是什麼？

就我個人而言，我會堅持使用/tmp/krb5cc_*or /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 不會有幫助，因為它不是刪除您的檔案的外部任務，而是服務本身這樣做。

相關內容