in reply to File lock demo
In the context you are showing this is safe and effective. I just wanted to mention a couple of things relating to the open mode you are using, ">". In your use-case, the semaphore file is safe. But if someone were to come along and look at this as how to open an output file they could be exposing themselves to a nasty race condition. Also, a common idiom in using a semaphore lock file for highlander control is to write the lock-holder's PID into the lockfile. In both cases, the ">" open is risky.
Here's the scenario:
- First process opens an output file, obtains a lock, and writes something into the file.
- Second process opens the same output file, but fails to obtain a lock because the first process holds the lock. However, because the file was opened in ">" mode, the file's contents were truncated to zero. So the process that failed to obtain a lock modified the file that some other process had a lock on before attempting to get a lock.
It is sometimes useful to write a PID into a lockfile so that it is easier for an observer to know who holds the lock, or who is manipulating the file. This isn't strictly necessary; it's informative. I could, as an outsider to the software, come along and look, seeing that myscript.LOCK contains the pid 6327. I can look and see if that PID is still alive, how long it's been running, how much memory it's using, and so on. There are other ways to discover who holds a lock, but just looking at a PID written into a file is an easy way. For that to work reliably, however, it is necessary that nobody opening the file modify it in any way before obtaining a lock. open my $fh, '>', $lockfile modifies the file before there's an opportunity to lock it.
There are strategies for preventing this situation. One is to use sysopen for finer-grained control; open with O_CREAT but without O_TRUNC, for example. Another option is to open in append mode. I've used both. If opening in append mode, with the intent of clobbering the content of the file after obtaining a lock, it would be necessary to seek to the beginning and truncate manually after obtaining the lock, before writing into the file. One reason for using sysopen would be if you want the call to fail entirely if the file already exists: O_CREAT|O_EXCL.
There's an MJD talk, the slides for which are really useful: File Locking Tips and Traps. In those slides, "+<" is used.
I think I gave a YAPC talk on flocking a few years back that may also provide some explanation: https://youtu.be/tWdmxrtPiKs.
Anyway, the point to this follow-up is please don't open in '>' mode and then obtain a lock, if you care about the contents of the file, because if you fail to get the lock because someone else holds it, you just stomped on them.
Dave
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: File lock demo
by LanX (Saint) on Apr 21, 2021 at 19:44 UTC | |
by davido (Cardinal) on Apr 21, 2021 at 20:35 UTC | |
by LanX (Saint) on Apr 21, 2021 at 21:07 UTC | |
Re^2: File lock demo
by LanX (Saint) on Apr 24, 2021 at 00:33 UTC | |
by davido (Cardinal) on Apr 24, 2021 at 17:27 UTC | |
by LanX (Saint) on Apr 24, 2021 at 17:38 UTC | |
by eyepopslikeamosquito (Archbishop) on Apr 24, 2021 at 22:06 UTC | |
by LanX (Saint) on Apr 24, 2021 at 23:45 UTC |