On 15-04-23 05:56 PM, Ole Tange wrote:
On Mon, Apr 20, 2015 at 4:31 PM, Martin d'Anjou
<martin.danjo...@gmail.com> <mailto:martin.danjo...@gmail.com> wrote:
Here is an implementation of how the user can specify an alternate
termination sequence:
https://github.com/martinda/gnu-parallel/compare/optional-termination-sequence?expand=1
Your input is welcome.
Let us say you do not know that 9 = KILL (it took me several UNIX
years before I learned that), but you want to send kill -9.
How should that be expressed in --termseq?
Good question. I'd be surprised if a user attempted to use --term-seq
without looking it up. So the --term-seq documentation (all of it,
tutorial included) should be clear that it uses signal names, not
numerical values. The documentation should point out the mapping between
signal names and their numerical value at least for a few common signals
(INT=2, TERM=15, KILL=9), then refer the user to their OS (unix: kill
-l, trap -l, Windows: ?).
Do I want to send the signal to the process group or just the process
To me it makes sense to first terminate the parent process and let it
terminate its own children, as it is a valid way of writing programs
(see http://mywiki.wooledge.org/SignalTrap).
If processes remain after the first pass, reapply the termination
sequence to the process group.
(and will that make any difference in real life situations)?
Say the process tree is: GNU parallel -> parent -> child
Killing the process tree is not an atomic operation, so race conditions
could cause spurious errors in the parent (parent tries to kill a
non-existent child process), or in GNU parallel (parent kills the child,
then GNU parallel kills the child again after the child is gone). There
could be other race conditions, I am not seeing them at the moment.
In my case, avoiding spurious errors caused by race conditions helps
identify real problems. When every log file contains spurious errors, it
gets harder to root cause problems.
Martin
