I'm testing proxying of authentications (it's not something I've done before so this could be my problem). I have a pool with 2 home servers defined in proxy.conf. For now, both servers are unreachable (blocked by a firewall). I'm using git head 2.1.x branch and I'm testing using eapol_test. The failure is repeatable, while the server is performing no other work, and occurs after the client retries twice (so three Access-Requests are sent to FR) and after the 3rd request, it wakes up from sleeping and dies: Wed Oct 13 14:44:17 2010 : Debug: Waking up in 11.3 seconds. Wed Oct 13 14:44:28 2010 : Error: ASSERT FAILED event.c[1175]: "We do not have threads, but the request is marked as queued or running in a child thread" == NULL [1]+ Abort trap: 6 radiusd -X (wd: /usr/local/etc/raddb) Any ideas? I can post complete debug output if needed and/or parts of my config.
Garber, Neal wrote:
I’m testing proxying of authentications (it’s not something I’ve done before so this could be my problem). I have a pool with 2 home servers defined in proxy.conf. For now, both servers are unreachable (blocked by a firewall). I’m using git head 2.1.x branch and I’m testing using eapol_test. The failure is repeatable, while the server is performing no other work, and occurs after the client retries twice (so three Access-Requests are sent to FR) and after the 3^rd request, it wakes up from sleeping and dies:
Ah... I don't usually do builds && tests without pthreads.
Wed Oct 13 14:44:17 2010 : Debug: Waking up in 11.3 seconds.
Wed Oct 13 14:44:28 2010 : Error: ASSERT FAILED event.c[1175]: "We do not have threads, but the request is marked as queued or running in a child thread" == NULL
Hmm... the assert isn't on line 1175 in current git, but that doesn't matter.
Any ideas? I can post complete debug output if needed and/or parts of my config.
Delete the assert, and replace it with a "goto" that jumps down to the "case REQUEST_DONE" statement. Alan DeKok.
Ah... I don't usually do builds && tests without pthreads.
Actually, I am building/testing with pthreads. However, I was running in debug mode (radiusd -X). The problem does not occur when I don't start radiusd with -X. Some additional debug code in event.c shows the following sequence of events: radiusd.c:main spawn_flag = FALSE (due to -X flag) event.c:radius_event_init have_children = spawn_flag event.c:request_pre_handler request->child_state = REQUEST_RUNNING event.c:no_response_to_proxied_request: request->child_state = REQUEST_RUNNING event.c:wait_a_bit request->child_state == REQUEST_RUNNING && !have_children radiusd dies with ASSERT FAILED..
Hmm... the assert isn't on line 1175 in current git,
Ugh.. I tested originally with pre-2.1.0, then retested with current git, then posted the output from the original test <duh>.
Delete the assert, and replace it with a "goto" that jumps down to the "case REQUEST_DONE" statement.
I can do that; but, are you saying this should be a permanent change because REQUEST_RUNNING & REQUEST_QUEUED are valid states even if not threading? If not, shouldn't the assignments be changed not to use REQUEST_RUNNING if not threading? Seems like we wouldn't want the server to die just because we're debugging and I'd rather not have to maintain a local change (to delete the assert) if I don't have to.. Thanks and I'm sorry for the "20 questions", I'm just trying to better understand the issue..
Garber, Neal wrote:
Actually, I am building/testing with pthreads. However, I was running in debug mode (radiusd -X). The problem does not occur when I don't start radiusd with -X. Some additional debug code in event.c shows the following sequence of events: ... !have_children radiusd dies with ASSERT FAILED..
Yes. The packet is proxied in single server mode. The home server never responds, and... there you go. :(
I can do that; but, are you saying this should be a permanent change because REQUEST_RUNNING & REQUEST_QUEUED are valid states even if not threading? If not, shouldn't the assignments be changed not to use REQUEST_RUNNING if not threading? Seems like we wouldn't want the server to die just because we're debugging and I'd rather not have to maintain a local change (to delete the assert) if I don't have to..
It's a permanent change. See latest "git" for a fix.
Thanks and I'm sorry for the "20 questions", I'm just trying to better understand the issue..
Understanding is good. Alan DeKok.
DeKok, Alan wrote:
It's a permanent change. See latest "git" for a fix.
Thanks Alan. I just retested and, uh, don't shoot the messenger, but now it dies in event.c:cleanup_delay(): Debug: Waking up in 11.4 seconds. Error: ASSERT FAILED event.c[536]: (request->child_state == REQUEST_CLEANUP_DELAY) || (request->child_state == REQUEST_DONE) [1]+ Abort trap: 6 radiusd -X (wd: ~/freeradius-server)
Garber, Neal wrote:
DeKok, Alan wrote:
It's a permanent change. See latest "git" for a fix.
Thanks Alan. I just retested and, uh, don't shoot the messenger, but now it dies in event.c:cleanup_delay():
Debug: Waking up in 11.4 seconds. Error: ASSERT FAILED event.c[536]: (request->child_state == REQUEST_CLEANUP_DELAY) || (request->child_state == REQUEST_DONE)
<shrug> Assertions are there to catch sanity failures. In this case, the request was treated as "done" without being explicitly marked "done". Do a "git pull". :)
participants (2)
-
Alan DeKok -
Garber, Neal