Date: Wed, 2 Jun 2004 15:46:58 -0400 From: Charles Swiger <cswiger@mac.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: current@freebsd.org Subject: Re: Problems with periodic scripts in jails [Cron <operator@sosai> /usr/libexec/save-entropy] Message-ID: <9C375698-B4CD-11D8-9C6A-003065ABFD92@mac.com> In-Reply-To: <20040602161148.GA3067@dan.emsphone.com> References: <20040602134523.GA26835@genius.tao.org.uk> <20040602140148.GA27036@genius.tao.org.uk> <20040602140923.GA27070@genius.tao.org.uk> <20040603011806.E25331@gamplex.bde.org> <20040602161148.GA3067@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 2, 2004, at 12:11 PM, Dan Nelson wrote: > A nice addition to cron might be a way to tell it that certain jobs > should be single-instance. I know about half of my cron jobs look > like: > > /usr/local/bin/lockfile -r 1 -l 3600 /tmp/runjob.LCK && ( runjob ; rm > /tmp/runjob.LCK ) > > and it'd be handy if cron would do this internally (no physical > lockfiles needed). The least intrusive way would be to add a magic > variable similar to MAILTO; NO_OVERLAP=1 or something. Anyone up for a > Junior Userland Hacker project? :) If a cron job (eg, a shell script) doesn't perform whatever locking it needs for itself, what happens when someone runs the script by hand? What happens to cron's "internal locking" if one restarts cron? Why jump through hoops to avoid creating lockfiles if you're going to need some persistent mechanism to track locks when/if cron terminates, anyway? My suggestion would be to move the invocation of lockfile into the runjob script itself, so that your crontab is smaller and less cluttered, and your runjob scripts become smart enough to fend for themselves. -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9C375698-B4CD-11D8-9C6A-003065ABFD92>