Re: What signal should timeout send when it gets a SIGTERM?

[Jim Meyering]

Pádraig Brady wrote:
> On 16/03/10 07:10, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> address@hidden --kill-delay
>>
>> The long option name makes it sound like this
>> is merely specifying the delay, when in fact it is
>> enabling new behavior as well.  Did you consider say,
>> "--kill-after=DELAY" ?
>>
>> Whatever its name, saying what happens *without* the option
>> might clarify:
>>
>>     Without this option, if the selected signal proves not to be fatal,
>>     @command{timeout} does not kill the @var{command}.
>
> That's better. I'll push the attached patch today sometime.
>
>>> +          alarm(kill_delay);
>>
>> We need one of those pesky space-before paren things ;-)
>> There's also one missing on a sigemptyset use.
>
> Grr :)
>
> There are a few of those:
> for c in *.c;
>   do echo "*******$c*******"
>   cpp -fpreprocessed $c 2>/dev/null | grep '[a-zA-Z0-9]('
> done

Good catches.  That sounds like a good syntax-check addition,
as long as cpp -fpreprocessed works.

> *******copy.c*******
> *******dd.c*******
> *******join.c*******
> *******pwd.c*******
> *******sort.c*******
> *******uptime.c*******
...

> Subject: [PATCH] timeout: add the --kill-after option

Thanks for the quick adjustments.
Please change --kill-delay to --kill-after also in NEWS:

> Based on a report from Kim Hansen who wanted to
> send a KILL signal to the monitored command
> when `timeout` itself received a termination signal.
...
> diff --git a/NEWS b/NEWS
...
> +  timeout now accepts the --kill-delay option which sends a kill
> +  signal to the monitored command if it's still running the specified
> +  duration after the initial signal was sent.