Re: Problems with periodic scripts in jails [Cron <operator_at_sosai> /usr/libexec/save-entropy]

On Jun 02, "Charles Swiger" wrote:

> 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?

For stuff that I do, when you run the script by hand, you see when it's
done by returning to the prompt, so you're not likely to run it until it's
finished.

> 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?

I've restarted cron once due to a time zone error, other than that, cron
tends to restart when the machine is booted, and that's about it :)  Maybe
some day I'll be hardcore enough to set up systems that put cron at risk,
but I think for the average user it's not a huge concern.

> 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.

That's a good suggestion.  I do think that cron itself strongly influences
the need for locking in some situations, and that it therefore might be 
appropriate to put functionality to deal with it in cron.  I drooled when
I read the initial suggestion :)

Mike