4

Let's say the system powers down unexpectedly due to a power outage.

Are flock locks always considered to be "unlocked" when the system starts up?

On Linux, flock relies on fcntl(...) (file descriptors).

Asked another way: Is it unnecessary to manually call flock -u <lock_filename> when the system first starts up? (i.e. from cron @reboot)?

Update:

BSD flock man pages says: 

Locks are on files, not file descriptors.   That is, file descriptors
duplicated  through dup(2) or fork(2) do not result in multiple instances
of  a lock, but rather multiple references to a single lock.
dajon
  • 2,350
  • 1
  • 16
  • 17

2 Answers2

2

My Linux guru friend here mentions that there is a kernel locks table (for file locks) (usually stored in memory) which disappears on a reboot.

And that the file lock is just there for as long as the process is running.

dajon
  • 2,350
  • 1
  • 16
  • 17
-1

According to the linux man page:

Locks created by flock() are associated with an open file table entry.

This is a data structure in the kernels memory and not in the file system that may be on persistent disk storage.

Open files are closed when the process exits - thus flocks are valid only as long as a process holding it is running.

nishantjr
  • 1,788
  • 1
  • 15
  • 39
  • 1
    This answer is incorrect. The FreeBSD System Calls Manual's [flock](http://www.freebsd.org/cgi/man.cgi?query=flock&sektion=2)(2) explicitly says: "Locks are on files, not file descriptors." – eatnumber1 Jul 22 '14 at 16:21
  • I've replaces `file descriptor` with `open file table entry`. By files, the man page does NOT mean physical files on the disc though. – nishantjr Jul 23 '14 at 11:11