errno set on Success

[Eric Radman]

Awesome work on libkqueue!

One issue that came up for me using 1.0 on RHEL 5.7 is this: adding a
new event would always return -1, but strerror(3) revealed that the
status was "Success". Because of this I have to compare strings to find
out if an error really occurred

EV_SET(&evSet, file->fd, EVFILT_VNODE, EV_ADD | EV_CLEAR,
NOTE_DELETE|NOTE_WRITE|NOTE_EXTEND, 0, file);
if (kevent(kq, &evSet, 1, NULL, 0, NULL) == -1)
if (strcmp(strerror(errno), "Success") != 0)
err(1, "failed to register VNODE event list");

On the BSDs and Mac OS testing the exit code of kevent(2) is sufficient.
Is there a reason why a successful call returns -1?

--
Eric Radman | http://eradman.com

[Mark Heily]

It's actually failing internally, so the -1 return code is correct. You are
hitting the following unimplemented function:

int
evfilt_vnode_knote_modify(struct filter *filt, struct knote *kn,
const struct kevent *kev)
{
return (-1); /* FIXME - STUB */
}

The reason you are seeing this is because your program tries to add the same
event twice. The first time calls knote_add() which works fine. The second
time calls knote_modify() which is not implemented for EVFILT_VNODE.

This is a bug in libkqueue, and I've put it on the list of things to fix. As a
workaround, you could avoid hitting the bug by refraining from issuing
multiple calls to kevent() with duplicate EV_ADD kevents.

Regards,

- Mark

[Eric Radman]

You were right on--using EV_DELETE to remove events solved the problem. According to the man page

    "Calling close() on a file descriptor will remove any kevents that reference the descriptor."

This is what I was relying on. Is it generally a bad idea to rely on close(2) to clean up VNODE events?

Eric

[Mark Heily]

Great question.. you just helped me find a bug in the EVFILT_VNODE filter.
This filter needs to enable notification for close() events on the file
descriptor, and then automatically delete the associated knote. It shouldn't
be too hard to fix, and I'll release a new version once the fix is implemented.

Thanks a lot,

- Mark

[Mark Heily]

The fix is contained in r551 of the stable branch, and r590 of the trunk.