LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (http://www.linuxquestions.org/questions/linux-server-73/)
-   -   Cron jobs not running (http://www.linuxquestions.org/questions/linux-server-73/cron-jobs-not-running-780382/)

saldon 01-06-2010 05:09 PM

Cron jobs not running
 
I have a file server that is an NIS client. User home directories are auto-mounted from another server.

Users are not able to run cron jobs. The /var/log/cron logs says:

Jan 6 14:33:01 inclination crond[3217]: (username) ORPHAN (no passwd entry)

I tried adding an entry in /etc/passwd, /etc/group, and /etc/shadow but the test script I have still doesn't seem to run although cron thinks it did. The log entry for these attempts looks like:

Jan 6 15:30:01 inclination crond[4312]: (username) CMD (/home/username/test-script)

Now root does seem to be able to run cron jobs with no problem. My test script works fine from cron when runs as root.

I suspect there's an issue with how I have NIS configured but I can't find any info that helps.

BTW - The test script runs fine from the command line when logged in as myself.

Any help would be appreciated.

slacker_et 01-07-2010 09:54 AM

I ran into that problem a couple of years ago.

At that company all user logins were actually Windows Active Directory logins that got authenticated on the Linux servers via winbind.
And I vaguely recall that we had to either bounce winbind on the Linux servers or had to re-join the Linux servers to the Windows Domain.

Sorry I can't be more specific.

--ET

saldon 01-08-2010 10:01 AM

Thanks for the idea but we're not using Windows for authentication on our Linux servers.

I did find one idea on the Internet that seems to have worked. It said that you need to be sure cron starts after ypbind and autofs. I restarted cron and everything started working. I looked in /etc/rc5.d and it appears cron was already starting after ypbind and autofs but I moved it to darn near last (S99crond) and inserted a sleep 30 in the start portion of the script just in case. I have seen problems where just making the process wait a bit has fixed a problem. Well, made the problem appear to go away, I was never able to find a root cause and I was too busy to spend large amounts of time troubleshooting an issues I could work around.

To give proper credit, here's the URL to the solution I found:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512757


All times are GMT -5. The time now is 10:22 AM.