Seeing ENOTCAPABLE from write FDs in kqueue?
Adrian Chadd
adrian at freebsd.org
Mon Jun 2 17:58:44 UTC 2014
Hi guys/all,
I've been tinkering with my RSS stuff where I have multiple listen
sockets, one per worker thread, all terminating high throughput TCP
transactions. It's all HTTP; I'm using libevent, evhttp and a very
small amount of glue code to achieve this.
libevent craps out from time to time because occasionally one of the
events in kqueue returns ENOTCAPABLE.
ENOTCAPABLE: ident=1686, filter=-2, flags=0x00004000, fflags=0x00000000, data=93
ENOTCAPABLE: ident=1324, filter=-2, flags=0x00004000, fflags=0x00000000, data=93
ENOTCAPABLE: ident=1740, filter=-2, flags=0x00004000, fflags=0x00000000, data=93
ENOTCAPABLE: ident=1628, filter=-2, flags=0x00004000, fflags=0x00000000, data=93
ENOTCAPABLE: ident=1199, filter=-2, flags=0x00004000, fflags=0x00000000, data=93
ENOTCAPABLE: ident=818, filter=-2, flags=0x00004000, fflags=0x00000000, data=93
ENOTCAPABLE: ident=389, filter=-2, flags=0x00004000, fflags=0x00000000, data=93
It's happening on the various data FDs; not on the listen socket.
What I'm seeing from ktrace:
27770 rss-http CAP operation requires <CAP_EVENT>, descriptor holds
<CAP_MAC_GET,CAP_MAC_SET,CAP_SEM_GETVALUE,CAP_SEM_POST,CAP_SEM_WAIT,CAP_EVENT,CAP_KQUEUE_EVENT,CAP_IOCTL,CAP_TTYHOOK,CAP_PDGETPID,CAP_PDWAIT,CAP_PDKILL,CAP_EXTATTR_DELETE,CAP_EXTATTR_GET,CAP_EXTATTR_LIST,CAP_EXTATTR_SET,CAP_ACL_CHECK,CAP_ACL_DELETE,CAP_ACL_GET,CAP_ACL_SET,CAP_KQUEUE_CHANGE>
27770 rss-http CAP operation requires <CAP_EVENT>, descriptor holds <>
27770 rss-http CAP operation requires <CAP_EVENT>, descriptor holds <>
27770 rss-http CAP operation requires <CAP_EVENT>, descriptor holds <>
27770 rss-http CAP operation requires <CAP_EVENT>, descriptor holds <>
27770 rss-http CAP operation requires <CAP_EVENT>, descriptor holds <>
.. so, why exactly would I be seeing this? Is this some capability
race where we have an FD setup but no capability yet assigned when
it's added into the kqueue set?
It's happening under high throughput (> 30,000 TCP sessions a second.)
Where would I continue debugging this?
Thanks!
-a
More information about the freebsd-arch
mailing list