Re: System call + signals = bad return code?

[bluto]

system() is a convenience wrapper around fork/exec. Don't expect to use signals with it and have things work well. The classic example of this kind of failure is when someone uses alarm with system: The ALRM occurs, the parent then continues, but the child doesn't receive the ALARM and keeps running (on some platforms at least). I've seen similar cases where system returns an invalid result if I've already forked off an unrelated process and it happens to die when system() is executing.

If you want to trap signals, it's better to do this yourself For example, fork/exec the child and have the parent call waitpid. If the waitpid is interrupted by the alarm, have the parent explicitly kill the child. An alternative is not to use alarm at all, but just to call waitpid about once a second. When the time is up just kill the child process. Update: Clarified a little

[swkronenfeld]

I think I'm being unclear in my original post. I don't want the child to receive the signal, nor am I using this alarm as a timeout to make sure the system call doesn't hang.

In the real code, a connection to MySQL is established via the DBI module. Then a wget command is issued that takes a long time. During that time, the database connection times out, and must send a signal to the parent. This causes $? and $! to be set. But in addition to those, the system('wget') call returns -1. I know the wget succeeds, because the file is completely downloaded. But since system() returns -1, it looks like the wget failed!

[bluto]

I was confused by your example. Sorry. This statement though still holds: I've seen similar cases where system returns an invalid result if I've already forked off an unrelated process and it happens to die when system() is executing. (i.e. in addition to signals, process reaping is problematic). You may want to try replacing system() with fork/exec/waitpid. The waitpid will return the status for the child pid you pass to it.