From: Joshua E Warchol (no email)
Date: Mon Mar 04 2002 - 10:03:47 EST
On Fri, Mar 01, 2002 at 01:39:53PM +0300, Michael Tokarev wrote:
> > The command takes very little time to run, and with the use of a non-
> > blocking exclusive lock I'm able to keep only one process touching the
> > map file. So this isn't creating a big issue right now, except that
> > everytime it runs twice I get an email from my software. That makes me
> > sandy.
> >
> > So, oh wise and helpful postfixers :) Anyone ever run across a problem like
> > this before?
>
> Well, it's something new to me, and it seems bizzare. Do you by any chance
> have problems with your system clock? Vixie-cron sleeps for 1 minute (using
> gettimeofday+select), wakes up, queries system time and checks all it's queue,
> runs every job found, queries systime again and sleeps for another minute.
> Looking to the source, I can't see where it can be woken up at 59 sec.
Nope, the system clocks seem steady. I've got ntpd holding the time on each
system.
> It seems something is wrong with your locking. Try to debug your script
> inserting some sleeps and running another copy while first one is running
> (or remove any output in case of lock failure).
My locking is working fine actually, it detects that another process has
an exclusive lock and exits. That is the proper behavior, unfortunately it
happens all the time because of the main crond error.
> Are you sure you really need to update your blocklists that often? Usually,
> it should be sufficient to update such things once every day, hour or e.g.
> 10 minutes (extreme!), but not every minute! This is a blocklist, after all!.. ;)
The rate of updates shouldn't matter. We typically do _not_ run cron processes
every minute, but this blocklist is needed in order to stop open relays on
our network (customer-owned relays). Also, I've got another script running
every 30 minutes that is also seeing this error. I had to add file locking
to that script too.
> Also, for such frequent tasks, I'd write a daemon that will be running all the
> time and will sleep by its own: update map, save timestamp, sleep, stat() a
> file and compare a timestamp, sleep, stat()/compare, sleep, ... -- this way,
> it is far more efficient, especially having in mind perl's startup time.
There are certainly more efficient ways to do this. A daemon process would
be better for sure. But right now the trade-off in development time isn't
worth the return.
The problem remains, cron is running twice a minute. Anyone have other
ideas?
-- Joshua Warchol UNIX Systems Administrator DSL.net - To unsubscribe, send mail to with content (not subject): unsubscribe postfix-users
|
|
|