2010/3/8 Pádraig Brady <p...@draigbrady.com>:
> On 08/03/10 07:17, Jim Meyering wrote:
>>
>> Pádraig Brady wrote:
>>>
>>> Perhaps we could handle all cases with
>>> the equivalent of:
>>>
>>> if (sig==TERM&& user_sig==KILL) {
>>> send(sig); /* give chance to term gracefully */
>>> sleep(1);
>>> send(KILL); /* nuke it from orbit */
>>> }
>>
>> If the child program's signal-triggered clean-up code takes more than that
>> one second, kill-9 would probably leave things in an inconsistent state.
>
> Yes, that's true, and I'd be against doing the above
> as it could cause intermittent weird behavior.
>
> An alternative would be to add a new --kill-wait option
> which could be used to specify an additional timeout before a SIGKILL was
> sent.
> That would be a general mechanism to terminate "normally" after the timeout
> or when SIGTERM etc. is sent, but then always setup another timeout
> to send SIGKILL if the monitored command does not exit.
An other alternative is to add a new --term-signal option that could
be used to tell what signal the user want forwarded if the timeout
command gets a TERM. Then I could use the command like this:
timeout --signal=KILL --term-signal=KILL 1h ./my_program
--
Kim Hansen
Vadgårdsvej 3, 2.tv
2860 Søborg
Fastnet: 3956 2437 -- Mobil: 3091 2437
