ksh taking all cpu time

[Kevin Wright]

I have installed the March 2001 patch bundle, and since then I am getting ksh processes owned by init which are taking up all of the cpu time..I think this is happenning when users log out incorrectly, however why are they taking up all the cpu time? and why has it not happened before the patch bundle? Has anyone had this sort of problem before?

[rainer doelker]

Kevin,

could you just check which KSH patch you have installed. And on which HP-UX you are?

What do you mean by users log out incorrectly, what do they do? What session do they leave. Usually a process whose father dies belongs to init.

Does the ksh still have children? Can you kill the ksh?

rainer

[Kevin Wright]

Ya, that is right, these ksh processes become owned by init, with several children still remaining..The process can be killed with a -9 option.
the patch is PHCO_20018
When these users login, they are taken into a menu driven application..if they log out correctly through the menu options, all is ok, however if they click the disconnect button on the reflection X window, the shell does not terminate and then takes all the cpu time..
We have instructed users to log out correctly, and I have written a script to run every hour and kill these processes..
Has anyone experienced this type of problem before and do you think I should remove the latest ksh patch?

[rainer doelker · Accepted solution]

Kevin,
from this description I would assume that the signal from the Xserver or Windowmanager which tells the shell to stop gets lost. Usually we would use SIGCLD or SIGHUP for that.

Possibilities:
1) ReflectionX does not send a signal
==> test by using another shell
2) Your application does not forward the signal
==> from your description it looks as if did before
3) The worst thing: the last changes (see patchtext) made to ksh in PHCO_200018 brought something which misses the signal. You might verify it by removing the patch.

IF that is really the problem we should open a SW-case and a change-request asap to fix it.

rainer

[rainer doelker]

Kevin,

I do not know if you have an SW-contract. If not and you could verify that the patch brings this problem. I would appreciate if you write me a detailed description so I can open a CR.
(rainer_doelker@hp.com)

rainer

[John Palmer]

The usual cause of this problem with own written menu programs is not checking that the shell 'read' command has failed.

This means that code that does the following:-

do

read option

done

goes into a screaming loop when the user disconnects the session rather than quitting properly.

A simple way to fix it is to replace:
read option
with
read option || exit

I don't know why this should only happen after installing the patch bundle though.

[Bill Hassell]

This may be a simpler answer here. Check in /etc/profile. There should be a statement at the beginning:

trap "" 123

This prevents users from interrupting the login shell and bypassing /etc/profile. But there must also be:

trap 123

at the end of /etc/profile. This re-enables the normal behavior of signals such as SIGHUP (hangup signal). If the second trap statement is missing, the shell is signaled that a hangup has occurred (originally designed for modems but works the same way on telnet) but the shell was told to ignore it...thus the hung process. The shell is looping because the connection has been severed and there is no direction from the kernel (it was ignored). Note that the excess CPU usage is usually accompanied by excess LAN traffic too, generated by the orphan shell process.

BTW: many new sysadmins will see both statements and figure that the second one is redundant, and remove it. They are very different and both are required in the order given.

[Kevin Wright]

Thanks for all who replied, the problem is fixed by removing the patch.
both trap statements were in /etc/profile.
I removed the patch PHCO_20018, and logged into the menu, clicked the disconnect button, and the shell terminated.
I have a call open to HP, we do have a SW contract.
Perhaps the menu code is not written correctly, but it works without the new patch.