Very Computer

  Is there a known problem in recent versions of SCO Unix (i.e., this is
not the old time granularity problem) with cron jobs not being run
properly?  I have a system recently migrated to SCO from another version
of Unix, and certain jobs refuse to run from cron, even though the
crontab entries are correct and the scripts run fine if run manually.  I
have also had difficulties on another SCO system with another script
entirely -- same problem.
  By "refuse to run" I mean that it is as if the entry just wasn't in
the crontab at all (and yes, I changed crontab the "proper" way so cron
knows it changed).

: What was the other version of UNIX? Many others use '/var/spool/cron/crontabs'
: instead of '/usr/spool/cron/crontabs'.

   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.

writes:

|> : What was the other version of UNIX? Many others use
|> '/var/spool/cron/crontabs'
|> : instead of '/usr/spool/cron/crontabs'.
|>
|>    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
thought.

+---------------------------------------------------------------------+
| Youri N. Podchosov (ynp) * Davidsohn & Son, Inc. NYC * 718-234-4140 |

+---------------------------------------------------------------------+

:   By "refuse to run" I mean that it is as if the entry just wasn't in
: the crontab at all (and yes, I changed crontab the "proper" way so cron
: knows it changed).

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)
        at.allow
        at.deny
        cron.allow
        cron.deny
    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:

    (for ksh)
    export PATH=/bin:/usr/bin:/etc:/u/bin:/usr/lib/uucp:/u/hack/bin

    (for sh)
    PATH=/bin:/usr/bin:/etc:/u/bin:/usr/lib/uucp:/u/hack/bin
    export PATH

    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
    the construct:

    /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
    and changeing:
        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:
        /etc/init b

8.  Make sure you date and time are correct (or at least close).
    If you need to change it, use:
        /etc/asktime

--
# Jeff Liebermann  Liebermann Design  150 Felker St #D  Santa Cruz  CA  95060

# 408.699.0483 digital_pager    73557,2074  cis [don't]

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.

yes

Quote:>2.  Is the script correct?   Run (e.g. for root):
> snip...

No problems here, cron looks good so far...

Quote:>3.  Do you have the files in /usr/lib/cron mangled?
>    (This would be my guess is the problem)
>    at.allow
>    at.deny
>    cron.allow
>    cron.deny

at.deny exists, but has nothing in it.
cron.deny exists, but is also empty.

Quote:>4.  Does your migrated script have a problem with the path?
> snip...

path looks good at my end.

Quote:>5.  If you decide to run SUID or GUID shell from cron, insure
> snip...
>6.  If your shell script creates megaboat monster files, you may
> snip...
>7.  If you need an excuse to buy a bigger hard disk, turn on
> snip...

N/A

Quote:>8.  Make sure you date and time are correct (or at least close).
> snip...

time is right on.

I am running SCO and can't get my crontabs going.  It says that it found
FIFO:

# cron
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

===================================================================
Jennifer Corey                         Lethbridge Internet Services

===================================================================

Quote:>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.

When I had that problem, nuking /usr/lib/cron/FIFO and rebooting
took care of things.

Tim Kuehn

    Thanks to all who responded to my post, both here and via Email.  I
have solved my problem and have learned a lot more about SCO cron that
will be useful in the future.  It seems that the job (I was wrong about
the entry never getting run) depended on a particular environment variable
being set (it did not matter on the old system, since the file the
variable pointed at was in a more-standard place).  This does not get
set when run from cron.  What worked was

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.

Let me throw in something that is not related exactly to this
job but is related to cron and asktime and can cause problems
if you aren't aware of this 'gotcha'!!

If someone accidentally sets the time wrong on boot up -
typically getting the month or year wrong - shutdown and start
over.

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.

--