I was a bit surprised to find that flock(2) specifically ignores fcntl
locks. from its manual page:
Since kernel 2.0, flock() is implemented as a system call in
its own
right rather than being emulated in the GNU C library as a
call to
fcntl(2). This yields true BSD semantics: there is no
interaction
between the types of lock placed by flock() and fcntl(2), and
flock()
does not detect deadlock.
I was trying to check if dpkg or apt-get was holding its lock and skip
running my cron job if so, but unfortunately it uses fcntl (F_SETLK),
and flock(1) will happily call flock(2) which succeeds.
it's a bit sad to have to write the lock testing in C or Perl rather
than use the nice little flock(1), so I wonder if we could "fix"
flock(1) somehow. I think I'm not alone to be surprised that flock(1)
is so ineffective against locking done by other utilities, so my
prefered solution would be to switch to using fcntl(2).
the chance of a problematic regression is small, I think. my *guess* is
that most flock(1) usage is only interacting with other usage of
flock(1) (not flock(2)). also relying on flock(1) succeeding on a
fcntl-locked file would be just Wrong(tm).
the "safe" solution is to add a flag, --fcntl, but isn't that just cruft?
I can provide patches when I hear what the mailing list wants.
--
Kjetil T. Homme
Redpill Linpro - Changing the game
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
