incrond running but not executing command under CentOS 6.4

Question

I have installed incron from the EPEL repository (before you ask; YES, I also tried downloading the source and compiling locally; same results) and am attempting to set up a process on my CentOS 6.4 (final) virtual box that I have successfully prototyped on my local Ubunto 12.04 machine:

Some information up front:

• SELinux is set PERMISSIVE
• I have added my script(s) and called executables to all with NOPASSWD using visudo to get around some permissions issues...

If I invoke my script from the command line with sudo /path/to/my/script.sh arguments it works like a charm.

sudo service incrond status verifies that incrond is running. root and myusername are added to /etc/incron.allow, /etc/incron.deny is empty.

My incrotab for root is:

/path/to/dropfolder/ IN_CLOSE_WRITE sudo /path/to/my/script.sh $@/$#

Events in /path/to/dropfolder/ result in exactly NOTHING happening. No logs are generated, no messages, no actions occur on the files in the folder.

So I have researched: it was suggested that cron runs in a minimal environment and that to execute complex commands/scripts you may have to execute your .bashrc and/or export your PATH at the beginning of the cron command.

Note: I can find no documentation supporting that incron also runs in a minimal environment, but as my google-fu (and bing-fu!) failed to result in any helpful results related directly to incron I figured WTH, I'll try that!

Edit: Documentation indicates that incron run from system tables or root takes env from its host enviroment, therefore only incron executed by non-root users should require any sort of env or PATH fiddling

So… incrontab for root:

/path/to/dropfolder IN_CLOSE_WRITE . /home/myusername/.bashrc; export PATH=$PATH:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin; sudo /path/to/my/script.sh $@/$#"

No dice… tried && instead of ; = no dice. If you can think of a variation on the above I've probably tried it…

So, lets try a little restorecond -R /usr/sbin/incrond /etc/incron* action! Huh, no change there either. service incrond stop followed by service incrond start and then service incrond restart … nope, nope, and nope.

Drastic measures: yum remove incron and yum install incron, chkconfig incrond on and then for good measure a sudo reboot!

Nothing.

I don't even get anything from /tmp/ IN_ALL_EVENTS echo boo>>/home/myusername/boofile.txt, hence my inability to even do an env>>envfile.txt to check whether incron is running in a sparse environment… (see above note)

And yet: service incrond status yields incrond (pid xxxx) is running...

What am I missing? It has to be big and obvious and I hope someone can make me feel like an idiot in short order!

further examination of /var/log/cron yields results like this: Aug 14 15:05:30 hostname incrond[1584]: (root) CMD (sudo /path/to/DropFolder/script/subfolder/script-Beta-1.sh /home/username/DropFolder/testfile.file) -yes I made sure my script was executable..

so incrond is indeed attempting to do SOMETHING, but I get no output anywhere... even a simple echo > /dev/pts/0 produces nada results.

• thanks for fixing my crap formatting job

Answer 1

Ok, here's the answer:

Despite all documentation I can find declaring it to be the contrary, incrond under CentOS 6.4 runs in a sparse environment and behaves as cron. this is NOT the case under Ubuntu, where incron inherits its environment from root for system tables and root tables and only user tables run in a sparse environment. This of course means that if you're calling a script (I am) the script needs to build it's environment and every thing must have a full path. EVERYTHING. (well, except for shell builtins :p)

numerous Google and and Bing and Stack Overflow and Server Fault searches all told me that cron operates this way, but they all also seemed to indicate that incron operates as described in the documentation, which it DOES under Ubuntu...

Bottom line, it works now, yay!

• I guess this just goes to show: when in doubt define the environment and use full paths... er, actually, just do that all time and save yourself a headache.

(this does not address my problem with applying a SELinux security policy for incron, but I'll worry about that later, in another post...)