Hey, had to bring this up again as I’m facing the same problem. Exactly with the same ’error 35’ in trace. This time it is a 6.0-stable.
Anything else can be done to track this down? Br Maxim > 24 feb. 2016 kl. 10:53 skrev Stuart Henderson <[email protected]>: > > On 2016-02-24, mxb <[email protected] <mailto:[email protected]>> > wrote: >> Hey, >> I have a strange behavior of relayd running on 5.8. >> This machine almost exclusively terminates TLS traffic. >> Exceptions are forwards which are in backup state (listen on CARP). >> >> Some times one or two relayd processes out of many consumes a lot of CPU >> and stays like this until I restart relayd. > >> ktrace gives me following: >> 4013 relayd CALL getdtablecount() >> 4013 relayd RET getdtablecount 101/0x65 >> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7ffffbb630) >> 4013 relayd STRU struct rlimit { cur=65536, max=65536 } >> 4013 relayd RET getrlimit 0 >> 4013 relayd CALL recvmsg(550,0x7f7ffffbb6a0,0) >> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable >> 4013 relayd CALL getdtablecount() >> 4013 relayd RET getdtablecount 101/0x65 >> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7ffffbb630) >> 4013 relayd STRU struct rlimit { cur=65536, max=65536 } >> 4013 relayd RET getrlimit 0 >> 4013 relayd CALL recvmsg(550,0x7f7ffffbb6a0,0) >> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable >> 4013 relayd CALL getdtablecount() >> 4013 relayd RET getdtablecount 101/0x65 >> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7ffffbb630) >> 4013 relayd STRU struct rlimit { cur=65536, max=65536 } >> 4013 relayd RET getrlimit 0 >> 4013 relayd CALL recvmsg(550,0x7f7ffffbb6a0,0) >> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable >> >> Human readable file after kdump is filled with those lines. >> This as far of my understanding is about limit of openfiles. > > It's not files; errno 35 is EAGAIN - it is likely that this was > fixed in -current (2015/12/05).
