0

I am attempting to install a new cron task on a server. I am able to run the process via command line, but cannot run it via cron. This is due to enviroment variables for PATH and PYTHONPATH not being set correctly when the task is run via cron. (I am actually having this trouble with all cron jobs on the server, but am focusing on one process in this question for simplicity's sake.)

Here is the cron entry for the process:

### procmon NLite ### */2 * * * * . ~/.bashrc; cd /var/networkip/nlite/proc_mon; . bashrc; cd bin; ./proc_mon.py > /dev/null 2>&1

Now, bashrc in the proc_mon directory contains:

BASEDIR=$PWD
KODIAK_ROOT=$BASEDIR/
BASEPATH=$KODIAK_ROOT

pathadd PYTHONPATH ${BASEDIR}/lib

So, when the crontask is run - PYTHONPATH should be reset, but this is not happening.

There are several other older servers successfully running these procs via cron.
Solutions attempted thus far:

  • compared all bashrc or bash_profiles from a successfully running the cron task to the server failing to run crons
  • logged environ variables to confirm this is the issue

Solutions I am not interested in:

  • a cron task to set enviromental variables. There are several procs that need to run via cron and all have different PATH and PYTHONPATH variables relative to that specific script. Doing this could get very messy and is just not a good long term solution as I install the same procs and crons on future servers.

Further info:

  • Linux distro for server failing cron: CentOS release 6.8
  • Linux distro for server with cron success: Red Hat Enterprise Linux Server release 5.2 (Tikanga)

Since the crons is able to work on other servers, there must be a reasonable solution to the problem.

  • Who defines pathadd? Are you depending on bash-isms? cron uses /bin/sh by default I believe, so you might have to at least set SHELL to /bin/bash in the crontab - man 5 crontab. – NickD Feb 28 '17 at 17:16
  • Hm, I'm actually not sure where pathadd is defined. I assumed it was a bashism. If I manually cd into the directory and . bashrc, then echo environ variables, everything works fine. For good measure, I tried changing pathadd to export and still no go for crontasks. – remy Feb 28 '17 at 19:08
  • I tried setting SHELL to /bin/bash in cron, no luck with that either. – remy Feb 28 '17 at 19:09
  • UPDATE: the environ variable are actually NOT the problem. Adding set +o posix to the start of a cron tasks fixes the issue! I still need a more global solution (disabling POSIX for cron?), but a step in the right direction... – remy Mar 1 '17 at 18:10
0

How about changing your command line/cronjob:

bash -c "PYTHONPATH=/var/networkip/nlite/proc_mon/lib:$PYTHONPATH python /var/networkip/nlite/proc_mon/proc_mon.py > /dev/null 2>&1"

Between RH5.2 and RH6.8 (to say nothing of CentOS), there are quite a lot of differences (which I wish I had a source for right now), including I think a change to the cron daemon (from cron to cronie, I think).

Regardless, there are some other things you may want to check into:

  • check if seLinux is part of the picture (grep for your path in /var/log/audit/audit.log if you have such a file, check for AVC)
  • call a bash script from cron, and set up your environment in that script (rather than having a long cron cli) - you can use /etc/cron.d for this.
  • try running your script with a clean env: env -i PYTHONPATH=/var/networkip/nlite/proc_mon/lib:$PYTHONPATH python /var/networkip/nlite/proc_mon/proc_mon.py > /dev/null 2>&1

You say this is happening for 'all cron jobs', so I would check seLinux first. Leave it enabled/enforcing, but use something like audit2allow to fix your specific issues.

May also be worth removing the redirect of output to /dev/null so you can see what the actual issue might be.

  • I directed the output to a log file - what I posted is the original cron. The actual issue is definitely environment variables. I added prints into the proc that log $PATH and $PYTHONPATH and both differ from what they are when the proc is run manually via command line. – remy Feb 28 '17 at 20:32
  • Understood - the thing is, that sounds like it all relates to this one specific example, where you had mentionned the issue impacts a whole bunch of other things. One thing that just occured to me, though: is the cronjob running as the same user as you are using to manually run the command? Or is it running as root? It may be this one issue can be sorted by using the user-specific crontab, in order to have the right env – iwaseatenbyagrue Mar 1 '17 at 9:33
  • it is running as the same user – remy Mar 1 '17 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.