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/aideSHELL=/bin/bash48 22 * * * root /usr/sbin/aide --check >/var/log/dailys/aide-$( date +\%Y\%m\%d ).out 2>&1I 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/aideSHELL=/bin/bash21 13 * * * root strace /usr/sbin/aide --check >/var/log/dailys/aide-$( date +\%Y\%m\%d ).out 2>/var/log/dailys/strace.outThe 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 aideroot 27794 27792 <stuff> /bin/bash -c /usr/sbin/aide --check > /var/log/dailys/aide-$( date +%Y%m%d ).out 2>&1root 27795 27794 <stuff> /usr/sbin/aide --check# ls -l /proc/27794/fdlr-x------. <stuff> 0 -> pipe:[14123645]l-wx------. <stuff> 1 -> pipe:[14123646]l-wx------. <stuff> 2 -> pipe:[14123646]# ls -l /proc/27795/fdlr-x------. <stuff> 0 -> pipe:[14123645]lrwx------. <stuff> 1 -> /nulllrwx------. <stuff> 2 -> /null<stuff># ls -l /proc/27792/fdlrwx------. <stuff> 0 -> /dev/nulllrwx------. <stuff> 1 -> /dev/nulllrwx------. <stuff> 2 -> /dev/nulllr-x------. <stuff> 5 -> anon_inode:inotifylr-x------. <stuff> 6 -> pipe:[14123646]# ps -ef | grep 27792root 27792  3850 <stuff> CROND<stuff># ps -ef | grep 3850root  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 2This 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/aideSHELL=/bin/bash41 14 * * * root /usr/sbin/aide --check | tee /var/log/dailys/aide-$( date +%\Y\%m\%d ).out 1>/dev/null 2>&1And 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.
Still no output from redirection in a cron job
bash;cron;io redirection;aide