Date: Mon, 19 Jul 2004 05:02:28 -0700 (GMT-07:00) From: Terry Lambert <tlambert2@mindspring.com> To: Xin LI <delphij@frontfree.net>, current@FreeBSD.org Subject: Re: About ISC-cron Message-ID: <27293807.1090238549091.JavaMail.root@wamui01.slb.atl.earthlink.net>
next in thread | raw e-mail | index | archive | help
Xin LI <delphij@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27293807.1090238549091.JavaMail.root>