Hello,

I have a problem that shakes my confidence in Linux's reliability of
handling crontab jobs (What I mean is when I apply the same procedure
on another Unix system, it always work, just not on my Linux box). The
problem is: I want to change the crontab entries. To do that I edit
the file <user>.crontab in the home directory, submit the job using
"crontab <file>". I also check the result using "crontab -l" and could
verify that the output is the same as the file content except for the
header lines which are comments.

For example, the old crontab entry used to be:

0 21 * * 1-5 /home/bmlam/job_A >/dev/null

Then I decided to deactivate job_A and run job_B everyday instead.
After editing the file and submitting it, "crontab -l" gives this
output:

# 0 21 * * 1-5 /home/bmlam/job_A >/dev/null
0 21 * * 1-5 /home/bmlam/job_B >/dev/null
But what happens in reality is, job_A continues to be run by cron and
I could see no trace of job_B being run!

I reckon rebooting the machine would fix it. But then that would put
Linux on the same level as Windows 9x !!!

Or am I missing something Linux specific, after all?

"bonminh lam" <hansmayer1962@hotmail.com> wrote in message
news:3c6b1bcf.0309161242.32f7b97@posting.google.co m

[...]
There must a newline on the last line of the file for it to parse properly.

--
use hotmail com for any email replies


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

On 16 Sep 2003 13:42:57 -0700, bonminh lam <hansmayer1962@hotmail.com> wrote:
Any reason you are not doing it the normal way using 'crontab -e' to edit
your crontab file? When you exit that, it lets cron know to use the
updated file.

--
David Efflandt - All spam ignored http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/

On Wed, 17 Sep 2003 00:11:50 +0000 (UTC),
David Efflandt <efflandt@xnet.com> wrote:



Which is no different from submitting a crontab file using "crontab file".
In fact crontab -e is a later invention and "crontab file" or "crontab
< file" is the original. The later with redirecting standard input is
a bit riscy feature because running crontab without any arguments used
to wipe out the current crontab entries.


Villy

hansmayer1962@hotmail.com (bonminh lam) wrote in message news:<3c6b1bcf.0309161242.32f7b97@posting.google.c om>...

I've never seen crontab fail under Linux, and I've used it quite
often. First thing I'd check is whether /home/bmlam/job_A and
/home/bmlam/job_B are actually different. I'd believe it's more likely
that at some point you copied the wrong file than believe that
crontab isn't working.

As for rebooting, there certainly is no reason to do that. You don't
mention which flavor of Linux you're using, but you can certainly
stop and start cron without rebooting. In Redhat, go to
/etc/rc.d/init.d and type './crond restart'. There are other, more
forceful ways of doing this, but that's probably the nicest way.

I'd really start using 'crontab -e' to edit your crontab files though.
It's safer than installing a new crontab each time. Your way isn't
wrong, it's just not as safe. And 'crontab -e' should work on any
modern Unix system.

Sean.

Sean G Gilley <uem@mycroft.cmhnet.org> wrote:
And I'd recommend exactly the opposite :-)

It depends on your work habits. (Similar to the OP, I use $HOME/.crontab
and edit that, installing it afresh each time with "crontab .crontab")

It's pretty much the same, just wrapped up in fancy stuff. Why do you
think it's safer? I'd suggest it's just different.

What happens if you forget the -e? Ah, feeding a new file to
crontab. Ctrl/D? Ooops there it goes (have to remember to use Ctrl/C
instead) :-/

Chris

news@roaima.freeserve.co.uk wrote in message news:<j2vo31-579.ln1@news.roaima.co.uk>...
Thanks for all the replies so far. I could not check on this thread
earlier since I was on holidays on the wonderful Algarve coast :-)

My job_B is definitely sth different than job_A. Worst, even a reboot
did not fix it. job_A still got executed and job_B dutifully ignored.
I got so tired of it now I did something like this : 'rm - job_A; ln
-s job_B job_A'

This definitely gets job_B executed. It solved my problem for this
time. Hell knows how I am going to do the next time I need to change
the crontab entries again.

btw, I run Redhat 7.2 and the it is multiprocessor system (2 CPU's),
not that this should matter.