On Fri, Jan 03, 2014 at 02:59:26PM +0100, Kjetil Torgrim Homme wrote: > 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. Welcome to POSIX/Linux locking... read nice Lennart's summary: http://0pointer.de/blog/projects/locking.html http://0pointer.de/blog/projects/locking2 > 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). Sorry, but today is not 1st Apr ;-) And process based fcntl(2) sucks more than flock(2) and for things like flock(1) it's probably completely useless. > 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. No please, flock(1) is based on flock(2), that's all. The semantic and all possible limitations are well known. I don't think we want to make things more complicated. Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- 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
