FreeRadius 2.1.8 works fine in DEBUG mode
Hi, I am using freeradius version 2.1.8. All the installation and everything went fine. Freeradius is able to accept and process the request in DEBUG mode. But in in normal mode, I am getting the following error. Mon Feb 8 17:29:20 2010 : Info: Ready to process requests. Mon Feb 8 17:29:59 2010 : Error: WARNING: Unresponsive child for request 0, in module python component authorize Mon Feb 8 17:30:00 2010 : Info: WARNING: Child is hung for request 0. Mon Feb 8 17:30:00 2010 : Info: WARNING: Child is hung for request 0. Mon Feb 8 17:30:01 2010 : Info: WARNING: Child is hung for request 0. Mon Feb 8 17:30:01 2010 : Info: WARNING: Child is hung for request 0. Mon Feb 8 17:30:03 2010 : Info: WARNING: Child is hung for request 0. Please let me know how I can solve this ? Thanks Amal
Amal Janardhanan wrote:
But in in normal mode, I am getting the following error.
Mon Feb 8 17:29:20 2010 : Info: Ready to process requests. Mon Feb 8 17:29:59 2010 : Error: WARNING: Unresponsive child for request 0, in module python component authorize Mon Feb 8 17:30:00 2010 : Info: WARNING: Child is hung for request 0.
Your python script is hanging. You can run daemon mode PLUS debugging. See "man radiusd": radiusd -fxx -l stdout Alan DeKok.
But the same script is running in DEBUG mode.. Also if I user freeradius-server-2.0.5, the script works in debug as well as daemon mode. Radius Server : freeradius-server-2.1.8 Server ProductName: Mac OS X Server Server ProductVersion: 10.5.8 Server BuildVersion: 9L34 If radius version is 2.0.5, it works fine. Thanks Amal On Feb 8, 2010, at 6:40 PM, Alan DeKok wrote:
Amal Janardhanan wrote:
But in in normal mode, I am getting the following error.
Mon Feb 8 17:29:20 2010 : Info: Ready to process requests. Mon Feb 8 17:29:59 2010 : Error: WARNING: Unresponsive child for request 0, in module python component authorize Mon Feb 8 17:30:00 2010 : Info: WARNING: Child is hung for request 0.
Your python script is hanging.
You can run daemon mode PLUS debugging. See "man radiusd":
radiusd -fxx -l stdout
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Amal Janardhanan wrote:
But the same script is running in DEBUG mode..
Also if I user freeradius-server-2.0.5, the script works in debug as well as daemon mode.
Radius Server : freeradius-server-2.1.8 Server ProductName: Mac OS X Server Server ProductVersion: 10.5.8 Server BuildVersion: 9L34
If radius version is 2.0.5, it works fine.
You've said that about 4 times now. Are you prepared to SOLVE the problem by following my instructions? Alan DeKok.
Hi , I tried debugging by radiusd -fxx -l stdout. But no information is printed in the window nor in any of the file. I tried various radius version from 2.1.1 to 2.1.8. Same result everywhere. Only 2.0.5 is working. Thanks Amal On Feb 9, 2010, at 1:29 PM, Alan DeKok wrote:
Amal Janardhanan wrote:
But the same script is running in DEBUG mode..
Also if I user freeradius-server-2.0.5, the script works in debug as well as daemon mode.
Radius Server : freeradius-server-2.1.8 Server ProductName: Mac OS X Server Server ProductVersion: 10.5.8 Server BuildVersion: 9L34
If radius version is 2.0.5, it works fine.
You've said that about 4 times now.
Are you prepared to SOLVE the problem by following my instructions?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Amal Janardhanan wrote:
I tried debugging by radiusd -fxx -l stdout.
But no information is printed in the window nor in any of the file.
I tried various radius version from 2.1.1 to 2.1.8. Same result everywhere.
Those command line options should cause it to print it's starting messages to the terminal. Since nothing is being printed, it's not even starting. My *guess* is that either you do not have permission to run the radiusd binary, *or* there is some "security" policy on your system that prevents it from running a newer version of FreeRADIUS. i.e. go find out why your system won't let you run executables. This isn't a freeradius problem. Alan DeKok.
If I don't include in import statement from python it works well. Just any import like import socket, it fails... A plain Python code works. Here is the thread sample. Sampling process 88764 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling radiusd (pid 88764) every 1 millisecond Call graph: 2378 Thread_2507 2378 start 2378 main 2378 radius_event_process 2378 select$DARWIN_EXTSN 2378 select$DARWIN_EXTSN 2378 Thread_2603 2378 thread_start 2378 _pthread_start 2378 request_handler_thread 2378 radius_handle_request 2378 rad_authenticate 2378 module_authorize 2378 indexed_modcall 2378 modcall 2378 python_function 2378 PyGILState_Ensure 2378 PyEval_RestoreThread 2378 PyThread_acquire_lock 2378 pthread_cond_wait$UNIX2003 2378 __semwait_signal 2378 __semwait_signal Total number in stack (recursive counted multiple, when >=5): Sort by top of stack, same collapsed (when >= 5): __semwait_signal 2378 select$DARWIN_EXTSN 2378 Sample analysis of process 88764 written to file /dev/stdout On Feb 11, 2010, at 1:04 AM, Alan DeKok wrote:
Amal Janardhanan wrote:
I tried debugging by radiusd -fxx -l stdout.
But no information is printed in the window nor in any of the file.
I tried various radius version from 2.1.1 to 2.1.8. Same result everywhere.
Those command line options should cause it to print it's starting messages to the terminal. Since nothing is being printed, it's not even starting.
My *guess* is that either you do not have permission to run the radiusd binary, *or* there is some "security" policy on your system that prevents it from running a newer version of FreeRADIUS.
i.e. go find out why your system won't let you run executables. This isn't a freeradius problem.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 02/11/2010 07:39 PM, Amal Janardhanan wrote:
If I don't include in import statement from python it works well.
You've got a pretty good clue then. This isn't a freeradius problem. Go figure out why python import statements are your problem. Some things to check are what is your PYTHONPATH when the script runs. Is anything pointed to by the path list NFS mounted or have permissions not available to the user radiusd runs under (most likely the radius or radiusd user)? Are you running on a SELinux enabled system? If so examine your /var/log/audit/audit.log to see if SELinux is denying access for some reason. Try running your script as the user:group radius runs as (look in your radiusd.conf file and find the user and group configuration variables). Do your scripts run in that environment? As Alan said earlier:
i.e. go find out why your system won't let you run executables. This isn't a freeradius problem.
-- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Tue, Feb 09, 2010 at 01:17:02PM -0800, Amal Janardhanan wrote:
But the same script is running in DEBUG mode..
Also if I user freeradius-server-2.0.5, the script works in debug as well as daemon mode.
Radius Server : freeradius-server-2.1.8 Server ProductName: Mac OS X Server Server ProductVersion: 10.5.8 Server BuildVersion: 9L34
If radius version is 2.0.5, it works fine.
First: Follow Alan DeKok's debugging instructions exactly. He knows what he is doing. My personal guessing: I would expect that in "DEBUG mode" the script is being run with root permissions and/or environment variables from your shell, such as PATH. Check what permissions are required by the script. Check that the script does not make assumptions about things in the environment; fully specify the path to any needed sub-scripts/binaries. It may be that your 2.0.5 install was running as root and your 2.1.8 install is now running as a "freeradius" user, whatever that user might happen to be named. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org
participants (4)
-
Alan DeKok -
Amal Janardhanan -
John Dennis -
Scott Lambert