Todas as respostas para a pergunta de por que um trabalho cron resulta em um arquivo de tamanho zero se resume a usar o redirecionamento de saída clássico. Isso ainda não ajuda aqui.
# cat /etc/cron.d/aide
SHELL=/bin/bash
48 22 * * * root /usr/sbin/aide --check >/var/log/dailys/aide-$( date +\%Y\%m\%d ).out 2>&1
Eu só receberei um arquivo de tamanho zero. Se eu puxar esse comando e executá-lo no prompt do bash (soltando as barras invertidas), recebo um arquivo preenchido.
UPDATE 1
@rudimeier sugeriu o uso de strace para rastrear meus descritores de arquivo. Isso falhou, mas de maneiras interessantes.
# cat /etc/cron.d/aide
SHELL=/bin/bash
21 13 * * * root strace /usr/sbin/aide --check >/var/log/dailys/aide-$( date +\%Y\%m\%d ).out 2>/var/log/dailys/strace.out
A tarefa foi executada, aide foi executada sem saída e strace mostrou-me que as designações do descritor de arquivo começaram com 3. A única referência a /var/log/dailys foi quando aide verificou as permissões e o conteúdo dos arquivos no diretório. Então, eu tentei outra coisa: vamos lançar o cron job, e olhar os vários descritores de arquivos de processos. Acabei tendo que ser um pouco rápido para fazer tudo isso, e ter esse truque no meu bolso me deu mais pistas para o acompanhamento.
# ps -ef | grep aide
root 27794 27792 <stuff> /bin/bash -c /usr/sbin/aide --check > /var/log/dailys/aide-$( date +%Y%m%d ).out 2>&1
root 27795 27794 <stuff> /usr/sbin/aide --check
# ls -l /proc/27794/fd
lr-x------. <stuff> 0 -> pipe:[14123645]
l-wx------. <stuff> 1 -> pipe:[14123646]
l-wx------. <stuff> 2 -> pipe:[14123646]
# ls -l /proc/27795/fd
lr-x------. <stuff> 0 -> pipe:[14123645]
lrwx------. <stuff> 1 -> /null
lrwx------. <stuff> 2 -> /null
<stuff>
# ls -l /proc/27792/fd
lrwx------. <stuff> 0 -> /dev/null
lrwx------. <stuff> 1 -> /dev/null
lrwx------. <stuff> 2 -> /dev/null
lr-x------. <stuff> 5 -> anon_inode:inotify
lr-x------. <stuff> 6 -> pipe:[14123646]
# ps -ef | grep 27792
root 27792 3850 <stuff> CROND
<stuff>
# ps -ef | grep 3850
root 3850 1 <stuff> crond
<stuff>
Assim, o STDOUT e o STDERR do processo de ajuda estão sendo direcionados para /null , o pai bash shell está gravando para seu pai. Esse processo principal, CROND , não possui FDs graváveis. E não vejo qual processo pode ter criado /var/log/dailys/aide-20170803.out como um arquivo vazio para começar. Mais curioso e mais curioso ...
ATUALIZAÇÃO 2
Tudo começou com DISA STIG RHEL-07-020030 , que possui /usr/sbin/aide --check 2>&1 | /bin/mail ... Eu já testei isso e sei que funciona. Por que canalizar e não redirecionar a saída?
Voltei para a versão pipe-mail e digitalizei PIDs e FDs. Com o arranjo de pipe bash, aide realmente preenche FD 1 e FD2 através do pipe, em vez de voltar para seu pai. Então, vamos brincar um pouco ...
# cat /etc/cron.d/aide
SHELL=/bin/bash
41 14 * * * root /usr/sbin/aide --check | tee /var/log/dailys/aide-$( date +%\Y\%m\%d ).out 1>/dev/null 2>&1
E isso funciona ... Eu tenho uma sensação fraca de que aide tem código que bloqueia o redirecionamento de saída além de um pipe. Vou escrever a solução quando minhas 24 horas terminarem.