Thanks to Chris and Ram,
Both Chris and Ram suggested to kill the cron process with HUP option.
Chris Ruhnke's response is below:
>Try sending a HUP signal to the cron daemon. It doesn't know that you have
>modified the cron file.
># ps -eo pid,command | grep cron
># kill -HUP <pid for cron>
>In the future you should use "cron -e" to edit the file. Then the daemon
>will know there has been an update.
Ryan McConigley, are you there? Ram Rao gave a hint about a patch available.
Could solve your problem as well.
>V4.0F has a bug in the crontab command, in that it does not cause
>an immediate change cron behavior. The workaround is to do a
>kill -HUP on the cron process, which forces it to reread its database.
>This problems exists in V4.0D, E, F and V5.0. I think it has been fixed
>in V4.0G, V5.0A, V5.1. For the releases in which it is broken, the
>jumbo patch kit will fix the breakage.
Thanks admins.
JC Faul
Systems Administrator
Mobile Telecommunications LTD
#######
Original question
After I edited a crontab file (crontab -l > new_file) and submitted the
file
to the cron (crontab new_file), I noticed that some processes
that was removed from new_file still executes as if cron reads the old
file.
crontab -l has confirmed that I've submitted new_file to cron.
/var/spool/cron/crontabs shows the new_file.
Received on Wed May 16 2001 - 14:17:27 NZST