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
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
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

# 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

# ps -ef | grep 3850
root  3850     1 <stuff> crond

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
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.

  • 1
    I guess there is an error because different cron environment, no terminal etc. I would try to run in with strace: strace /usr/sbin/aide --check ...
    – rudimeier
    Aug 3, 2017 at 18:47
  • FYI - On CentOS 6.9 (32-bit) it works as you originally attempted. Aide v0.14 from the CentOS base repo.
    – Deathgrip
    Aug 3, 2017 at 22:06
  • @Deathgrip - That's weird. My tests are on 64-bit Oracle Linux 6.9 with SELinux enforcing, and aide 0.14. (sigh I love computers...)
    – dafydd
    Aug 3, 2017 at 22:29

1 Answer 1


You are using selinux. If you "setenforce 0" and then let cron run, you will get the output you expect. At the root shell, your selinux context is:


But when running from Cron, your selinux context starts as:


| to another command works, so you could have also done | cat > file

aide then does its own thing with selinux which causes redirection to fail.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .