O que está me impedindo de canalizar de um arquivo '600' para o email dentro do launchd?

Question

No OSX 10.6, estou executando o logcheck.sh via. launchd usando este plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key><string>org.logcheck</string>
<key>Program</key><string>/opt/local/bin/logcheck.sh</string>
<key>StartInterval</key><integer>600</integer>
</dict>
</plist>

logcheck é executado no intervalo especificado, mas não me envia e-mails usando o comando abaixo:

cat $TMPDIR/checkreport.$$ | $MAIL -s "$HOSTNAME $DATE system check" $SYSADMIN

onde

$TMPDIR=/opt/local/var/tmp
$MAIL=/usr/bin/mail
$SYSADMIN=myuser

no entanto, se eu cortá-lo, mudo o comando para:

cat $TMPDIR/checkreport.$$ > /Users/myuser/report
cat /Users/myuser/report | $MAIL -s "$HOSTNAME $DATE system check" $SYSADMIN

então eu recebo o e-mail.

Verificando a permissão no tmp com $ls -l /opt/local/var recebo

drwx------  20 root  admin  680 Jul 12 13:29 tmp/

Se eu executar sudo /opt/local/bin/logcheck.sh , o primeiro comando funciona.

Se eu usar /opt/local/bin/logcheck.sh no crontab do root, o primeiro comando funciona.

Se eu lançar o script echo "$(whoami)" > /Users/myuser/launchduser , vejo que está sendo executado pelo root.

Por que não estou recebendo e-mails com o primeiro comando no launchd? É um problema de permissões com o pipe a ser enviado?

    

Answer 1

Eu recentemente trabalhei nisso e encontrei entradas no log do sistema ( /var/log/system.log ) que mostram erros relacionados a esse problema, como:

Nov  1 08:52:14 my-computer com.apple.launchd[1] (org.postfix.master[22591]): Stray process with PGID equal to this dead job: PID 22592 PPID 1 pickup
Nov  1 08:52:14 my-computer com.apple.launchd[1] (org.postfix.master[22591]): Stray process with PGID equal to this dead job: PID 22594 PPID 1 cleanup

Descobri que meu script de logcheck e o e-mail esperado funcionavam perfeitamente quando executados na linha de comando, e que o script logcheck executava bem suas funções quando iniciado usando launchd através de um script LaunchDaemon.

No entanto, o email nunca chegou ao usar launchd . Os erros acima, e muitos outros, envolvendo postfix e sendmail, indicam que os processos do sendmail filho estavam sendo finalizados pelo launchd (como parte de suas rotinas de coleta de lixo?) Antes de terem tempo para serem concluídos.

Eu adicionei a seguinte chave ao meu plist:

<key>AbandonProcessGroup</key>
</true>

e o e-mail começou a fluir ao usar o launchd. Infelizmente, ainda recebo as mensagens de processo / tarefa perdidas no meu system.log, que atualmente estou trabalhando para eliminar. Adicionei uma linha sleep 120 ao meu script logcheck.sh , o que reduziu, mas não eliminou, essas mensagens. Eu poderia aumentar o tempo do comando sleep em logcheck.sh , para que o script persista por mais tempo, mas eu não gosto desse 'hack' em particular e quero encontrar uma solução mais elegante. Eu acredito que o launchd não inicia sua coleta de lixo até que o processo logcheck.sh seja concluído ....

Vou tentar alongar explicitamente a chave TimeOut na lista de controle e ver se isso funciona melhor.

    

Answer 2

Por curiosidade, quando o seu script envia com sucesso os relatórios, os corpos estão vazios?

Eu só peço porque sua solução sempre gerará um email se / Users / myuser / report for gravável, mesmo que você não consiga ler $ TMPDIR / checkreport. $$. O corpo estará vazio, mas você receberá o e-mail com a linha de assunto apropriada.

O que acontece quando você faz algo assim?

if [ -r $TMPDIR/checkreport.$$ ]; then
    <$TMPDIR/checkreport.$$ $MAIL -s "$HOSTNAME $DATE system check" $SYSADMIN
else
    echo "Unable to read file: $TMPDIR/checkreport.$$" | $MAIL -s "ERROR: $HOSTNAME $DATE system check" $SYSADMIN
fi

Isso só tentará enviar o email do relatório se $ TMPDIR / checkreport. $$ existir e for legível, caso contrário você deverá receber um email informando o nome do arquivo explícito que ele não pôde ler e você poderá investigar a partir daí. / p>

Como nota lateral, acabei de remover o comando cat porque ele gera um processo desnecessário. O resultado final será o mesmo, mas é um pouco mais limpo apenas redirecionar o conteúdo do arquivo diretamente para o seu comando de e-mail, em vez de enviar a saída do gato para ele.

    

Answer 3

Sua saída ls mostra claramente que seu usuário não pode inserir nem ler o $ TMPDIR , para que ele não possa ler o arquivo, mesmo que seja legível para ele.

Como já foi mencionado, seu segundo hack simplesmente cria um arquivo vazio, mesmo que não possa entrar no diretório temp ... então o e-mail chega, mas vazio.

Você deve :

• adicione seu usuário ao grupo de administradores
• crie o $ TMPDIR g + rXs

para ter o arquivo disponível para o usuário.