Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Here's what I have in my crontab:

*  *  *  *  * /bin/bash /home/user_name/

Here's what's in the file:


cd /var/www/sites/site1
sudo svn update *

cd /var/www/sites/site2
sudo svn update *

The script is set to +x.

Any ideas on why it won't run in cron? It runs fine when I run it manually.

share|improve this question
Does the cron log give you any information at all? – Frands Hansen May 26 '11 at 13:36
The only thing in there is: TIMESTAMP server CROND[4621]: (root) CMD (/bin/bash /home/user_name/ ) a bunch of times. – doremi May 26 '11 at 13:38
Do you have other entries in your crontab, do those work? – Lucky Luke May 26 '11 at 15:48
up vote 3 down vote accepted

Any reason you have /bin/bash in cron invocation? The #!/bin/bash in the script itself should do the same thing. Also make sure that the script is configured to executable (chmod +x/chmod 755). Verify that you want to run the program under your account, otherwise specify the user with the sudo -u "USERNAME" command. Also check and make sure that your account (or the account you want it to run under) has the NOPASSWD option added in /etc/sudoers (more info here:

share|improve this answer
I added sudo -u my_user to the script and I think it's working now. However, now when I try to run the script manually, I get a permission denied. Why would that be? I'm logged in as the same user. – doremi May 26 '11 at 14:16
When you run crontab by editing it with crontab -e it should always run as your user (though I could be wrong on that one, I was trying to research what user cron jobs run as). In that case, you shouldn't need to specify the user. Just make sure your user account has NOPASSWD added in /etc/sudoers. If you want to test, you could always add an to a junk file with the sudo command... something like "sudo echo date >/tmp/scriptlastrun" just to see if its working how you expect. – Matthew May 26 '11 at 14:35

You might also need to remove "requiretty" option from /etc/sudoers file, if your distribution has it there by default.

share|improve this answer
I know this to be true on Redhat, CentOS, Fedora. – steve.lippert May 26 '11 at 15:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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