after installing 11.00 ksh sessions are not disconnecting

[TMcB]

Hello everyone.

We have recently upgraded 3 of our 4 servers from 10.20 to 11.00.
When I say 'upgrade', we actually did the clean install method. We also installed the latest HWE1100 and QPK1100. I noticed that it includes patch PHCO_27418.

Anyway, since then we have noticed that ksh sessions are behaving oddly.
We have a menu based system, which the users click on window's X button to exit from.

However, the ksh session remains, and it appears the user is still logged in.

On our remaining 10.20 server, when the users do the same, the ksh session disappears OK.

Any ideas??

Thanks

[Pete Randall]

What X button? Is this running via a terminal emulator like Reflections?


Pete

[TMcB]

sorry ...

Yes, they are using terminal emulators.

[Pete Randall]

So, do they bring up a full CDE session and then exit by quitting the terminal emulator? We have the same problem and we use user education (with a baseball bat, usually) to circumvent it. I'm surprised that it worked in 10.20!


Pete

[TMcB]

Hi Pete,
Whatever way the software system is written, the users don't have any option to logout.
They have always hit the X button, when they return to the main menu.

We had a problem with it working on hp10.20 after a general patch install, but as soon as we removed patch phco_20018, worked again.

[Pete Randall]

Did you check to see if there's an 11.0 equivalent to PHCO_20018?


Pete

[Pete Randall]

Disregard - there isn't!

I don't know what to think, maybe there's something in a ksh patch somewhere but I'm not sure how to find it.


Pete

[Graham Cameron_1]

I think the root cause of this to do with signal handling.

If I kill my hummingbird telnet window by clicking the X button, it generates a SIGHUP (1) to the child.

So, if I open a terminal window with a shell, type
trap 'date >>1' 1
and kill the window, it logs the datestamp to file 1.

It sounds like your problem is that something is no longer propagating or handling these signals properly.

Check it's not something obvious like a trap statement in /etc/profile of your 11.00 system that the 10.20 system didn't have.

-- Graham

[TMcB]

Hi Graham

the profiles are the same on the 10.20 server and the 11.00 server.

The /etc/profile contains :
trap "" 1 2 3
trap 1 2 3

The user's profile includes :
trap "" 0 2 3 4
trap "~epic/etc/remove_eptc" 1

[John Palmer]

I've had a look at PHCO_20018 and there appear to have been several fixes to SIGHUP handling.

These 'fixes' will already be applied to the 11.00 ksh so you are experiencing the same problem as before but without the option to remove the fix.

Could you post the relevant scripts (including ~epic/etc/remove_eptc)?

One thing that may be worth trying is to change your scripts to use the Posix shell (#!/usr/bin/sh rather than #!/usr/bin/ksh). I've found differences in them in the past.

Regards,
John

[TMcB]

Hi

attached is the remove_eptc script

[TMcB]

Hi everyone

I uninstalled patch phco_27418 "ksh(1) cumulative patch" which was installed as part of the latest patch kit, and everything is now working OK.

My only concern is is unistalling this patch will have some other effect.

[John Palmer]

One thing of interest is that your 'remove_eptc' script attempts to kill the eptc process with kill -2 but your user's .profile specifically ignores this trap (trap "" 0 2 3 4).

man sh-ksh states that 'If arg is the null string (your case) then this signal is ignored by the shell AND BY THE COMMANDS THAT IT INVOKES (my emphasis).

I would expect your kill -2 to have no effect and suspect that you've been getting away with it due to a bug in ksh.

If you have a test environment, I'd put some diag code in remove_eptc (just log to a tmp file) to see whether it is being called. I'd also either change your kill to kill -15 (the default) or (if -2 is required) change the trap to "" 0 3 4.

Regards,
John