Pádraig Brady wrote:
> On 07/03/10 18:54, Kim Hansen wrote:
>> What signal should the timeout program send to the child process when
>> it gets a SIGTERM?
>>
>> The timeout in coreutils does not do the same as timeout from tct.
>> tct-timeout sends the signal it was instructed to send on timeout,
>> coreutils-timeout sends the signal it received.
>>
>> I like the tct behaviour as that makes it easy to send a SIGKILL, is
>> there a chance that you could change timeout in coreutils to do it
>> like that?
>
> I suppose one could special case SIGTERM,
> in which case it would be best to send the signal that the
> user defines to terminate the command.
>
> However, what if the user defines a signal that they
> don't want to actually terminate the command. For example
> imagine they want to use timeout to get a progress report
> from dd after 10s like: timeout -sUSR1 10s dd ...
> Convoluted I guess and probably better handled with:
> dd & ( sleep 10; kill -USR1 $! )
>
> Also what about the case where a command usually
> behaves normally and exits when it gets a TERM,
> but sometimes it hangs and needs a KILL which
> you specify with timeout. You wouldn't want to
> change the TERM into a KILL in that case.
>
> 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.
