On Dec 3, 2003, at 10:49 AM, Akens, Anthony wrote: [..]
print "Running vmstat\n";
defined(my $vmstat_pid = fork) or die "Cannot fork: $!";
unless ($vmstat_pid) {
exec "vmstat 5 5 > /log/monitor/delta/vmstat.out";
die "cannot exec vmstat: $!";
}
print "Running sar\n";
defined(my $sar_pid = fork) or die "Cannot fork: $!";
unless ($sar_pid) {
exec "sar 5 5 > /log/monitor/delta/sar.out";
die "cannot exec date: $!";
}
print "Waiting...\n";
waitpid($vmstat_pid, 0);
waitpid($sar_pid, 0);
print "done!\n";
I presume you are working on a solaris box? have you thought about
timex sar 5 5
timex vmstat 5 5and you will notice that the sar command will take about 25 seconds and the vmstat about 20.
but then there is that minor nit about
exec "vmstat 5 5 > /log/monitor/delta/vmstat.out"
or die "cannot exec vmstat: $!";since in theory exec WILL not return, so if it failed why not keep it in the proper context...
Then there is that Minor Nit about not controlling 'stderr' which can lead to things like:
vladimir: 60:] ./st*.plx Running vmstat Running sar sh: /log/monitor/delta/vmstat.out: cannot create sh: /log/monitor/delta/sar.out: cannot create Waiting... done! vladimir: 61:]
So while you are in the process of learning fork() and exec() why not think a bit more agressively and go with say a pipe to pass back the information.... so as not to buy the IO overhead of writing to files?
While the following was written for a command line 'let us get interactive' type of solution, it might be a framework you could rip off and use:
<http://www.wetware.com/drieux/pbl/Sys/gen_sym_big_dog.txt>
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
