Strange exit status behavior from the process package
I've run into some strangeness with the process package. When you kill some processes on the command line you correctly get a non-zero exit status. However when using the process package's terminateProcess (which sends a SIGTERM), it returns an ExitSuccess: module Main (main) where import Control.Concurrent (threadDelay) import System.Process (createProcess, proc, getProcessExitCode, terminateProcess) main :: IO () main = do (_, _, _, ph) <- createProcess $ proc "/usr/bin/sleep" ["100"] terminateProcess ph threadDelay 1000000 print =<< getProcessExitCode ph -- prints Just ExitSuccess, should be Just (ExitFailure 143) term1: sleep 100 term2: pkill sleep term1: echo $? # 143 Anyone know what might be going on? -- Michael Xavier http://www.michaelxavier.net
On Sat, Sep 21, 2013 at 11:12 PM, Michael Xavier
I've run into some strangeness with the process package. When you kill some processes on the command line you correctly get a non-zero exit status. However when using the process package's terminateProcess (which sends a SIGTERM), it returns an ExitSuccess:
The 143 you get from the shell is synthetic (and nonportable). Signals are not normal exit codes; WEXITSTATUS is not defined in this case (but often will be 0, as seems to be shown here), instead WTERMSIG will be set to the signal that terminated the process. The caller should be using WIFEXITED / WIFSIGNALED / WIFSTOPPED to determine the cause of the termination and then the appropriate WEXITSTATUS / WTERMSIG / WSTOPSIG call to determine the value. It sounds like the createProcess API does not recognize signal exit at all, and uses WEXITSTATUS even when it is not valid. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Could I trouble you or anyone else to help me implement this feature? I
have some test processes, one that exits cleanly on sigterm and one that
refuses and must be killed abruptly. In some experimentation on GHCi,
things seem to go alright, but in test, either process reports that it has
terminated with 15, which is incorrect.
Test code:
https://github.com/MichaelXavier/Angel/blob/sigkill/test/Angel/JobSpec.hs#L3...
Relevant implementation code:
https://github.com/MichaelXavier/Angel/blob/sigkill/src/Angel/Job.hs#L161
https://github.com/MichaelXavier/Angel/blob/sigkill/src/Angel/Process.hs#L40
I've spent quite a bit of time trying different solutions to this and have
failed to get the tests to pass.
On Sat, Sep 21, 2013 at 9:24 PM, Brandon Allbery
On Sat, Sep 21, 2013 at 11:12 PM, Michael Xavier < michael@michaelxavier.net> wrote:
I've run into some strangeness with the process package. When you kill some processes on the command line you correctly get a non-zero exit status. However when using the process package's terminateProcess (which sends a SIGTERM), it returns an ExitSuccess:
The 143 you get from the shell is synthetic (and nonportable). Signals are not normal exit codes; WEXITSTATUS is not defined in this case (but often will be 0, as seems to be shown here), instead WTERMSIG will be set to the signal that terminated the process. The caller should be using WIFEXITED / WIFSIGNALED / WIFSTOPPED to determine the cause of the termination and then the appropriate WEXITSTATUS / WTERMSIG / WSTOPSIG call to determine the value.
It sounds like the createProcess API does not recognize signal exit at all, and uses WEXITSTATUS even when it is not valid.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-- Michael Xavier http://www.michaelxavier.net
participants (2)
-
Brandon Allbery -
Michael Xavier