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 <stu@spacehopper.org>:
>
> On 2016-02-24, mxb <mxb@alumni.chalmers.se <mailto:mxb@alumni.chalmers.se>> 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).
No comments:
Post a Comment