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.
UPDATE 1
@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:[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>
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...
UPDATE 2
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.
strace:strace /usr/sbin/aide --check ...