Cron duplicates jobs?

Cron duplicates jobs?

Post by Jeff Lieberma » Wed, 18 Oct 1995 04:00:00



: We're starting to get strange things happening with some long-standing cron
: scripts - it looks like cron is starting up the jobs (which all run from
: shell scripts) twice at virtually the same time.

Oh yes.  My guess is that someone edited the scripts located
in the /usr/spool/cron/crontabs directory and left the backups
in there.  When cron comes along looking for work, it executes
both the edited and the backup version.

It is also possible to have more than one copy of cron running.
However, you really have to work to do that and I assume that
you rebooted to clear any such atroscities.  If rebooting still
starts two copies, then look in /etc/rc2.d/ directory and see
if there aren't two copies of S75cron.  Leaving editor backups
in this directory will also cause things to be run twice.

Incidentally, the politically correct way to modify cron scripts are to:
        login: root                     # It's nice to be root.
        crontab -l -u uucp > cron.uucp       # Save current crontab for uucp.
        cp cron.uucp cron.uucp.old      # Backups are nice.
        vi cron.uucp                    # Make your changes.
        crontab -u uucp cron.uucp       # Reload the modified script.
                                        # It will complain if errors are found.

The last crontab command copies the modified script into the
/usr/spool/cron/crontabs directory and informs cron that things
have changed.

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

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

 
 
 

Cron duplicates jobs?

Post by Simon Bunc » Fri, 20 Oct 1995 04:00:00





> : We're starting to get strange things happening with some long-standing cron
> : scripts - it looks like cron is starting up the jobs (which all run from
> : shell scripts) twice at virtually the same time.

> Oh yes.  My guess is that someone edited the scripts located
> in the /usr/spool/cron/crontabs directory and left the backups

Well, it was a good theory - but not what's causing our problems. I've also
checked that there's only one cron running.

I've had logging on this morning and can show what's happening:

1) Here's the relevant line from root's crontab. In this case, killidle is
a Perl script that kicks idle users out of an Informix database, but we've
had similar problems running pure shell scripts.

0,30 9-21 * * 1-5 /usr/user/bin/killidle

2) Here's some output from /usr/lib/cron/log. As you can see, the killidle
process is started up twice - the first time, 1 second before it was
actually scheduled to start!

Quote:>  CMD: /usr/user/bin/killidle
>  root 91 c Thu Oct 19 12:29:59 BST 1995
>  CMD: /usr/user/bin/killidle
>  root 95 c Thu Oct 19 12:30:00 BST 1995

<  root 95 c Thu Oct 19 12:30:15 BST 1995
<  root 91 c Thu Oct 19 12:30:15 BST 1995

This does *not* happen every time cron starts something up, or with any
discernible pattern that I can see so far.

We also run xntpd - I did wonder if that was screwing up the system clock
somehow, but /usr/adm/syslog shows that xntpd wasn't doing anything at the
time the above log was taken.

So, any ideas what's going on here? I'm baffled!

--
========================================================

SHL Learning Technologies            +44 (0)171 415 9900
========================================================

 
 
 

Cron duplicates jobs?

Post by Bela Lubki » Sat, 21 Oct 1995 04:00:00



> I've had logging on this morning and can show what's happening:

> 1) Here's the relevant line from root's crontab. In this case, killidle is
> a Perl script that kicks idle users out of an Informix database, but we've
> had similar problems running pure shell scripts.

> 0,30 9-21 * * 1-5 /usr/user/bin/killidle

> 2) Here's some output from /usr/lib/cron/log. As you can see, the killidle
> process is started up twice - the first time, 1 second before it was
> actually scheduled to start!

> >  CMD: /usr/user/bin/killidle
> >  root 91 c Thu Oct 19 12:29:59 BST 1995
> >  CMD: /usr/user/bin/killidle
> >  root 95 c Thu Oct 19 12:30:00 BST 1995
> <  root 95 c Thu Oct 19 12:30:15 BST 1995
> <  root 91 c Thu Oct 19 12:30:15 BST 1995

> This does *not* happen every time cron starts something up, or with any
> discernible pattern that I can see so far.

> We also run xntpd - I did wonder if that was screwing up the system clock
> somehow, but /usr/adm/syslog shows that xntpd wasn't doing anything at the
> time the above log was taken.

This *is* actually caused by an interaction with time-adjusting daemons
such as xntpd.  It's a bug in cron, but triggered by the mechanisms
these daemons use to adjust system time.  You say xntpd wasn't doing
anything right then; but it probably was.  It doesn't adjust time
all-at-once, it calls a system call "adjtime()", which tells the kernel
to slowly drift the time into alignment.  The drift happens one tick at
a time, by either doubling or skipping the adjustment of the system time
during the hardware timer tick.

I don't know what can be done about this besides using some sort of
locking protocol in your cron job.  (Yes, that means *every* cron job on
an affected system.  Affected systems do not include all systems using a
clock-adjuster; there appears to be some other subtle triggering factor,
like the motherboard clock running a bit fast, which is a fairly unusual
condition).

- Show quoted text -

Quote:>Bela<