[414] in athena10
Re: Automatic updates for Athena 10
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Aug 13 15:07:40 2008
From: Greg Hudson <ghudson@MIT.EDU>
To: Jonathon Weiss <jweiss@mit.edu>
Cc: Kenneth Arnold <kcarnold@mit.edu>, athena10@mit.edu
In-Reply-To: <200808120236.m7C2aNLt013281@vorpal-blade.mit.edu>
Content-Type: text/plain
Date: Wed, 13 Aug 2008 15:06:55 -0400
Message-Id: <1218654415.12433.194.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
On Mon, 2008-08-11 at 22:36 -0400, Jonathon Weiss wrote:
> I'd feel a lot better if we desync'd over at least the course of an
> hour. Is there a particualr reason not to? I'm certainly willing to
> say it doesn't matter for the pre-release, but when we go to full
> production, I'd be nervous about lacking it.
It's just not trivial to do in a clean manner. cron.hourly jobs are run
synchronously, which means if you want to desync them you have to sleep
and run in the background, which in turn might interfere with cron's
logging, and means an extra entry or two in the process table while it's
running. This is already the case in 9.4 (you can see "desync"
processes in your process listing) and it's manageable, but if it were
unnecessary it would be best done away with.
Not blocking logins across a whole cluster at the same time is a pretty
compelling argument, though.
> As an aside, ops has started descynchronizing all of
> /etc/cron.{monthly,weekly,daily,hourly} themselves. We got bitten by
> one or two of the weekly and daily jobs firing off at once on 10-15
> VMs and taking out the host they were running on. Not desyncronizing
> things that run on many machines always seems to find a way to bite
> us.
That's perhaps a better approach. It does require computing the
contents of /etc/crontab and /etc/cron.d/anacron at runtime (or package
install time), which is more complicated than a simple diversion.
