why one specific cron job running more time in Linux OS

[jeesshnasree]

Hi Team,

it s a General question :

Daily(everyday)  10(n means numeric number)  cron jobs are runnining smoothly ontime  . But oneday one specific job taking long time

. could you please provide cause of the jobs slow reason . 

Fnally its not hypothetical question and there is no logs  and how to avoid this type issue .

what is the troubleshoot this type of issue and avoid in future . if anyone knows the solution then kindly share the necessary require steps . 

[Scott]

@jeesshnasree,

Cron is a job scheduler, which means that your job probably kicks off at the correct time, but itself takes a long time.  For example, if you  have a job that starts at noon, but takes four hours to run, then the job will complete at four in the afternoon.  It could also be that jobs with a higher priority superceeded this job for processor time or that the system, generally, was busy which meant that this job recieved less processor time or disk I/O it relies on took longer, etc. than it had in the past.

If you run the job manually, you should get a sense of how long it will take.  If you wrap it with the time command or date; JOB; date, you'll see how long it takes to complete.

-STM

[jeesshnasree]

Hi @Scott,

thanks for your valuable reply.

(1.)Actually 10 cron jobs running everyday within hour ,but few days back one job took long time means more than 2 hours.. how to check cron job log in background with non root user under /tmp location path with specific date and time format. Any command verification or check with non root command for jobs details.

(2)If possible , could you please share one sample script . Script run under root but background log under non root for verification “/tmp” path with specific date and time log . 

3. If not possible for (2) script  otherwise ignore my comments. Finally thanks @Scott for your valuable information.👍👍

[Scott]

@jeesshnasree, unfortunately, unless you've already set yourself up to do so, troubleshooting things that happen in the past are difficult.  And by "set yourself up to do so" I mean that you've included diagnostic messages, logging, or other auditing methodologies that always capture data, so that in the event of a problem you can look back at that data and try to determine what was different about this anomolous run.

You can use tools like logger, which will use the syslog system, or you could put echos and redirects in your cron script to put diagnostic or debug information somewhere like /tmp.  cron will automatically redirect an standard out and standard error messages to the root user via mail.  You can check this, logged in as root, with the mail command.

Unfortunately, I don't quite understand what you're asking me to provide you.

-STM

[jeesshnasree]

Hi @Scott,

 thanks for your valuable information. I will check with root ID user.