Date: Sat, 9 Dec 2000 22:42:41 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Brian Somers <brian@Awfulhak.org> Cc: Dag-Erling Smorgrav <des@ofug.org>, "David E. O'Brien" <obrien@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc crontab Message-ID: <Pine.NEB.3.96L.1001209223834.82272B-100000@fledge.watson.org> In-Reply-To: <200012092254.eB9Msbk55407@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Dec 2000, Brian Somers wrote: > It makes things a bit un-orthogonal though. Maybe something like > this would be more appropriate: > > 1 3 * * * root lockf /var/run/periodic periodic daily > 1 3 * * 6 root lockf /var/run/periodic periodic weekly > 1 3 1 * * root lockf /var/run/periodic periodic monthly While this is really much cleaner and appealing to me, it runs into the usual file locking problem: since they're advisory, they're inter-user and enforced for root (!). As such, any random process running as any random user can acquire the lock and stack up all your periodic scripts, DoSing you. And it's hard to track down, too, since it's hard to figure out what processes own what locks. This actually applies to a really large number of other related problems: for example, when locking is used to protect mailboxes, any user can deny service by acquiring locks on all mailboxes, etc. Usually the solution is to only use locks on objects which are appropriately protected, unfortunately. On a related note, this is also more susceptible to cascading failure, as it queues the work rather than canceling it if resources aren't available. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1001209223834.82272B-100000>