Skip to main content
added 990 characters in body; edited tags
Source Link
dafydd
  • 1.5k
  • 5
  • 18
  • 32

@rudimeier@rudimeier suggested using strace to track my file descriptors. That failed, but in interesting ways.

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.

@rudimeier suggested using strace to track my file descriptors. That failed, but in interesting ways.

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

@rudimeier suggested using strace to track my file descriptors. That failed, but in interesting ways.

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.

Follow up experiments.
Source Link
dafydd
  • 1.5k
  • 5
  • 18
  • 32

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

Fixed a wrong word.
Source Link
dafydd
  • 1.5k
  • 5
  • 18
  • 32

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

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 LANG=/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.

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.

Source Link
dafydd
  • 1.5k
  • 5
  • 18
  • 32
Loading