<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.17095" name=GENERATOR><!-- converted from rtf -->
<STYLE>.EmailQuote {
        PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt; BORDER-LEFT: #800000 2px solid
}
</STYLE>
</HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2>You must realize that "gdb" by itself is an answer that is 
of very little use.  While I am aware that gdb is the GNU Debugger, you 
have no way of knowing that I do, and you gave no other context or other 
information that would help me use gdb to gather anything.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2>So let me be more clear:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2>What EXACTLY do I need to do to get more information about 
this phenomenon, and under what circumstances do I need to do it, and once I 
have some output, what should I be looking for in it?  Running production 
RADIUS servers with "strace radiusd -X" is probably impractical (and highly 
insecure), and may even alter the runtime environment such that the fatal event 
never occurs.  I've never observed the failure in either of the two test 
servers I run, and their configurations are identical, so I must assume that 
radiusd dies after receiving some sort of improper/unexpected data, or when it 
gets into some weird state, or other such thing.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2>But it can't be fixed if I can't figure out how to 
reproduce it.  It'll happen eventually, but a server that is no longer 
running doesn't tell me much either.  How is gdb going to help me figure 
out why something isn't working any more?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=960200504-09032011><FONT face=Arial 
color=#0000ff size=2>--J</FONT></SPAN></DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> 
  freeradius-users-bounces+mcnuttj=missouri.edu@lists.freeradius.org 
  [mailto:freeradius-users-bounces+mcnuttj=missouri.edu@lists.freeradius.org] 
  <B>On Behalf Of </B>Gary Gatten<BR><B>Sent:</B> Tuesday, March 08, 2011 5:06 
  PM<BR><B>To:</B> 'freeradius-users@lists.freeradius.org'<BR><B>Subject:</B> 
  Re: FR 2.1.7 Exits for no reason<BR></FONT><BR></DIV>
  <DIV></DIV><FONT 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Gdb</FONT><BR> <BR>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none"><FONT 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"><B>From</B>: 
  McNutt, Justin M. [mailto:McNuttJ@missouri.edu] <BR><B>Sent</B>: Tuesday, 
  March 08, 2011 04:59 PM<BR><B>To</B>: freeradius-users@lists.freeradius.org 
  <freeradius-users@lists.freeradius.org> <BR><B>Subject</B>: FR 2.1.7 
  Exits for no reason <BR></FONT> <BR></DIV><FONT face="Arial, sans-serif" 
  size=2>
  <DIV>Hey all,</DIV>
  <DIV> </DIV>
  <DIV>So the host-based auth stuff is working well now, but we've discovered 
  another problem.</DIV>
  <DIV> </DIV>
  <DIV>We have four FR 2.1.7 servers running on RHEL 5 (fully patched).  
  Every now and then, for no apparent reason, radiusd just stops.  It exits 
  with "Exiting normally." to syslog.  They don't all exit at the same 
  time.  Since there are four of them behind a load balancer, it usually 
  doesn't result in a service outage, and we've been lucky so far that only a 
  couple of them have been down at once.  But it's still 
  disconcerting.</DIV>
  <DIV> </DIV>
  <DIV>The servers tend to all be <I>started</I> within a minute of each other, 
  since I make changes to Server #1, and then use an rsync script to replicate 
  /etc/raddb to the other servers and restart them.  So they all start 
  within seconds of one another.  This week, Server #3 stopped within about 
  8 hours of being started (went from 1130 to 1930).  Server #1 failed last 
  week at 2330.  Server #4 hasn't failed yet.  It's very odd.</DIV>
  <DIV> </DIV>
  <DIV>Any ideas on how I can troubleshoot this?</DIV>
  <DIV> </DIV>
  <DIV><FONT face="Arial, sans-serif">Thanks!</FONT></DIV>
  <DIV><FONT face="Arial, sans-serif"></FONT> </DIV>
  <DIV><FONT face="Arial, sans-serif">Justin McNutt</FONT></DIV>
  <DIV><FONT face="Arial, sans-serif">Network Systems Analyst - 
  Ninja</FONT></DIV>
  <DIV><FONT face="Arial, sans-serif">DNPS, Mizzou Telecom</FONT></DIV>
  <DIV><FONT face="Arial, sans-serif">(573) 882-5183</FONT></DIV>
  <DIV><FONT face="Arial, sans-serif"></FONT> </DIV>
  <DIV><FONT face="Arial, sans-serif">"Do you have a concussion?"</FONT></DIV>
  <DIV><FONT face="Arial, sans-serif"></FONT> </DIV>
  <DIV><FONT face="Arial, sans-serif">Ping is NOT a service.  You don't 
  need it.  Use a real test.</FONT></DIV>
  <DIV><FONT face="Arial, sans-serif"></FONT> </DIV>
  <DIV> </DIV></FONT><FONT size=1>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 1pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: windowtext 2.25pt double"></DIV>"This 
  email is intended to be reviewed by only the intended recipient and may 
  contain information that is privileged and/or confidential. If you are not the 
  intended recipient, you are hereby notified that any review, use, 
  dissemination, disclosure or copying of this email and its attachments, if 
  any, is strictly prohibited. If you have received this email in error, please 
  immediately notify the sender by return email and delete this email from your 
  system." </FONT></BLOCKQUOTE></BODY></HTML>