Something weird using a kill on HP-UX 11

[Dirk-jan hartman]

Hi there,

I am somewhat at a loss at the reaction of HP-UX to one of the scripts we use here.
Basically, what happens is that 3 processes (AEFUF, AEFAD, AEFSECEX) and maybe some child processes are identified and killed by a script using kill -9 $PROCESS_ID (for details see attachment).
99,9% of the time the script runs smoothly, but occasionally, a message is returned saying : " usage: kill [ -signo ] pid ..."

I tried to reproduce this output of kill on the commandline;
ommitting the process id will get you the message " kill: 7737: The specified process does not exist." and ommitting everyting does " su: kill: The number of parameters specified is not correct."
But ... if I call /usr/bin/kill directly it says "Usage: kill [-signo] pid ... "
To further confuse you guys, look at the following command line snippet:
hp27:/vba/acc/nb/lat/lat_01/command_library [154] > which kill
/usr/bin/kill
hp27:/vba/acc/nb/lat/lat_01/command_library [155] > /usr/bin/kill
usage: kill [ -signo ] pid ...
hp27:/vba/acc/nb/lat/lat_01/command_library [156] > kill
su: kill: The number of parameters specified is not correct.
So I use /usr/bin/kill, but if I call the /usr/bin/kill directly i get another /usr/bin/kill than via the normal kill which also goes to /usr/bin/kill?
Does this make sense at all?
Or do I better apply for a job as counter clerk at McDonalds?

Thanks in advance for all your help,
DJ

[Mark Grant]

When you call kill, it is a shell built in command that does the killing. When you run /usr/bin/kill you are running the actual kill command.

If your script is using the bourne shell, it is worth noting that it doesn't have a built in "kill" and so you would be using the command version

[Mark Grant · Accepted solution]

Just looked at your script at can see that you explicitly use /usr/bin/kill.

It would appear that at times your script doesn't get an existing PID is it possible that the script is trying to kill a process that exisited when the script started but had terminated by the time you got to the killing?

[john korterman]

Hi,
the error message may also be caused by an illegal pid number, i.e. >30000, or if the pid contains characters.
Perhaps you could let your script write out the pid to the logfile as well.
Just a suggestion....

regards,
John K.

[Dirk-jan hartman]

Thanks Mark!

I did not know the which information would not take into account the shell built-ins, so that was the initial reason of my confusion.
And you were right about the absence of the PID, I noticed a typo in the variable which is used for killing the child processes. Only occurs 0.1% of the time, so that would also account for my 99,9% being correct.

Again thanks alot for your quick response.
Cheers,
DJ

[Jeff Schussele]

Hi DJ,

Just a note that one should only use kill -9 as a last resort because a -9 kill will do no cleanup of shared memory or semaphores & such. Therefore over time all these uncollected resources could cause shortages & force you to manually cleanup or even reboot to continue.
Always use a vanilla kill or the equivalent kill -15 & then if that doesn't work you can proceed towards kill -9 trying some of the other signals along the way.

My 2 cents,
Jeff

[Bill Hassell]

The virtually useless which and whereis commands should be replaced with whence (and type which is an alias: whence -v). which and whereis do *NOT* tell you what the shell (or shell script will do with the command: su. Now since you are using the fullpath for kill, you are indeed getting /usr/bin/kill but for general usage, never use which and whereis to determine what will happen when you type a command. Use type as in: type kill (this assumes you are using a POSIX shell such as /usr/bin/sh or /usr/bin/ksh)

To see why this is so important, try the following:

cd $HOME
echo "echo Big mistake!" > su
chmod 755 su
PATH=::$PATH
su
whereis su
type su

(where did your su come from?) Then remove su and fix PATH:

rm su
PATH=$(cat /etc/PATH)

Some other surprises:

whereis fc history for
which fc history for
type fc history for

The reason that whereis and which don't work is that they are not part of the shell, they are external commands. They know nothing about what the shell will do with a command. The whence command (for POSIX shells) interprets the command string and returns how the shell will treat the string which is what counts. The command may be a shell builtin, or an alias, or located in some unexpected PATH location. That's why all scripts should replace $PATH with an internal PATH value known to be correct (PATH=/usr/bin, *not* PATH=$PATH:other_stuff). A shell script can easily be subverted if PATH is used from the user's environment and assumed to be safe.

As far as kill failing, you should always assume that your PID number is not a number at all, that is is null or that it contains several numbers and bail out before doing something wrong. And as mentioned, kill -9 is dangerous to the health of your system. Always use kill -15 first, give the program a chance to terminate, then use kill -9 as a last resort. All sane programs should respond to kill -15 and terminate properly. kill -9 bypasses all the shutdown code in the program and simply removes the program leaving shared memory in shambles and unposted data disappears.

[Dirk-jan hartman]

Bill, Jeff,

thank you for replying!
Unix is really a very strong and fun operating system as you can reach your goal in a number of different ways - or at least it seems until you stumble onto the minor differences like with the whence/whereis/which/type commands.
It is really good that you guys want to invest your time in helping us out! I appreciate it very much, as do a lot of other people I think.

As for the kill, the script was developped by an expert who indicated that the processes can only be shut down in this manner, thus calling for the 'kill -9 ' option. The processes are alledgedly a little bit buggy in terminating themselves, and could hang if you ask them to commit suicide (kill -15).

We have been running this script for over a year now on HP-UX10, and the last half year on HP-UX11, and surprisingly we have had no resource contingencies during that time.
I think there are also kernel routines collecting garbage, so maybe the "garbagemen" took care of this issue.
But I agree that a 'kill -15' is a nicer option whenever applicable.

Again thanks for all your help,
Cheers,
DJ