forking a perl process from modperl to execute a network program

[Gac Corp <ga...@yahoo.com>]

Hi Folks:

I have perl program that runs under modperl in a
website, that needs to fork another perl program that
executes a network program. The problem is that the
tcp socket c program runs fine when executed from
a modperl fork, but udp socket dies. This udp program 
runs fine when run from the console. I don't think it
has anything to do with user permission. I have used 
rootto run the UDP socket and it still fails. 
The program also uses raw socket . Is there a way to
close all the socket handles and environment inherited
from the modperl.

Sample codes and ideas welcome.

Oliver

__________________________________________________
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/

Re: forking a perl process from modperl to execute a network program

[Barrie Slaymaker <ba...@slaysys.com>]

Gac Corp wrote:
> but udp socket dies.

Does it open the socket ok?   How long until it dies?  Is it forking again in the
C program (perhaps to daemonize)?  If you want to instrument your code to see when
the filehandle goes away, here's some sample Perl code I use for debugging IPC::Run
that you could port to C if it would help (it's invaluable):

sub _map_fds {
   my $map = '' ;
   my $digit = 0 ;
   my $in_use ;
   for my $fd (0..63) {
      ## I'd like a quicker way (less user, cpu & expecially sys and kernal
      ## calls) to detect open file descriptors.  Let me know...
      my $test_fd = POSIX::dup( $fd ) ;
      $in_use = defined $test_fd ;
      POSIX::close $test_fd if $in_use ;
      $map .= $in_use ? $digit : '-';
      $digit = 0 if ++$digit > 9 ;
   }
   warn "No fds open???" unless $map =~ /1/ ;
   $map =~ s/(.{1,12})-*$/$1/ ;
   return $map ;
}

You could use a couple of fdopen()s instead of the dup() if you care about r/w.

To rule out parent process interaction, you might sleep()ing just after the fork()
in the parent to see if the child's socket lasts longer, but I can't see how the
parent process doesn't interfere with the tcp child when it does with the udp.

Is the udp child process fully separating from the controlling terminal?

- Barrie