Bug 602567

Summary: Current version does not generate core dumps
Product: Red Hat Enterprise Linux 5 Reporter: Mindaugas Riauba <mindaugas>
Component: freeradius2Assignee: John Dennis <jdennis>
Status: CLOSED ERRATA QA Contact: Aleš Mareček <amarecek>
Severity: medium Docs Contact:
Priority: high    
Version: 5.5CC: amarecek, dpal, ksrot
Target Milestone: rcKeywords: Rebase
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of:
: 609633 (view as bug list) Environment:
Last Closed: 2012-02-21 00:36:04 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 609633, 644100, 736878    
Description Flags
test script
test script none

Description Mindaugas Riauba 2010-06-10 04:07:26 EDT
Description of problem:
Current version of freeradius2 does not produce core dump file on segfault.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set "allow_core_dumps = yes" in radiusd.conf
2. Comment out "user = radiusd" and "group = radiusd"
3. ulimit -c 1000000000
Actual results:
No core dumps are generated on segfault

Expected results:
core dump file

Additional info:
This is bug in upstream version. In 2.1.8 it is fixed. Line in changelog:
* Enabled "allow_core_dumps" to work again
Comment 1 John Horne 2010-06-11 08:41:02 EDT
I don't have the exact same problem, but do have a serious problem with Freeradius2, which too is fixed in 2.1.8. The current release of RedHat freeradius needs to be upgraded.

Problem and response from Freeradius developer:

  > We are running Freeradius 2.1.7 (on CentOS 5 - freeradius2-2.1.7-7.el5),
  > and are seeing many of these messages in our log files:
  >   Fri Jun 11 11:44:19 2010 : Error: Failed binding to proxy address *
  >   port 1815: Address already in use
  > The server is already running and so would already be bound to the port,
  > so why is it trying to bind to it again? These seem to occur initially
  > in ones or twos, but eventually the server stops responding completely
  > to requests. At that point we have to restart the radiusd process.
  > Is this known about and maybe fixed in 2.1.9? Or is something else going
  > on here?

  Changelog from 2.1.8:

        * Proxying large numbers of packets no longer gives error
          "unable to open proxy socket".

This is from the freeradius user s mailing list, Subject line "FR 2.1.7: Error: Failed binding to proxy address". This problem is seriously affecting our RADIUS service, so needs to be sorted out soon.

Comment 4 Dmitri Pal 2010-06-30 13:45:11 EDT
Let us track the original issue here. I have forked a separate bug for the issue described in comment #1.

Comment 5 Dmitri Pal 2010-06-30 13:47:05 EDT
We are not planning to rebase the freeradius2 package in 5.6 release.

If you need this specific fix please log a case with customer support and we will try to extract and back port the solution for it. In this case it will be delivered as an errata.
Comment 8 John Dennis 2011-09-07 19:52:32 EDT
This has been fixed in the current upstream version. Since we are planning on rebasing freeradius2 to the current version in RHEL 5.8 we should automatically pick up the fix in the rebase.

This is the git commit to the upstream git repo which addressed this problem:


commit 2967714b702ba960cb716fac8e27551a12fe9d45
Author: Alan T. DeKok <aland@freeradius.org>
Date:   Tue May 4 14:36:42 2010 +0200

    Enable core dumps after suid_down

A full discussion of the issue and it's resolution can be found here:

Comment 11 Aleš Mareček 2011-12-07 03:51:42 EST
Created attachment 541765 [details]
test script
Comment 15 Aleš Mareček 2011-12-07 08:14:16 EST
Created attachment 541950 [details]
test script
Comment 17 errata-xmlrpc 2012-02-21 00:36:04 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.