Greetings, I have FreeRadius 1.1.0 working on Debian 3.1 on an Intel box. When using rlm_perl, the authenticate() sub does its job and, eventually, calls a method to send an email to a certain address before returning OK. The problem is that this SMTP connection can take longer than wished, therefore I am forking the SMTP call, so the authentication process can go on as normal. The problem with this solution, though, is that--as I cannot wait for the SMTP connection to be done--the process is left as a zombie. I have, therefore, used a double forking solution, where the grandfather returns inmediately to the authorize() function, and the child forks again, and waits (waitpid()) for the new (grand)child to do the job, so no zombie is created. By itself, this works and no zombies are left behind, as expected. However, when used with FreeRadius, zombies are left behind. I have tried to 'IGNORE' SIGCHLD, to use reaper function (and all the other tricks in perlipc(1)) to no avail (I am even using Proc::Fork to simplify things so I am sure I am doing things properly). Is this a problem with my calling this inside the authenticate() function, or with rlm_perl, or...? Is this a problem with 1.1.0 and solved with a later version? Any help appreciated. thanks a lot! david PS- Perl is version 5.8.4 compiled with threads and ithreads PPS- has the RLM_PERL module documentation's been improved in more recent versions, by any chance? ___________________________________________________________________________ Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. El correo electrónico vía Internet no permite asegurar la confidencialidad de los mensajes que se transmiten ni su integridad o correcta recepción. Telefónica no asume ninguna responsabilidad por estas circunstancias. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by a professional privilege or whose disclosure is prohibited by law.If you are not the intended recipient you are hereby notified that any read, dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. Internet e-mail neither guarantees the confidentiality nor the integrity or proper receipt of the messages sent. Telefónica does not assume any liability for those circumstances. ___________________________________________________________________________
On Thu, Jun 15, 2006 at 05:42:45PM +0200, david.suarezdelis@telefonica.es said:
Greetings,
I have FreeRadius 1.1.0 working on Debian 3.1 on an Intel box.
When using rlm_perl, the authenticate() sub does its job and, eventually, calls a method to send an email to a certain address before returning OK.
The problem is that this SMTP connection can take longer than wished, therefore I am forking the SMTP call, so the authentication process can go on as normal.
The problem with this solution, though, is that--as I cannot wait for the SMTP connection to be done--the process is left as a zombie. I have, therefore, used a double forking solution, where the grandfather returns inmediately to the authorize() function, and the child forks again, and waits (waitpid()) for the new (grand)child to do the job, so no zombie is created.
By itself, this works and no zombies are left behind, as expected. However, when used with FreeRadius, zombies are left behind. I have tried to 'IGNORE' SIGCHLD, to use reaper function (and all the other tricks in perlipc(1)) to no avail (I am even using Proc::Fork to simplify things so I am sure I am doing things properly).
Is this a problem with my calling this inside the authenticate() function, or with rlm_perl, or...? Is this a problem with 1.1.0 and solved with a later version?
I can't tell you without seeing the script, but the way I would handle this (if I understand correctly) would be two fold. First, set up a signal handler for SIGCHLD that is a callback to a subroutine that calls waitpid(). Then, at the end of your script, if you haven't received SIGCHLD, and you're about to exit, jump to the routine that handles SIGCHLD. Then go back to just using a single fork. You could presumably track whether you're even supposed to have a child out there with a variable, so as to skip the jump at the end if you've already reaped your child process. My advice herre may be wrong, of course - I do not use rlm_perl, but I do use perl fairly regularly. -- -------------------------------------------------------------------------- | Stephen Gran | God is dead and I don't feel all too | | steve@lobefin.net | well either.... -- Ralph Moonen | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
david.suarezdelis@telefonica.es wrote:
By itself, this works and no zombies are left behind, as expected. However, when used with FreeRadius, zombies are left behind.
FreeRADIUS has a wrapper around fork() that modules are expected to use. The reason is that the server is threaded, and some modules want to wait for the child to return. In a threaded environment, the SIGCHLD may be delivered to *another* thread, which causes problems. Hence the wrapper, which catches all of the SIGCHLD's, and ensures they're delivered to the correct destination. In your case, you're not calling the wrapper, so it never waits for that PID, and thus the zombie. A solution is to modify src/main/threads.c, function reap_children(). Right now it loops over known PIDs, and waits on them. Change it to wait for any PID, and then look that PID up in the list. If it's known, it's updated. Otherwise, the status is tossed. That should get rid of the zombies. If you can send a patch soon, it can make it into the next version of the server. Alan DeKok.
participants (3)
-
Alan DeKok -
david.suarezdelis＠telefonica.es -
Stephen Gran