☰

Systemd: /tmp 또는 /run의 파일이 몇 초 후에 삭제되는 이유는 무엇입니까?

tag-icon • tag-icon linux centos7 systemd systemd-service
Systemd: /tmp 또는 /run의 파일이 몇 초 후에 삭제되는 이유는 무엇입니까?

Kerberos를 사용하여 Windows 공유를 마운트하기 위해 systemd를 사용하고 있습니다. 이 작업을 수행하려면 먼저 kinit.service 파일을 실행하여 Kerberos 자격 증명 캐시(ccache)를 생성합니다. mount.cifs에는 루트가 필요 하므로 ccache는 루트가 소유해야 하므로 .service는 루트로 실행됩니다( journalctl -xe도움이 되었습니다). .mount(및 .automount)는 ccache를 사용하여 Kerberized 마운트를 수행합니다. ccache를 대화형으로 생성하면 잘 작동합니다. 그러나 서비스 유닛 내부에서 실행하면 ccache가 빠르게 삭제되고 (자동)마운트가 실패합니다. /tmp나 /run/user/0에 저장해도 상관없습니다.

  1. /tmp 또는 /run의 파일이 자동으로 삭제되는 이유는 무엇입니까?
  2. 이러한 ccache 파일의 기본 위치는 무엇입니까? PrivateTmp더 나은 솔루션이 있습니까 ? 그렇다면 서비스 파일 내에서 해당 개인 tmp 디렉토리를 어떻게 참조합니까? 시도했지만 %T/krb5cc_root.ccachesystemctl에서 오류가 발생했습니다. JoinsNamespaceOf마운트 파일에 동일한 private 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의 파일이 자동으로 삭제되는 이유는 무엇입니까?

왜냐하면 당신의 서비스즉시 종료되는 "데몬"을 시작합니다., 따라서 시작 후 몇 초 내에 서비스가 "중지됨"으로 표시되어 kdestroyfrom 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/. 이는 실제 데몬(장기 실행 프로세스)이므로 추적됩니다. 정기적인 갱신도 처리합니다.

    옵션("시작 시 분리") 과 함께 k5start를 사용 -b하고 이에 따라 .service를 Type=forking모드로 변경하면 동일한 "성공할 때까지 지연" 동작이 발생합니다.

(모든 티켓을 처리하도록 허용하는 세 번째 옵션도 있지만 gssproxyCentOS의 cifs.upcall은 아직 이를 지원하지 않습니다. 파일 시스템 마운트 이외의 다른 용도로 KRB5_CLIENT_KTNAME프로그램 자체가 필요에 따라 키탭에서 티켓을 획득하도록 허용하지만 작동하지 않습니다. 이 경우.)

이러한 ccache 파일의 기본 위치는 무엇입니까?

/tmp/krb5cc_*개인적으로 나는 or 을 고수할 것입니다 /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는 도움이 되지 않습니다. 파일을 삭제하는 것은 외부 작업이 아니라 서비스 자체이기 때문입니다.

관련 정보