Re: About ISC-cron

Xin LI <delphij_at_frontfree.net> wrote:
> I have Google'd the mailing list and found no discussion explaining why
> we have not upgraded our cron and friends. Is there any discussion I
> have missed? In other words, should I make these work a port, or a diff
> against src/, when I have finished the whole thing?

Be careful that you do not bring back a historical Berkley DB
problem that used to bite people using cron.

The problem was related to the cron program mapping in the
database pages, and then returning a pointer to the record
itself for getpwent.  The mapping didn't expect whar cron
then did, which was modify the record in place, not realizing
that the passwd database entry being returned was not pointing
to a static data area.  Technically, this is bogus, and we
should probably copy the returned entry to a static save area
so that code that tries to out-clever itself won't end up with
its foot shot off.

Anyway, as a result, run cron long enough, it would stomp a
page from the password database on random files occasionally.
This was a problem on InterJets for Whistle; since we had a
crontab entry that ran "newsyslog" once a second, it was almost
always the crontab itself that got stomped.  Our "fix" for this
on th InterJet was a kludge to rebuild the crontab on reboot,
in case it had been corrupted (the underlying VM issue was about
impossible to identify, given the circumstances where it would
reproduce being so rare).  I believe FreeBSD worked around this
issue in cron itself; if so, you would need to pull it forward
(I'm pretty sure the corruption issue itself was taken care of,
but I can't guarantee it).  The InterJet approach was a kludge
because the first thing you noticed to tell you there was a
problem was that your logfiles filld up, and "newsyslog" was/is
not smart enough to recreate history and break up huge log
files, once they existed.

Another issue you might want to deal with is use of numeric
user identifiers should be allowed/preferred, with the alpha
ones being more of a comment.  The issue here is that if you
are binding to another server for your password database, cron
is started early enough that users not in the local passwd file
that come from that server won't be resolved until that server
runs.  I'm pretty sure that the Samba name services, and also
potentially the LDAP name services, are started later than cron
itself is started.  Generating them from the names after a
contab -e would probably fix things transparently enough.

-- Terr