Incrond works, but does not execute the command under CentOS 6.4

Question

I installed incron from the EPEL repository (before you ask: YES, I also tried downloading the source code and compiling the same results locally), and I'm trying to set up a process on my CentOS 6.4 (final) virtual field, which I successfully prototyped my local Ubunto 12.04 machine:

Some information ahead:

• SELinux installed PERMISSIVE
• I added my script and called executables for everyone using NOPASSWD using visudo to get around some permissions problems ...

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

sudo service incrond status checks if incrond is working. root and myusername are added to /etc/incron.allow , /etc/incron.deny empty.

My incrustat for root:

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

Events in /path/to/dropfolder/ produce exact NOTHING. No logs are generated, no messages, no action occurs in the files in the folder.

So, I researched: it has been suggested that cron works in a minimal environment and that you may need to run .bashrc and / or export PATH at the beginning of the cron command to execute complex commands / scripts.

Note. I can’t find the documentation confirming that incron also works in a minimal environment, but since my google-fu (and bing-fu!) Did not incron any useful results directly related to incron I understood WTH, I will try this!

Edit: The documentation indicates that incron starts from system tables or that root accepts env from its host environment, so only incron run by non-root users should require any kind of env or PATH frivolous

So, & hellip; 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 & hellip; tried && instead ; = boneless. If you can come up with the option above, I probably tried it & hellip;

So, let's try a little restorecond -R /usr/sbin/incrond /etc/incron* ! Yes, there are no changes. service incrond stop , followed by service incrond start , and then service incrond restart & hellip; nope, nope and nope.

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

Nothing.

I don’t even get anything from /tmp/ IN_ALL_EVENTS echo boo>>/home/myusername/boofile.txt , so my inability to even execute env>>envfile.txt to check if incron in a sparse & hellip; (see note above)

And still: service incrond status gives incrond (pid xxxx) is running...

What am I missing? This should be big and obvious, and I hope someone can make me feel like an idiot in short order!

further consideration of /var/log/cron gives the following results: 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 is executable.

so incrond is really trying to do SOMETHING, but I get nothing ... even a simple echo > /dev/pts/0 produces nada results.

• thanks for fixing my crap formatting job

Answer 1

Ok, here is the answer:

Despite all the documentation, I can say that this is the opposite, incrond on CentOS 6.4 runs in a sparse environment and behaves like a cron . this does not apply to Ubuntu, where incron inherits its environment from root for system tables and root tables, and only user tables work in a sparse environment. This, of course, means that if you call the script (i), the script must build its environment, and every thing must have a full path. EVERYTHING . (well, except for the built-in shells: p)

numerous google searches, as well as Bing and Qaru and Server Fault all told me that cron works this way, but they all also seemed to indicate that incron works as described in the documentation it does under Ubuntu ...

Bottom line, now it works, yay!

• I guess this just shows: when in doubt determine the environment and use the full paths ... uh, actually, just do it all the time and save yourself a headache.

(this does not concern my problem with applying SELinux security policy for incron , but I will worry about it later, in another post ...)