REG: difference in debug and normal mode
Hi, Is there a difference in terms of the way packets are accepted when running in debugging mode versus the normal mode. I have a very strange scenario where radius crashes when put in normal mode but runs just fine in debugging mode. I suspect it may be due to sudden surge in load, but then that would only be the case when the way radius handles packets in the two cases is different. Thanks in advance for the help. Regards, Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in
Hi, On Tue, Oct 09, 2018 at 02:19:32PM +0530, 8zero2 operations wrote:
Is there a difference in terms of the way packets are accepted when running in debugging mode versus the normal mode.
I can't answer you that question, but could you elaborate a bit on exactly which behavior you suspect to be different? Do you know what the packets look like that cause the crash? Do they crash the server reliably? Have you tried if a single one such packet is enough to cause a crash? Have you got a core dump that you can look into for a stack trace? Thanks, HC
On Tue, 2018-10-09 at 14:19 +0530, 8zero2 operations wrote:
Is there a difference in terms of the way packets are accepted when running in debugging mode versus the normal mode.
Threading is disabled.
I have a very strange scenario where radius crashes when put in normal mode but runs just fine in debugging mode.
Try radiusd -fxxl stdout instead of -X. -- Matthew
Thanks Mathew, Did what you suggested, there is an exec program(php code) running which generates coa attributes. The server dies with a segmentation fault on that program, wait = yes input_pairs = request output_pairs = coa program = "/usr/bin/php /path/to/program '%{User-Name}' '%{control:Plan-Id}' 'allcoa' '%{%{Acct-Multi-Session-Id}:-%{Acct-Session-ID}}' '%{NAS-IP-Address}'" shell_escape = yes timeout = 10 Regards, Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On Tue, Oct 9, 2018 at 3:41 PM Matthew Newton <mcn@freeradius.org> wrote:
On Tue, 2018-10-09 at 14:19 +0530, 8zero2 operations wrote:
Is there a difference in terms of the way packets are accepted when running in debugging mode versus the normal mode.
Threading is disabled.
I have a very strange scenario where radius crashes when put in normal mode but runs just fine in debugging mode.
Try
radiusd -fxxl stdout
instead of -X.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, Going further, did a backtrace. Got this: Thread 1 "radiusd" received signal SIGSEGV, Segmentation fault. 0x00000000004310e7 in coa_retransmit (request=0x7fff7000a7d0) at src/main/process.c:4295 4295 request->delay = delay * request->home_server->coa_irt; Regards, Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On Wed, Oct 10, 2018 at 10:52 AM 8zero2 operations <8zero2ops@gmail.com> wrote:
Thanks Mathew,
Did what you suggested, there is an exec program(php code) running which generates coa attributes. The server dies with a segmentation fault on that program,
wait = yes
input_pairs = request
output_pairs = coa
program = "/usr/bin/php /path/to/program '%{User-Name}' '%{control:Plan-Id}' 'allcoa' '%{%{Acct-Multi-Session-Id}:-%{Acct-Session-ID}}' '%{NAS-IP-Address}'"
shell_escape = yes
timeout = 10
Regards, Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in
On Tue, Oct 9, 2018 at 3:41 PM Matthew Newton <mcn@freeradius.org> wrote:
On Tue, 2018-10-09 at 14:19 +0530, 8zero2 operations wrote:
Is there a difference in terms of the way packets are accepted when running in debugging mode versus the normal mode.
Threading is disabled.
I have a very strange scenario where radius crashes when put in normal mode but runs just fine in debugging mode.
Try
radiusd -fxxl stdout
instead of -X.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Wed, 2018-10-10 at 11:36 +0530, 8zero2 operations wrote:
Going further, did a backtrace.
Got this:
See https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/bugs That said, what version? There were some fixes to CoA that went in recently, so you should try with the v3.0.x branch from github to see if it's already fixed. -- Matthew
Hi, Thanks for your reply. I am using 3.0.16. If I compile the latest branch would it overwrite my modules or files(I have changed)? If I still find it unresolved in latest build should i file for a bug? Regards, Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On Wed, Oct 10, 2018 at 2:49 PM Matthew Newton <mcn@freeradius.org> wrote:
On Wed, 2018-10-10 at 11:36 +0530, 8zero2 operations wrote:
Going further, did a backtrace.
Got this:
See
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/bugs
That said, what version?
There were some fixes to CoA that went in recently, so you should try with the v3.0.x branch from github to see if it's already fixed.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Wed, 2018-10-10 at 15:48 +0530, 8zero2 operations wrote:
I am using 3.0.16. If I compile the latest branch would it overwrite my modules or files(I have changed)?
"make install" shouldn't overwrite an existing raddb config, but common sense really that you should make a backup yourself... Personally I just install into a different prefix and then copy the old raddb over to the new location to test it. But if you do that you need to edit prefix/libdir etc in radiusd.conf to make sure it's using the correct paths.
If I still find it unresolved in latest build should i file for a bug?
Sending it here again is fine, unless someone asks for an issue to be opened. -- Matthew
Hi, Thanks man, I know it was a stupid question but it was more out of curiosity(don't have much experience in this) but i see it doesnt replace existing files if any. So compile the latest tree, got this: (20) coa_cn_attributes: Program executed successfully Bad talloc magic value - unknown value talloc abort: Bad talloc magic value - unknown value Backtrace of last 24 frames: /usr/local1/lib/libfreeradius-radius.so(+0xd607)[0x7ffff7955607] /usr/lib/x86_64-linux-gnu/libtalloc.so.2(_talloc_get_type_abort+0xe1)[0x7ffff708ff11] /usr/local1/lib/libfreeradius-radius.so(fr_pair_verify+0x85)[0x7ffff79675a0] /usr/local1/lib/libfreeradius-radius.so(fr_pair_list_move+0x7e)[0x7ffff7964da8] /usr/local1/lib/rlm_exec.so(+0x1888)[0x7ffff5600888] /usr/local1/lib/rlm_exec.so(+0x1b56)[0x7ffff5600b56] /usr/local1/sbin/radiusd[0x42b776] /usr/local1/sbin/radiusd[0x42bec7] /usr/local1/sbin/radiusd[0x42b93e] /usr/local1/sbin/radiusd[0x42c9b6] /usr/local1/sbin/radiusd[0x42b93e] /usr/local1/sbin/radiusd[0x42c9b6] /usr/local1/sbin/radiusd[0x42b93e] /usr/local1/sbin/radiusd[0x42c9b6] /usr/local1/sbin/radiusd[0x42b93e] /usr/local1/sbin/radiusd[0x42c9b6] /usr/local1/sbin/radiusd(modcall+0xb1)[0x42d828] /usr/local1/sbin/radiusd(indexed_modcall+0x366)[0x428c8a] /usr/local1/sbin/radiusd(process_accounting+0x22)[0x42b0ae] /usr/local1/sbin/radiusd(rad_accounting+0xe9)[0x40f1bf] /usr/local1/sbin/radiusd[0x44121c] /usr/local1/sbin/radiusd[0x43ca0b] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7ffff6c6d6ba] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ffff676b41d] Thread 79 "radiusd" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffc561c700 (LWP 42094)] 0x00007ffff6699428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. have everything installed libc6(dbg, dev), libtalloc2, Used the latest branch. Not a duplicate https://github.com/FreeRADIUS/freeradius-server/issues/1980, this happens in exec. Thanks in advance. Regards, Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On Wed, Oct 10, 2018 at 4:12 PM Matthew Newton <mcn@freeradius.org> wrote:
On Wed, 2018-10-10 at 15:48 +0530, 8zero2 operations wrote:
I am using 3.0.16. If I compile the latest branch would it overwrite my modules or files(I have changed)?
"make install" shouldn't overwrite an existing raddb config, but common sense really that you should make a backup yourself...
Personally I just install into a different prefix and then copy the old raddb over to the new location to test it. But if you do that you need to edit prefix/libdir etc in radiusd.conf to make sure it's using the correct paths.
If I still find it unresolved in latest build should i file for a bug?
Sending it here again is fine, unless someone asks for an issue to be opened.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 10, 2018, at 11:05 AM, 8zero2 operations <8zero2ops@gmail.com> wrote:
Hi,
Thanks man, I know it was a stupid question but it was more out of curiosity(don't have much experience in this) but i see it doesnt replace existing files if any. So compile the latest tree, got this:
(20) coa_cn_attributes: Program executed successfully
Bad talloc magic value - unknown value
Please see doc/bugs for more documentation on what we need from crashes. Alan DeKok.
participants (4)
-
8zero2 operations -
Alan DeKok -
Hans-Christian Esperer -
Matthew Newton