☰

Systemd: por que os arquivos em/tmp ou/run são excluídos após alguns segundos?

tag-icon • tag-icon linux centos7 systemd systemd-service
Systemd: por que os arquivos em/tmp ou/run são excluídos após alguns segundos?

Estou usando o systemd para montar um compartilhamento do Windows usando Kerberos. Para fazer isso funcionar, primeiro executo kinitum arquivo .service para criar um cache de credenciais Kerberos (ccache). O .service é executado como root, pois o ccache precisa pertencer ao root ( journalctl -xeme ajudou com isso), pois o mount.cifs requer root. O .mount (e o .automount) usam o ccache para fazer a montagem Kerberizada. Quando crio o ccache interativamente, isso funciona bem. No entanto, quando executado dentro da unidade de serviço, o ccache é rapidamente excluído e a montagem (automática) falha. Não importa se eu salvo em /tmp ou /run/user/0.

  1. Por que os arquivos em/tmp ou/run são excluídos automaticamente?
  2. Qual é o local preferido para esses arquivos ccache? É PrivateTmpuma solução melhor? Em caso afirmativo, como me refiro a esse diretório tmp privado dentro do arquivo de serviço? Eu tentei %T/krb5cc_root.ccache, mas o systemctl gera um erro. É JoinsNamespaceOfa maneira de usar o mesmo tmp privado no arquivo de montagem?

Estou usando o systemd 219 no Linux CentOS 7. Abaixo está minha unidade .service. Desde já, obrigado!

[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

Responder1

Por que os arquivos em/tmp ou/run são excluídos automaticamente?

Porque o seu serviçoinicia um "daemon" que sai imediatamente, marcando assim o serviço como "parado" segundos após o início, fazendo com que kdestroyfrom ExecStop= seja executado.

  • Opção 2: altere a definição .service para informar ao systemd que isso édeveria seruma tarefa que sai imediatamente, usando estas opções:

    [Service]
Type=oneshot
RemainAfterExit=yes

    O Type=oneshotmodo também é útil porque fará com que o systemd espere que ExecStart= seja totalmente concluído antes que o serviço seja marcado como "ativo", evitando a necessidade de adicionar o arbitrário sleep 2. Em outras palavras, permite que você use After=kinit.servicesem se preocupar que outras coisas comecem “muito cedo”.

  • Opção 1: Substitua kinit pelo k5startdaemon dehttps://www.eyrie.org/~eagle/software/kstart/. Este é um daemon real – um processo de longa execução – e será rastreado como tal. Ele também cuidará da renovação periódica.

    Se você usar k5start com a -bopção ("Desanexar na inicialização") e alterar o .service para Type=forkingo modo correspondente, você também obterá o mesmo comportamento de "atraso até o sucesso".

(Há também uma terceira opção de deixar gssproxylidar com todos os tickets, mas cifs.upcall no CentOS ainda não suporta isso. Para outros usos além da montagem de sistemas de arquivos, KRB5_CLIENT_KTNAMEpermitiria que o próprio programa adquirisse tickets do keytab conforme necessário, mas não funcionará nesse caso.)

Qual é o local preferido para esses arquivos ccache?

Pessoalmente, eu ficaria com /tmp/krb5cc_*or /run/user/<uid>/krb5cc_*. (Esses são os únicos locais que o NFS rpc.gssd verifica.)

Para SMB, cifs.upcall examinará o local padrão do sistema para o UID que está executando a montagem (ou seja, o que estiver definido em krb5.conf), que geralmente ocorre /tmp/krb5cc_0quando o systemd está fazendo isso. (Embora cifs.upcall possa extrair KRB5CCNAME do ambiente do invocador, isso não ajuda com montagens automáticas envolvidas, já que cifs.upcall veria apenas systemd ou autofsd como o chamador.)

PrivateTmp é uma solução melhor?

PrivateTmp não vai ajudar, porque não é uma tarefa externa que está excluindo seu arquivo, é o próprio serviço que está fazendo isso.

informação relacionada