fanotify gremlin---hard no-return fail (under gdb) - fanotify

Question

this is almost the same example as in the man page. everything is updated to recent versions. gcc is 4.9.2. gdb is 7.8.1. linux kernel is 3.17.6-1 (64bit). the install is a recent arch bootstrap. here is the whittled down case:
#define _GNU_SOURCE /* Needed to get O_LARGEFILE definition */
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <fcntl.h>
#include <poll.h>
#include <sys/fanotify.h>
int main(int argc, char *argv[]) {
int fd;
fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK, O_RDONLY | O_LARGEFILE);
if (fd == -1) exit(1);
fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd);
if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT, FAN_OPEN_PERM | FAN_CLOSE_WRITE, -1, "/") == -1) exit(2);
fprintf(stderr, "in gdb step through with 'n' for repeat.\n");
fprintf(stderr, " (and sometimes otherwise), a ^C works, but a ^Z and then ^C does not.\n");
}
most of the time, this works fine, but sometimes it does not. I think this is when fanotify_mark never returns. on trying to debug this, I found that I can(not) replicate this for debugging. if I use gdb and try to step through with 'n', fanotify_mark() never returns and is uninterruptible (^C, ^Z).
is this replicable elsewhere, or am I doing something wrong?
/iaw

Answer 1

this happens because FAN_OPEN_PERM requires another program to grant permission. this is almost verbatim from the example in the fanotify man page---and this makes it rather unfortunate, because whittling down the program can induce a hard OS block. so watch it.
my actual intent was to monitor file accesses. for this, one uses FAN_OPEN, not FAN_OPEN_PERM.