CPU Loop of vi process after killing terminal

[Martin Decker]

I am experiencing a strange CPU Loop of a vi process on a HP-UX 11.23 ia64 system. Somehow, my terminal was disconnected while editing a file with vi. A day later, I realized a process, using 1 of my 2 CPUs and it collected more than 1000 CPU Minutes.

ps -ef|grep vi

orashadb 6767 6244 241 15:18:12 pts/0 1035:03 vi awrrpt_2_3573_3574.txt

tusc reports a loop of:
tusc -a -f -v -p 6767
( Attached to process 6767 ("vi awrrpt_2_3573_3574.txt") [32-bit] ) [6767] In user-mode ........................................................................................................................................ [running] [6767] write(1, 0x400c9780, 2047) .......................................................................................................................... ERR#6 ENXIO [6767] sigvec(SIGCONT, 0x7fff19e0, 0x7fff19f0) ............................................................................................................. = 0
vec.sv_handler: 0x777ce5e0
vec.sv_mask: EMPTY SET
vec.sv_flags: SV_RESETHAND
ovec.sv_handler: SIG_IGN
ovec.sv_mask: EMPTY SET
ovec.sv_flags: SV_RESETHAND
[6767] write(1, 0x400c9780, 1648) .......................................................................................................................... ERR#6 ENXIO [6767] Received signal 27, SIGTTIN, in read(), [SIG_DFL], no siginfo [6767] Received signal 26, SIGCONT, in read(), [caught], no siginfo [6767] read(0, 0x7fff6b38, 1) .............................................................................................................................. = 0 [6767] sigvec(SIGCONT, 0x7fff19e0, 0x7fff19f0) ............................................................................................................. = 0
vec.sv_handler: SIG_IGN
vec.sv_mask: EMPTY SET
vec.sv_flags: SV_RESETHAND
ovec.sv_handler: SIG_DFL
ovec.sv_mask: EMPTY SET
ovec.sv_flags: SV_RESETHAND

Is this a bug or does it work as designed?

Regards,
Martin

[Arunvijai_4]

Hi Martin,

Do you have PHCO_31705 installed on your server? Just check and it could be a reason for this..

http://www1.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHCO_31705&context=hpux:800:11:23

-Arun

[Martin Decker]

Hello Arun,

yes, the PHCO_31705 is installed. Moreover, we do not use ied.

It may be worth mentioning that we log in with a personal account and then use "super" to switch to an application account. The vi command was executed from the application account. We use super version 3.20 patchlevel 0.

Regards,
Martin

[Muthukumar_5]

May be process related on vi is storing dump informations to /var/preserve directory?

--
Muthu

[Arunvijai_4]

Hi Martin,

I believe when a terminal is disconnected abruptly, user process remains.. This can be an expected behaviour since user process such as VI remains in memory.

-Arun

[Arunvijai_4]

Martin, from patch database i can see PHCO_32444, http://www1.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHCO_32444&context=hpux:800:11:23

and PHCO_32856 http://www1.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHCO_32856&context=hpux:800:11:23

both are SH-PSOX and KSH patches. You can try them as well to make sure you have latest patches for the shell.

-Arun

[Martin Decker]

Sorry, /var/preserve is empty. In the meantime, I could reproduce the problem.

If I enter "vi " and start a new shell with the vi command ":sh" and then disconnect the terminal, the vi Process loops.

Is this expected behaviour?

Regards,
Martin

[Arunvijai_4]

Martin, I am not able to reproduce this on Linux and 11.11. Are you first trying to "super" then, start vi ?

-Arun

[Muthukumar_5]

It may be worth mentioning that we log in with a personal account and then use "super" to switch to an application account. The vi command was executed from the application account
>>>

May be a problem with super. Try to do this in normal account as,

a) login as normal user
b) vi test
c) esc>:sh
d) exit

it will come to normal vi test screen.

Can you try this after login with su to application user account?

--
Muthu

[Arunvijai_4]

Hi Martin, I have with changing user.. That is, #1) login as root
#2) su
#3) vi test.c
#4) In vi, :sh
#5) From another terminal, kill sshd

I am not able to reproduce the problem and i could n't see any VI in loop.

-Arun

[Martin Decker]

I just found out that super does not have anything to do with it. It also occurs if I just log in with my personal account. I have attached a tusc log of the action.

I use HP-UX B.11.23 U ia64.

Regards,
Martin

[Arunvijai_4]

Martin, I tried with 11.23 (IA64) and not able to reproduce the issue. I use "su" to switch to normal user from root. Is it what you are doing ?

-Arun

[Martin Decker]

No, i just log in via ssh to my personal user, then open vi, create a new shell with ":sh" and then kill the terminal window.

Regards,
Martin

[Muthukumar_5]

Post this information,

swlist -l file | grep -w vi
what `which vi`

--
Muthu

[Martin Decker]

$ what `which vi`
/usr/bin/vi:
$ B.11.23 Jul 15 2003 02:09:47 $
$Revision: B11.23_LR
Fri Aug 29 21:42:38 PDT 2003 $

Unfortunately, I don´t have access to swlist.

Regards,
Martin

[Arunvijai_4]

Yes, Now i am able to reproduce the problem since login with normal user account on 11.23 IA64.

-Arun

[Arunvijai_4]

Yes, we both are using same version

# what `which vi`
/usr/bin/vi:
$ B.11.23 Jul 15 2003 02:09:47 $
$Revision: B11.23_LR
Fri Aug 29 21:42:38 PDT 2003 $

# swlist -l file |grep -w vi

TextEditors.EDITORS2: /usr/bin/vi

-Arun

[Arunvijai_4]

I think, i found a reason here. when you kill the terminal you kill only the "sh" executed from vi. Here, vi remains intact.
# ps -ae |grep -i vi
26194 ? 0:00 vi

But, when you close the terminal, all the processes are getting cleared. (I use putty, after killing user terminal, i close putty window) Now,

# ps -ae |grep -i vi

lists nothing..

-Arun

[Martin Decker]

I do not just kill the shell. I close my SSH Client (SecureCRT) and vi keeps running with 1 CPU used.

Regards,
Martin

[Bill Hassell]

What is the setting for your traps? (hint: type trap). There is a trap condition SIGHUP which is normally set to send a terminate signal to all processes attached to the login port. If someone removed the trap entry at the end of your /etc/profile, then the temporary setting at the top of /etc/profile (that disables traps 1 2 and 3) will remain in effect. This means that a hangup (disconnect) signal is ignored.

[Martin Decker]

$ trap
trap -- 'echo '\''logout'\' EXIT

In my personal .profile, it says:

# Set up the shell environment:
set -u
trap "echo 'logout'" 0

Is that the problem?

Regards,
martin

[Bill Hassell]

Nope. The trap command (without values) shows just one trap (zero or exit) that will run the logout script. The pair of traps in /etc/profile looks like this:

trap "" 1 2 3
...
trap 1 2 3

The first turns off (ignores) signals 1 2 and 3, and the second (at the bottom of /etc/profile) turns normal traps back on again. So SIGHUP isn't your problem here.