Daniel Berrangé suggested to use fcntl() locks rather than lockf().
'man lockf':
On Linux, lockf() is just an interface on top of fcntl(2) locking.
Many other systems implement lockf() in this way, but note that
POSIX.1 leaves the relationship between lockf() and fcntl(2) locks
unspecified. A portable application should probably avoid mixing
calls to these interfaces.
IOW, if its just a shim around fcntl() on many systems, it is clearer
if we just use fcntl() directly, as we then know how fcntl() locks will
behave if they're on a network filesystem like NFS.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <
20180831145314.14736-3-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
while (1) {
struct stat a, b;
+ struct flock lock = {
+ .l_type = F_WRLCK,
+ .l_whence = SEEK_SET,
+ .l_len = 0,
+ };
fd = qemu_open(path, O_CREAT | O_WRONLY, S_IRUSR | S_IWUSR);
if (fd == -1) {
goto fail_close;
}
- if (lockf(fd, F_TLOCK, 0) < 0) {
+ if (fcntl(fd, F_SETLK, &lock)) {
error_setg_errno(errp, errno, "Cannot lock pid file");
goto fail_close;
}