Re: Alternate termination sequence option --term-seq

[Martin d'Anjou]

On 15-04-23 05:56 PM, Ole Tange wrote:

On Mon, Apr 20, 2015 at 4:31 PM, Martin d'Anjou
<martin.danjou14@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