Re^7: old file descriptors not being cleaned up

Thanks for the reply. I changed the spawn code to a list but it didn't make any difference.

my @cmd = split " ", "$pingcmd $hosts[$i] $pingsize $pingnumber";
$pid = open $pings[$i][1], "-|", @cmd or 
  die "Error executing $cmd[0]: $!\n";;
[download]

I also tried this as a list and a string but it made no difference either. "$pingcmd $hosts[$i] $pingsize $pingnumber 2>/dev/null </dev/null"

The reason I'm not using Net::Ping is that u have to be root to make ICMP echo requests. Net::Ping::External just does the same thing I'm doing now. I also need to ping lots of hosts at once.

Comment on Re^7: old file descriptors not being cleaned up Select or Download Code

Replies are listed 'Best First'.
Re^8: old file descriptors not being cleaned up by mr_mischief (Monsignor) on Dec 18, 2010 at 10:35 UTC
Well, the redirection would have to be done using the shell, so making that a list wouldn't help anything. I am wondering if using kill to send a SIGTERM signal to the spawned program instead of just closing the pipe may help. It shouldn't be necessary, but it does seem you're suffering from something odd Solaris is doing with the files of the spawned program. Perhaps sending a signal (other than SIGKILL or something that can't be handled, preferably SIGTERM as already mentioned) would get the spawned program to close its own open files as it should. I see the draw of using an external suid program that is already developed and maintained by someone else rather than developing your program to run partially as root. I might make a different decision, but I certainly won't argue with yours. So back to trying to fix the problems with your version we go. You mention Net::Ping::External, which I hadn't thought about. It does do basically what your program does, but it uses the specific redirections `1>$devnull 2>$devnull` as part of its command call. It does this in this particular way regardless of system, actually. The redirections are stated the same way, and although the location of the null device is left as a variable it is one with the '/dev/null' value assigned just the line before. I have no idea whether that will help, but it's a simple enough change to try. One thing that has occurred to me is that in your example code as posted I didn't notice you doing anything with the data read from the pipe. Are you actually using the read data? If not, `system` would be a cleaner solution than the piped `open`. You'd still have the status returned by ping.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^8: old file descriptors not being cleaned up
by mr_mischief (Monsignor) on Dec 18, 2010 at 10:35 UTC

Well, the redirection would have to be done using the shell, so making that a list wouldn't help anything.

I am wondering if using kill to send a SIGTERM signal to the spawned program instead of just closing the pipe may help. It shouldn't be necessary, but it does seem you're suffering from something odd Solaris is doing with the files of the spawned program. Perhaps sending a signal (other than SIGKILL or something that can't be handled, preferably SIGTERM as already mentioned) would get the spawned program to close its own open files as it should.

I see the draw of using an external suid program that is already developed and maintained by someone else rather than developing your program to run partially as root. I might make a different decision, but I certainly won't argue with yours. So back to trying to fix the problems with your version we go.

You mention Net::Ping::External, which I hadn't thought about. It does do basically what your program does, but it uses the specific redirections 1>$devnull 2>$devnull as part of its command call. It does this in this particular way regardless of system, actually. The redirections are stated the same way, and although the location of the null device is left as a variable it is one with the '/dev/null' value assigned just the line before. I have no idea whether that will help, but it's a simple enough change to try.

One thing that has occurred to me is that in your example code as posted I didn't notice you doing anything with the data read from the pipe. Are you actually using the read data? If not, system would be a cleaner solution than the piped open. You'd still have the status returned by ping.

[reply]
[d/l]
[select]