Right.
So, this email will start with an apology for all the noise, and false
alarm.
Having said that, I do owe some explanation.
[ I also found it strange that leaking that socket helped. ]
That socket, is valid though, since it was returned by usock() in
ubus_reconnect().
What really happened
On 2014-08-01 18:01, Alexandru Ardelean wrote:
> Back with some findings.
>
> Please check this:
> https://github.com/commodo/ubus/commit/c601505a6b33aa208e1a3492d3ade5ae2d853899
That looks very wrong to me. If that triggers, you're leaking the fd.
> The current problem [high CPU usage] seems to
I just recalled that we're also using libcurl (which uses uloop).
I am wondering now if closing the socket interferes with libcurl.
Will check later.
On 2 Aug 2014 01:22, "Alexandru Ardelean" wrote:
> Thank you for looking into it.
>
> Will wait for an answer on that.
>
> Thanks
> On 1 Aug 2014
Thank you for looking into it.
Will wait for an answer on that.
Thanks
On 1 Aug 2014 23:49, "John Crispin" wrote:
>
> On 01/08/2014 18:01, Alexandru Ardelean wrote:
> > Please check this:
> >
> https://github.com/commodo/ubus/commit/c601505a6b33aa208e1a3492d3ade5ae2d853899
> *cough* ... looks l
On 01/08/2014 18:01, Alexandru Ardelean wrote:
> Please check this:
> https://github.com/commodo/ubus/commit/c601505a6b33aa208e1a3492d3ade5ae2d853899
*cough* ... looks like i was holding the tool wrong when i wrote that
function. thanks for the debugging effort, will look into it tomorrow
Jo
Back with some findings.
Please check this:
https://github.com/commodo/ubus/commit/c601505a6b33aa208e1a3492d3ade5ae2d853899
The current problem [high CPU usage] seems to have appeared after some
modifications we made to the code which were related to a recent proposal
patch I sent [ that got reje
I'll see what I can find.
At the time I created this patch I had it reproducing more often, but not
often enough to trace a cause.
The patch seems to help, but [as you've said] the error seems like
something else.
Seems to be reproducing again, after a while, and in a certain
configuration.
I'll
On 2014-07-29 15:23, Alexandru Ardelean wrote:
> Quick info follow-up: strace-ing on the PIDs (with high CPU usage)
> shows a lot of EAGAIN errors from recvfrom() and a lot of recvfrom() +
> poll() + clock_gettime_monotonic() calls.
>
> Thinking about it, would it make more sense to add a short w
Quick info follow-up: strace-ing on the PIDs (with high CPU usage) shows a
lot of EAGAIN errors from recvfrom() and a lot of recvfrom() + poll() +
clock_gettime_monotonic() calls.
Thinking about it, would it make more sense to add a short wait instead [to
reduce the throttle] and let it "infinite
Seems that every once in a while libubus takes up the whole CPU
for certain processes.
This could be bad code that I keep (re)writing.
I don't know if it's ok to give up after a certain number of
retries; high CPU usage could indicate I should look deeper
at my logic.
Which is why I've submitted
10 matches
Mail list logo
