On Jun 2, 2004, at 4:07 PM, Mike Hunter wrote: >> 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. Oh, sure, the user isn't likely to run the script again if they are waiting for the prompt to return. However, it's not difficult to imagine cron kicking off the script while the user is also running it, or for the script to already be running via cron before the user starts up a second one, etc... >> 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. You're right: this isn't a huge concern. Neither is it something which can be entirely ignored, at least not safely. >> 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 :) Fair enough. :-) The initial suggestion was interesting enough, sure, but a little well-placed criticism results in stronger ideas... -- -ChuckReceived on Wed Jun 02 2004 - 11:24:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:55 UTC