Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

I created an entry in crontab to execute a job at midnight as e.g user A.

In the morning, I find there were no result of the script, checking the /var/cron/log, I find that during that hour (same time) only a script user root was executed.

Questions: a) Can we set multiple jobs in cron to execute the same time. b) If no? Does this mean user root cron has precedence over any other user to execute the cron job?

here is what they look like. root$ crontab -l 05 00 10 * * /opt/sdf/sbin/> /dev/null 2>&1 #Test

userA$crontab -l 05 00 10 * * /opt/sdf/sbin/> /dev/null 2>&1 #Test

share|improve this question
Does the root user script reboot the machine, prematurely ending the job? – Jacob Schoen Jun 10 '09 at 14:10
Not all cron providers are created equally. Which cron package are you using? – Dan Carley Jun 10 '09 at 14:22
using Solaris 10 platform. – Syed Jun 11 '09 at 9:55
up vote 2 down vote accepted

Cron can run many scripts at the same time. In fact, in Debian there are entire directories of cron scripts (ie. /etc/cron.daily /etc/cron.hourly) that execute at the same time.

If the script executes properly at a different time, why don't you try changing the time of the root cron job to determine whether the problem is with the actual timing, or a conflict between the scripts.

I also agree with turning off the redirect to /dev/null until you have everything working correctly.

share|improve this answer
Or, if you don't have the machine setup such that cron can send mail to a useful place when it sees output from a job, change the redirects to point to files instead like ">> /root/temp.cron.job.log 2>&1" or such. Just make sure you turn it off when you are done (or add the file to your logrotation setup) otherwise the file will grow until it fills the partition. – David Spillett Jun 10 '09 at 15:46
/etc/cron.daily /etc/cron.hourly don't all execute at the same time. They execute in asciibetical order, one after another. – Cian Jul 5 '09 at 13:31

I would take the /dev/null redirect off of the job and have cron email you the output of the file. It could be the script has a problem (maybe assuming an environment variable that doesn't exist when running through cron).

share|improve this answer
there is no entry in /var/cron/log for userA at all, seems like it didnt execute at all at that time, if I change the timing to something different it will execute with no issue. – Syed Jun 10 '09 at 13:58

That crontab you posted is set up to only run at 00:05 the 10th every month, is this what you wanted?

Please check that your script in /opt has executeable permissions, and that it's prorperly calling up sh. You can try this by simply running the script in the console (by using its full path, dont put "sh" in front of the command)

Try to check the directory /var/spool/cron/ for your username, the cron file should be there (somewhere - I don't have access to a system right now).

share|improve this answer
accurate and correct - +1 – GNUix Jun 11 '09 at 6:39

Cron jobs can run at the same time. Your problem is something else. .. or .. the script is running as root. Maybe what you're trying to run has its own method of preventing more than one instance.

share|improve this answer
there was no entry in /var/cron/log for my script run as e.g user A – ssharizal Jun 10 '09 at 13:38

I would suspect that there is some interaction between the two scripts like a lock file or an open file.

share|improve this answer
thanks Dennis, the root script is doing some cleaup tidy work while the other is dumping data although the folder are not the same though, but the base folder is the same /tmp, this would be something that I should look into. – Syed Jun 10 '09 at 14:07

I have never had a problem with multiple cron jobs running at the same time. Just tested on my Slackware system, works fine, but it may vary according to distro.

That said, it's usually a good idea to stagger the minutes of your crontab entries anyway so they're not all running at the same time (just to prevent unnecessary load on the system and potential interaction problems).

I double Milner's suggestion of checking the output of the cron jobs rather than redirect it to null. At least until you debug why the jobs themselves aren't working.

share|improve this answer

Users should be able to run cron jobs simultaneously with no problem. Have you confirmed that user A is permitted to use cron (try checking /etc/cron.allow and /etc/cron.deny).

share|improve this answer
If a user isn't permitted to run cron, then they should not be permitted to edit and maintain a crontab. – Milner Jun 10 '09 at 13:53
You can also check whether the cron job runs successfully by setting it to execute "in 5 minutes" and observing your machine for evidence of success. – Mike Mazur Jun 10 '09 at 13:53
hi ktower, yes, the user is permitted to execute the cron. I fail to mentioned that the script execute nicely when I change the time for user A script in its cron. – Syed Jun 10 '09 at 13:57

Did you use crontab -e to edit the crontab? It may be that crontab has not noticed your change, you must use this command to edit/install new crontabs.

share|improve this answer
yes, I used crontab -e to edit them. here is what they look like. root$ crontab -l 05 00 10 * * /opt/sdf/sbin/> /dev/null 2>&1 #Test userA$crontab -l 05 00 10 * * /opt/sdf/sbin/> /dev/null 2>&1 #Test – ssharizal Jun 10 '09 at 13:36

I have never heard of cron silently disabling cron jobs because others were scheduled for the same time. That should work, so I guess your problem is elsewhere.

BTW, this sounds like something for

share|improve this answer

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.