Dear brothers,
I have a script run by FreeRadius (using their Apache-like perl_mod system, called rlm_perl) that executes a function when an Access-Request RADIUS packet is received.
The function determines if the authentication is correct or not, and returns the approriate response to the daemon. It must also send a notification. I have these implemented as e-mail messages (using Mail::Sendmail), but I cannot wait for the email to be sent (network delays, etc...).
The problem is that when I fork the notification, I cannot wait() for it: if I allow it to end, it will return a reply of its own to the FreeRadius, which is translated in more than one reply packet to the client; if I exit the child, it remains as a zombie freeradius process until the server is reinit...
I have tried to implement this setup with Proc::Fork, vanilla fork() and even threads (although these cannot work, because the function is executed in a kind of CGI fashion), but I always get these problems...
So, can anyone tell me if it's possible to fork the notification so it doesn't let zombies behind, and does not forces me to wait for it to be done?
As a last resort, I will have to take the notification to a different process that is watching a log file or something, but that complicates things a bit, and it's yet another process to dogwatch...
Thanks!
PS- updated: I have tested it with $SIG{CHLD} = 'IGNORE'; and am playing with all the different possibilities of perlipc(1), but it's a bit discouraging... Thanks!
--
our $Perl6 is Fantastic;
In reply to Zombie-less forking inside a daemon? by Excalibor
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |