Theodore Jones schrieb:
Here is the mail message I continue to recieve on the hour:
Date: Wed, 29 Nov 2000 17:01:01 -0700
From: Cron Daemon <root@xxxxxxxxxxxxxxxxx>
To: root@xxxxxxxxxxxxxxxxx
Subject: Cron <root@www> /home/sites/site2/database/sentinel.pl
/bin/sh: /home/sites/site2/database/sentinel.pl: No such file or directory
pretty clear, isn`t it ? the file does not exist, or the path is wrong.
I'm pretty sure the cronjob is installed as root also. Here's what I
get when doing a "crontab -l":
yes, it is, as it is in root`s crontab.
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.7142 installed on Wed Nov 29 16:45:44 2000)
strange, i don`t have this entry. i interpret it - see "man cron" for
this - that you should not edit the file directly with a text editor,
but open it for editing with crontab -e, like you did.
I had allready tried a "crontab -e" as root, but the first line that it
outputs in edit mode tended to stop me... :
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (something.crontab installed on Fri May 19 13:13:41 2000)
that`s normal, as it is simply a comment in the crontab, which is a
simple text file with some special behaviour (it does not behave special
in any sense, but it is treated in a special way by the crontab
command).
the only point that seems a bit strange is "edit the master"; i don`t
know how to understand this. maybe cobalt specific stuff, but i don`t
think so.
anyway, i edit my crontabs regularily in this way (all but /etc/crontab,
that i edit directly) without any problems (raq3i).
the first thing you should do now is to check the path to sentinel.pl
("whereis sentinel.pl" or "locate sentinel.pl"); you might add the
correct entry to /etc/crontab if you don`t want to bother around with
"crontab -e", which calls vi by default (exactly : the program specified
by your EDITOR environment variable, that you of course can change to
e.g. to pico (don`t forget the -w !!)).
btw: the mail is not bounced, it`s the way that cron tells the user
about errors (sort of STDOUT). that`s the only (simple and effective)
way, as the user might not be logged in when cron executes something for
him.
again, "man cron" is your friend.
cu