Unix Cron : Can we set cron jobs to run at the same time

Question

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

In the morning, I found there were no results of the script. Checking the /var/cron/log, I found 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/somescriptA.sh> /dev/null 2>&1 #Test

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

Solution 1

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.

Solution 2

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).

Solution 3

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).

Solution 4

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.

Solution 5

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

View more solutions

Comments

[Admin]

Does the root user script reboot the machine, prematurely ending the job?

[Admin]

Not all cron providers are created equally. Which cron package are you using?

[Admin]

using Solaris 10 platform.

[Admin]

yes, I used crontab -e to edit them. here is what they look like. root$ crontab -l 05 00 10 * * /opt/sdf/sbin/somescriptA.sh> /dev/null 2>&1 #Test userA$crontab -l 05 00 10 * * /opt/sdf/sbin/somescriptB.sh> /dev/null 2>&1 #Test

[Admin]

there was no entry in /var/cron/log for my script run as e.g user A

[Milner]

If a user isn't permitted to run cron, then they should not be permitted to edit and maintain a crontab.

[Daniel Steigerwald]

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.

[arathunku]

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.

[arathunku]

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.

[arathunku]

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.

[Axel]

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.

[deathly809]

accurate and correct - +1

[Cian]

/etc/cron.daily /etc/cron.hourly don't all execute at the same time. They execute in asciibetical order, one after another.

[M B Parvez Rony]

Though it is too old question, but I have to ask one thing. Let, I have a CRON action at every 30 second. But one CRON takes about 1 minute to finish. Is there any problem with this? Can same CRON task can runs twice or more times parallelly?