Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stc!root44!gwc
From: gwc@root.co.uk (Geoff Clare)
Newsgroups: comp.unix.questions
Subject: Re: Killing the correct process
Message-ID: <1381@root44.co.uk>
Date: 23 Feb 90 15:05:36 GMT
References: <22332@adm.BRL.MIL> <5312@star.cs.vu.nl> <1212@root44.co.uk> <5352@star.cs.vu.nl> <1221@root44.co.uk> <5448@star.cs.vu.nl>
Reply-To: gwc@root.co.uk (Geoff Clare)
Organization: UniSoft Ltd, London, England
Lines: 87

In article <5448@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:

>I still want the verbose info to appear synchronously (see below).

I'll let you into a secret.  The original version never had a "verbose"
message at all - I never felt the need for it.  I added it because
I was posting my script as an alternative to yours, but using a better
strategy, so I thought it ought to have the same facilities.

As I said before, normally the verbose message isn't needed - the
shell will report the termination of the process.

However, if you really don't like the delay in the message, I offer
the following change which causes it to be printed straight away
(although still after the prompt) in cases where the command dies
immediately on the first kill.

Change:
	sleep 2

	# if process hasn't died yet, use SIGKILL
	kill -$SIGKILL $pid >/dev/null 2>&1
to:
	if kill -0 $pid >/dev/null 2>&1
	then
		sleep 2

		# if process hasn't died yet, use SIGKILL
		kill -$SIGKILL $pid >/dev/null 2>&1
	fi

>In your script the delay is always 2 seconds; in the latest version of my
>script it's a parameter.

This isn't very useful - how do you predict how long the command will
need to clean up?  Two seconds is plenty for most commands.

>)>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.
>
>Right; fixed in the current version (easy).

So now you can tell when something went wrong, but you still aren't
getting the full picture.  If the command is terminated by a signal
your script will instead exit with a non-zero exit code (usually
128 + signal number).

Another big advantage in having the parent execute the command is that
it is then a normal foreground process, so you can use the INTR and QUIT
keys in the normal way.  If the user interrupts your script, he gets
a prompt back and may think he has killed the command, whereas in fact
it's still running in the background.

Face it Maarten, having the child execute the command is a total no-hoper.

>)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.  [...]
>
>What if the command wasn't started from a terminal?  Not nice.
>Unnecessary too.

The script was designed for casual use from a terminal.  If I ever
wanted to put it to more serious use, I could get rid of the leftover
sleep by adding another background process to monitor the other two.
Or better still, I would use a C program.

>Another plus of timeout 5.0: the signal is now a parameter too.

Another unnecessary frill.  SIGTERM is the right signal to use - that's
why it's the default for the "kill" command.

>Now it's your turn again, Geoff! :-)

I'm not going to post my script again, because I think we've wasted enough
net.bandwidth on this already.  If anybody has saved a copy, they can
apply the change I suggested above if they think it's worth it.  (I don't
think it is - I doubt if I will ever use the '-v' option).
-- 
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