assert in util.c:189 on exit
And so for the last week I have been happily using cvs20050929 with a couple one liners. This morning logs look like this: Fri Oct 7 08:29:29 2005 : Error: !!! ERROR !!! The server is blocked: discarding new request 181169 Fri Oct 7 08:29:29 2005 : Error: !!! ERROR !!! The server is blocked: discarding new request 181170 Fri Oct 7 08:29:30 2005 : Error: !!! ERROR !!! The server is blocked: discarding new request 181171 Fri Oct 7 08:29:30 2005 : Error: !!! ERROR !!! The server is blocked: on and on (any idea why? this never happened before [ before means cvs from 20050316 ]) so I executed /etc/init.d/freeradius stop and got the above assert. Apparently a gracefull exit is hard to do if the server has blocked threads? Where should I start looking? Thanks, Joe
Joe Maimon <jmaimon@ttec.com> wrote:
This morning logs look like this:
Fri Oct 7 08:29:29 2005 : Error: !!! ERROR !!! The server is blocked: discarding new request 181169 ... (any idea why? this never happened before [ before means cvs from 20050316 ])
I don't *think* any of the changes to threads.c would cause this problem. But that message is produced only when the request queue is full. i.e. new requests are coming in faster than the server can process them.
so I executed /etc/init.d/freeradius stop
and got the above assert.
Apparently a gracefull exit is hard to do if the server has blocked threads?
Yes. It tries to exit cleanly, but something calls request_free() on a request currently being used by a thread. The solution to that problem is simply to *not* call request_free() when exiting. As for why it's blocked, see the rest of the debug log. It *should* tell you what's blocked, and where. Alan DeKok.
Joe Maimon wrote: Got assert in util.c:189 on a HUP (not everytime) apparently on a HUP rl_deinit() is called from listen_free() from read_mainconfig() That deletes all requests and asserts that nobody is using any of them. I suppose the change can be not to free all requests on a HUP and/or to return from request_free() like so if(request->child_pid != NO_SUCH_CHILD_PID) return;
Joe Maimon <jmaimon@ttec.com> wrote:
apparently on a HUP rl_deinit() is called from listen_free() from read_mainconfig()
That deletes all requests and asserts that nobody is using any of them.
Whoops. listen_bind() re-uses the FD on re-init, and it should re-use the request list, too. I'll commit a patch in a few minutes. Alan DeKok.
participants (2)
-
Alan DeKok -
Joe Maimon