[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cron not updating -> errors



On 06-May-00, 13:04 (CDT), Santiago Garcia Mantinan <manty@i.am> wrote: 
> > > Well, you have pointed me in the right direction, hoever, this, or what I'm
> > > using (a test -x file && file), solves the problem when a dpkg -r is done,
> > > but the problem is still there if a dpkg --purge is done.
> > How so? Purging does all that removing does, plus it removes conffiles.
> 
> Yes, and as I have the cron.d entry as a conffile, when I do a --purge the
> cron.d entry is removed, and at the next time it was due to be executed,
> cron tries to execute the program, even though the entry in cron.d is not
> there anymore, that causes the error :-((((

I was going to argue with Josip, and while I was preparing the argument,
I realized that there shouldn't, in fact, be a problem.  Not that
I think you're not seeing an error, just I don't think it's what
you think it is. 

Let's work with package foo, which has config file /etc/cron.d/foo:

* * * * * root test -x /usr/sbin/foo_me && /usr/sbin/foo_me

Now, if you remove (not purge) the package, then the cron.d/foo is still
there (since it's a config file), so every minute it will check for
/usr/sbin/foo_me, and since it's not there, won't try to run it. Ok so
far?

Suppose instead of removing the package, we purge the package,
so both /etc/cron.d/foo and /usr/sbin/foo_me are removed. Let's
say we do it at 14:53:32, and dpkg completes instantaneously :-).
At 14:54:00, cron looks at it's internal db, which still has the
entry for /etc/cron.d/foo (because of the 1 cycle update delay I
mentioned in another message). That's ok though, because the test for
/usr/sbin/foo_me will still fail, and it won't run it. Then cron notices
that the /etc/cron.d dir has been updated, re-reads the files, and the
foo entry is deleted.


Now, there *are* two opportunities for a file not found kind of
error. One is that the purge happens between the time that cron looks at
the directory for new/changed files and the time it tries to read the
file. However, since it only checks the directory when directory gets
updated, and thus would require two or more changes in the same cycle
plus a very fast race, I think it's *extremely* unlikely. The symptom
for this, by the way, would be an error in the syslog, not an e-mail.

The second is that the purge or remove would occur between "test -x
/usr/sbin/foo_me" and the execution of foo_me. Slightly more likely, but
also a race and hardly repeatable.

So, Santiago, can you make your package available? I'll look at it and
see if I can figure out what the problem is.


Steve


Reply to: