Every answer to the question of why a cron job results in a zero-length file comes down to using classic output redirection. That still doesn't help, here.
# 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
I will only get a zero-length file. If I pull that command out and run it at the bash prompt (dropping the backslashes), I get a filled file.
@rudimeier suggested using strace to track my file descriptors. That failed, but in interesting ways.
# 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
The job ran, aide ran without output, and strace showed me that file descriptor assignments started with 3. The only reference to
/var/log/dailys was when aide checked the permissions and contents of the files in the directory. So, I tried something else: let's kick off the cron job, and look at the various process file descriptors. I wound up having to be a little fast to get this all done, and having this trick in my pocket gave me more clues for follow up.
# 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: l-wx------. <stuff> 1 -> pipe: l-wx------. <stuff> 2 -> pipe: # ls -l /proc/27795/fd lr-x------. <stuff> 0 -> pipe: 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: # ps -ef | grep 27792 root 27792 3850 <stuff> CROND <stuff> # ps -ef | grep 3850 root 3850 1 <stuff> crond <stuff>
So, the STDOUT and STDERR of of the aide process is getting directed to
/null, the parent
bash shell is writing to its parent. That top process,
CROND, has no writable FDs. And, I don't see which process might have created
/var/log/dailys/aide-20170803.out as an empty file to begin with. Curiouser and curiouser...
This all started with DISA STIG RHEL-07-020030, which has
/usr/sbin/aide --check 2>&1 | /bin/mail ... I'd already tested this and know it works. Why piping and not output redirection?
I went back to the pipe-to-mail version and scanned PIDs and FDs. With the bash pipe arrangement,
aide actually populates FD 1 and FD2 through the pipe, instead of back to its parent. So, let's play a little...
# 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
And that works... I have a weak feeling that
aide has code that blocks output redirection aside from through a pipe. I'll write the solution when my 24 hours are up.