Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!eru!luth!sunic!mcsun!ukc!stc!root44!gwc
From: gwc@root.co.uk (Geoff Clare)
Newsgroups: comp.unix.questions
Subject: Re: Killing the correct process
Message-ID: <1221@root44.co.uk>
Date: 14 Feb 90 14:59:34 GMT
References: <22332@adm.BRL.MIL> <5312@star.cs.vu.nl> <1212@root44.co.uk> <5352@star.cs.vu.nl>
Reply-To: gwc@root.co.uk (Geoff Clare)
Organization: UniSoft Ltd, London, England
Lines: 77

In article <5352@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
>In article <1212@root44.co.uk>,
>	gwc@root.co.uk (Geoff Clare) writes:
>
>)There is a much simpler way than Maarten's.
>)
>)The basic strategy is:
>)
>)	(sleep $time; kill $$) & exec "$@"
>
>Here's an example using your timeout command:
>
>	$ timeout -v 0 cat
>	Terminated
>	$ 
>	TIMED OUT "cat"
>
>Sic!  The verbose message appears ASYNCHRONOUSLY!  That's not what I want!

There is a big difference in the purpose of the '-v' option between our
scripts.  Yours provides the only message you get to say that the command
timed out.  With mine the shell has already informed me of that
(synchronously) with the "Terminated" message seen above.  The '-v' would
not normally be used in this simple case.  It is there to provide extra
information about *which* command was timed out, in the event of several
parallel "timeout" commands.

Also, the delay is a direct result of allowing the process time to
clean up.  Using a straight 'kill -9' as your script did would mean
the verbose message would appear before the prompt.  The very slight
delay in providing the additional information is a small price to pay
for allowing the timed out process to tidy up.

>To get a synchronous message I had to have a *child* execute the command
>supplied, while the *parent* reports the status.

But this has a very serious drawback - you lose the exit status of the
executed command.  The command could die horribly with no error message,
and you would not know about it!  All your script tells you is whether
the command completed within the timeout period or not.

>Another bug in your script is shown by the following example:
>
>[stuff deleted]
>
>You leave useless processes hanging around!

Leaving a harmless sleep command behind will not usually cause any
problems.  It will get zapped when the user logs out, if it hasn't
completed by then.  There is no way round this if you want to have
the parent process exec the command.  This slight drawback is greatly
outweighed by the advantage of getting the exit status passed back
correctly.

>)An important feature which Maarten's script lacks, is that mine kills
>)the process with SIGTERM, allowing it to clean up.  It only goes for
>)SIGKILL if the SIGTERM doesn't do the job.  [...]
>
>How do you determine that the job has finished cleaning up?

The script allows 2 seconds.  If this might not be enough it could be
passed as an option to "timeout".  Most commands only need to remove a
few temporary files and maybe kill some children, which doesn't take
very long.  A chance to clean up in a short time is much better than no
chance at all.

>Turning back to my script - the only problem with it: the given command
>might have created children which keep hanging around after their parent
>has died.

A well designed command will kill its children as part of the clean up
procedure when it receives a SIGTERM.  That is why it's important to use
SIGTERM first rather than going straight for SIGKILL.
-- 
Geoff Clare, UniSoft Limited, Saunderson House, Hayne Street, London EC1A 9HH
gwc@root.co.uk  (Dumb mailers: ...!uunet!root.co.uk!gwc)  Tel: +44-1-315-6600
                                         (from 6th May 1990): +44-71-315-6600