The other version of Unix was Interactive (yes, there are still a couple
of those around). The location of the crontab file is not an issue
because the job was loaded in via the crontab command and shows as being
present in a crontab -l.
: # ps -efa | grep cron <== is the daemon running?
Yes, the daemon is running. So are most of the cron jobs.
: Also, have you rebooted?
Yes, the system has been rebooted various times.
You might also try to turn on cron's logging and see then if cron really
picks up the jobs that look like skipped. Maybe jobs' return codes and
execution times (if any) reported in cron's log will give some food for
| Youri N. Podchosov (ynp) * Davidsohn & Son, Inc. NYC * 718-234-4140 |
Lots of good suggestions. My turn. See item 3 for the problem.
1. Is cron running? Does it look like this? (uid=root, started by init)
root 165 1 0 Sep 18 ? 0:14 /etc/cron
2. Is the script correct? Run (e.g. for root):
crontab -l -u root > filename # save current crontab as filename
crontab -u root filename # reload cron script
crontab will complain bitterly if there are any errors in
the script. I've had it complain about blank lines at the end.
Repeat for other users of cron.
3. Do you have the files in /usr/lib/cron mangled?
(This would be my guess is the problem)
See the man pages for the logic details.
If you have an at.allow file, you *MUST* list every user of cron.
4. Does your migrated script have a problem with the path?
The stock SCO cron only looks in /usr/bin and /bin. If you
don't hard code the full path name of your executables in the
scripts called by cron, you must include a statement like:
near the beginning of your shell scripts.
5. If you decide to run SUID or GUID shell from cron, insure
that the script actually runs with the correct owner by using
/bin/su username -c "/u/hack/bin/shell_script"
in your cron script.
6. If your shell script creates megaboat monster files, you may
need to include a ulimit statement in your script.
45 23 * * * ulimit 5000; /usr/lib/uucp/uudemon.clean > /dev/null
7. If you need an excuse to buy a bigger hard disk, turn on
logging for cron by editing /etc/default/cron
CRONLOG=NO to CRONLOG=YES
You will need to kill and restart cron. Kill -9 PID works fine
for stopping cron. However to restart, use:
/usr/bin/sd cron start
You can also add the following to /etc/inittab
cron:b:once:/etc/init.d/S75cron start > /dev/console 2>&1
and restart with:
8. Make sure you date and time are correct (or at least close).
If you need to change it, use:
# Jeff Liebermann Liebermann Design 150 Felker St #D Santa Cruz CA 95060
# 408.699.0483 digital_pager 73557,2074 cis [don't]
>1. Is cron running? Does it look like this? (uid=root, started by init)
> root 165 1 0 Sep 18 ? 0:14 /etc/cron
No problems here, cron looks good so far...Quote:>2. Is the script correct? Run (e.g. for root):
at.deny exists, but has nothing in it.Quote:>3. Do you have the files in /usr/lib/cron mangled?
> (This would be my guess is the problem)
path looks good at my end.Quote:>4. Does your migrated script have a problem with the path?
N/AQuote:>5. If you decide to run SUID or GUID shell from cron, insure
>6. If your shell script creates megaboat monster files, you may
>7. If you need an excuse to buy a bigger hard disk, turn on
time is right on.Quote:>8. Make sure you date and time are correct (or at least close).
I am running SCO and can't get my crontabs going. It says that it found
cron aborted: cannot start cron; FIFO exists
! cannot start cron; FIFO exists Thu Sep 21 12:06:41 MDT 1995
! ******* CRON ABORTED ******* Thu Sep 21 12:06:41 MDT 1995
Ever heard of FIFO and how to solve this problem??
Any help appreciated.
Jennifer Corey Lethbridge Internet Services
When I had that problem, nuking /usr/lib/cron/FIFO and rebootingQuote:>I too am having problems getting my cron to work. I took this little
>questionaire and everything on my end looks good. I keep getting an
>error about the cron finding FIFO.
su - root -c <script file>
Jennifer, your problem is that cron at one point died improperly.
There is a named pipe called /usr/lib/cron/FIFO which cron expects to
create for itself and it gets upset if it is already there. Normally
cron deletes the file when it is stopped, but if it dies without doing
that the file stays. Delete the file and then try starting cron.
If someone accidentally sets the time wrong on boot up -
typically getting the month or year wrong - shutdown and start
If, for example, the year gets set wrong to 94 instead of 95,
and you set it from asktime, you will see your machine go
through a monumental slowdown.
On my machine I have about 5 things that execute every hour.
If the year were off by one and reset then cron would realize
that it missed a few jobs and would only get back up to speed
after it execute the 40,000+ jobs waiting. 24 hours/day times
265 days tiems 5 job per hour.
I've seen this happen to people a couple of times. I don't
know if more modern crons have fixed this - but because of some
critical things that couldn't be interupted I saw a machine
beat itself senseless for an hour trying to catch up on a full
years worth of cron jobs.
I'm wondering, has anyone else run into problems where CRON jobs
don't all seem to run? I have a number of crontab entries, some
of which run, others of which don't ever seem to do anything.
Is cron in .99P12 (SLS 1.03) flakey?
2. putpwent() subroutine on AIX RS6000 system
4. Multi Task on dumb terminal
7. Help!!! cron jobs are not running
9. cron did not run root jobs (solaris 2.5.1)
10. cron running jobs not in crontab
11. **cron jobs do not alwats run
12. Solved: cron not running jobs.