Skip to main content

Timeline for Correct locking in shell scripts?

Current License: CC BY-SA 3.0

19 events
when toggle format what by license comment
Jun 11, 2020 at 12:04 history edited CommunityBot
Commonmark migration
Dec 20, 2017 at 14:44 comment added Jens Timmerman isn't /var/tmp a bad place to store lock files, since they are preserved across reboots. I don't think a process will be preserved across a reboot. So you would want a place that is explicitly cleared on reboots? Also some systems clean files in /var/tmp after 30days of non use. Something like /var/lock would make more sense?
May 6, 2016 at 14:54 comment added Tim Kennedy Thanks @maxschlepzig. I've updated the edit to specifcally refer to ksh88.
May 6, 2016 at 14:52 history edited Tim Kennedy CC BY-SA 3.0
added 89 characters in body
May 5, 2016 at 21:09 comment added maxschlepzig Tim, the page Clint linked only mentions that noclobber isn't sufficient with ksh88. Which is arguably a niche shell, nowadays. In any case, mkdir seems to have more serious limitations - cf. the links Gilles provided in a comment to Glenn's mkdir answer.
Nov 17, 2015 at 19:24 comment added jrw32982 Note: using noclobber (or -C) in ksh88 does not work because ksh88 does not use O_EXCL for noclobber. If you're running with a newer shell you may be OK...
Sep 8, 2015 at 8:46 comment added mc0e @NigelHorne makes a good point, but the existence of a process withthe appropriate PID isn't enough. The cmdline associated with that PID should also match the current one.
Jun 18, 2015 at 15:29 history edited Tim Kennedy CC BY-SA 3.0
improved answer using information from an informative comment.
Jun 18, 2015 at 15:13 comment added Tim Kennedy @ClintPachl : Thanks. Interesting reading. I like the solution of using a directory, then creating temp files in that directory, which gets cleaned up automatically.
Jun 16, 2015 at 5:09 comment added Clint Pachl The noclobber option may be prone to race conditions. See mywiki.wooledge.org/BashFAQ/045 for some food for thought.
Jun 16, 2015 at 5:04 comment added Clint Pachl @AdamKatz, that introduces an obvious race condition. A lot can happen between checking the lock file and writing/locking it. Setting the noclobber option may be atomic, but one would have to check the shell implementation to make sure open uses the O_CREAT|O_EXCL options and that the OS supports advisory locking.
Jan 15, 2015 at 23:51 comment added Adam Katz I was going to agree with @maxschlepzig about this being a bashism, but it turns out to work in dash (and zsh). I haven't tried any of the "bashism testers." Still, I disagree with this approach on deep magic grounds; it's obscure and hard to read for people who don't know what it does. Better to go with [ ! -e "$lockfile" ] && echo $$ > "$lockfile" 2>/dev/null for legibility.
Dec 17, 2014 at 13:29 comment added Nigel Horne Good answer, but you should also 'kill -0' the value in lockfile to ensure that the process that created the lock still exists.
Oct 7, 2011 at 9:45 comment added maxschlepzig I have accepted this answer because the method is safe and so far the most elegant one. I suggest a small variant: set -o noclobber && echo "$$" > "$lockfile" to get a safe fallback when the shell does not support the noclobber option.
Oct 7, 2011 at 9:43 vote accept maxschlepzig
Oct 4, 2011 at 21:11 comment added maxschlepzig Your noclobber method seems to be safe: nfs.sourceforge.net/#faq_d10 and mywiki.wooledge.org/BashFAQ/045#Discussion
Oct 4, 2011 at 20:15 comment added maxschlepzig No, with lockrun you don't have a problem - when a NFS server hangs, all lockrun calls will hang (at least) in the lockf() system call - when it is back up all processes are resumed but only one process will win the lock. No race condition. I don't run into such problems with cronjobs a lot - the opposite is the case - but this is a problem when it hits you it has the potential to create a lot of pain.
Oct 4, 2011 at 20:02 history edited Tim Kennedy CC BY-SA 3.0
added answer for lockrun portion of the question.
Oct 4, 2011 at 19:50 history answered Tim Kennedy CC BY-SA 3.0