Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As its name suggests, the <code>flock</code> utility wraps the <code>flock(2)</code> system call, whose <a href="http://linux.die.net/man/2/flock" rel="nofollow">documentation</a> states that it associates the lock with the fd's entry in the table of open files. Open files get removed when the last file descriptor is closed, and descriptors are themselves transient resources automatically cleaned up when the process exits in any fashion, including <code>kill -9</code>. Forcible shutdown of the machine wipes the whole state of the running system, so locks associated with opened files cannot survive that scenario either. Therefore a script that exits in a timely fashion should not block the system.</p> <p>One realistic possibility of blocking that comes to mind is the script having a bug that causes it to hang indefinitely, which will indeed prevent other instances from being able to run. If this is expected to occur in practice, it can be handled by writing out the script PID (<code>$$</code>) into the lock file immediately after acquiring the lock. Before the lock is acquired, the process that waits for the lock would specify a timeout using the <code>-w</code> option to <code>flock</code>. If the timeout expires, it would read the PID of the hanging lock owner from the lock file, kill the owner, and repeat the locking process.</p> <p>A theoretical problem is the hardcoded file descriptor number 200. If your script opens 200 files, or is spawned from a program that opens 200 files without the close-on-exec bit, you will clobber an existing file descriptor. This is highly unlikely to occur in practice.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload