Excellent observation, but as I continue troubleshooting today, I think the problem is actually the opposite. I'm having script problems because the external process is being killed! I have never used fork before, but it seems that what is happening here is that when the external program dies, that child process stays alive and becomes in effect a new copy of my infinite-loop script. I ran for an hour this morning on a pingable IP, no problems. When I switch to a non-pingable IP (while keeping the script running) I suddenly see two log entries changing the .ini file... I switch back, and there are 4.... So everytime I kill the running .exe, I double my number of running perl scripts? Wow. I "fixed" this by adding a "die" command immediately after the "system" command (to get the child to die) but this has a nasty effect of getting "SPOOLSV.EXE" to suck up 99% of my CPU. So I'm guessing there's a better way to kill my children. I need to find out how.
-- Believe nothing, no matter where you read it, or who said it - even if I have said it - unless it agrees with your own reason and your own common sense.
(Buddha)
| [reply] |
See my reply below. It definitely sounds like you're using system() (which returns) instead of exec() (which doesn't). Keep in mind that fork creates two identical processes, both running your perl script. Unless you want two copies of your script running, one of processes running your script must be overwritten using exec().
If the application you want to kill is started by your script, you might want to look into using Win32::Process module insted of fork. When you create an object, it returns an object with a ->kill() method.
| [reply] |