cancel
Showing results for 
Search instead for 
Did you mean: 

Re: crontab behaviour

 
Din_1
Frequent Advisor

Re: crontab behaviour

I too had the similar problem in my env. But when i restarted the Cron deamon it worked...
Dennis Handly
Acclaimed Contributor

Re: crontab behaviour

>have already checked above mentioned two points.

Did you do as Hasan suggested, use "crontab -e" and make a minor change?

I suppose this would only matter if you ever had your crontab entry executing for every day.
Yogeeraj_1
Honored Contributor

Re: crontab behaviour

Hi,

I would suggest that you verify your cronlog to determine the first time the job was executed. Other jobs entries that might be running before and that might have been accidentally been modified.

In the meanwhile you may wish to remove this entry or comment it as:

#0 18 * * 6 sh

hope this helps!

kind regards
yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)
Spark_2
Frequent Advisor

Re: crontab behaviour

Hi all,

I did two things yesterday.

1. Typed the same entry again and commented old one, suspecting any blank or spl char issue

2. Restarted cron daemon as it seemed user had done some changes few days ago.

Yesterday it didnt run, as required. Still monitoring it for few days.

Thank you all for you suggestions..

I would update after observing it more...
Matti_Kurkela
Honored Contributor

Re: crontab behaviour

Maybe someone has edited the /var/spool/cron/crontabs/ file directly, without using the "crontab -e" command.

The "crontab -e" uses the editor defined in the EDITOR environment variable, or vi if nothing is defined. After the crontab file has been edited, the "crontab" command signals the cron daemon to make it re-read the crontab file. If someone edits the /var/spool/cron/crontabs/ directly, this signalling step is not done and the cron daemon will still use old settings until the daemon is restarted or the reload is triggered.

MK
MK