| Age | Commit message (Collapse) | Author |
|---|
|
" &" was to avoid throwing an exception when the child process has a
non-empty exitcode. However, the error-throwing function is callCommand
and not spawnCommand, so removing " &" shouldn't change the semantic.
https://codeberg.org/xmobar/xmobar/pulls/698#issuecomment-1722323
> callCommand seems to be the closest new function to system, but there
> is a difference: it raises an exception if the child process has a
> non-zero exit code. To preserve the exact behavior would require
> something like spawnCommand (s + "&") >>= waitForProcess.
I was able to reproduce zombie processes with the following steps:
+ running my own xmobar configuration
+ spawning a command that is long running (sleep 10)
+ sending SIGTERM to the xmobar process
After doing so, the sleep command will continue to run.
This PR uses withCreateProcess, which will always wait for the process
to terminate, even when the main thread is asked to exit (SIGTERM).
Note that SIGKILL is not expected to terminate the children.
|
|
This effectively reverts c54d93e and 991a168. While those fix #687 and
#688 respectively in the case where the configuration is recompiled, in
all other cases they leave zombie processes, since they undo the fix for
#181.
However, instead of reverting to the deprecated system function, we use
the newer spawnCommand and waitForProcess. And like with 991a168, the
low battery action now runs in the background to avoid blocking the bar.
|
|
This should address the problems reported in issue #688
|
|
|
|
|
