SPAWNed process termination causes runaway

[Allan Large]

We have an Itanium running OpenVMS v8.3-1H1. The heart of the matter situation is this ...

Using a terminal emulation program, we connect to the system. It doesn't matter whether it is TELNET, SSH or LAT. We then execute a command procedure that all it has in it is:

$ SPAWN

This connects us to the spawned process. From that spawned process we run any program the prompts for input (just try $ MCR AUTHORIZE) and just let it sit there. We then just close the terminal emulation window.

If you then look at the sub-process that was created with the SPAWN, the process is running-away, accumulating CPU about as fast as it can. The working set size ever so slowly creeps up but no other counts/quotas.

We have tested this on Alpha V8.3 and Itanium V8.3 and it works as expected in that the sub-process and its associated main program die when the window is closed.

Anyone have any ideas / experiences ?

[Jeremy Begg]

I just tried this on my rx2660 running VMS 8.3-1H1 with MultiNet and it did exactly as you described. The spawned subprocess consumes a full CPU.

Note that entering the SPAWN command at the DCL prompt doesn't have this effect, the CPU loop only happens if the SPAWN command is in a DCL procedure.

I'd call this a bug, and you should log a support call with HP.

Regards,
Jeremy Begg

[Jur van der Burg]

This works fine on my system. Did you install the latest UPDATE patchkit?

Jur.

[Allan Large]

Jeremy:

You are absolutely correct. The original SPAWN must come from a command procedure. Doing the SPAWN from the command line works fine. Additionally, the SPAWNed process must be running a program that is expecting input. Using DCL READ or INQUIRE however won't cause the same problem.


Jur:

The problem occurs with the initial release of V8.3-1h1 and after each of the 6 updates for this version.

I thought I would post here before logging a call to HP as I am surprised that it has not already been reported.

[Craig A]

If the only thing in the command procedure is SPWAN then can I ask why you bother doing that at all?

If you want to use AUTHORIZE why not just type:

$ MCR AUTHORIZE

Craig A
(who is obviously missing something)

[Allan Large]

Craig:

There is a bigger picture here. Basically, I presented this issue as bare-bones ... just stating the root of the problem as simply as possible.

We have a command procedure that is basically a menu processor, that allows certain users to SPAWN out of the process to do other things. When the user did a SPAWN and ran any program that prompted for input (I just used AUTHORIZE as an example) and would then just simply close the terminal session, without logging out and going back to the original session, the SPAWNed process would start consuming CPU time at a very rapid rate.

[Craig A]

Allan

OK. Sounds like some user edjumacation is required.

:-)

Craig A.

[Allan Large]

OK ... I found my answer. It was a known problem in DCL:


Patch kit VMS831H1I_DCL-V0100 says

5.2.4 Looping In Loginout During Terminal Hangup

5.2.4.1 Problem Description:

When a parent process has its nodelete bit set and spawns a subprocess, if the subprocess is still active and the terminal attached to it is closed, the parent process
goes into a loop with 100% CPU utilization.

Images Affected:

- [SYSEXE]DCL.EXE




Thanks guys !!!

[Allan Large]

See above....

[John Gillings]

Allan,

experiences...

I once issued an AUTHORIZE command via RSH to a system which didn't have SYSUAF defined. It didn't work, so I repeated the command as "PIPE DEFINE SYSUAF SYS$SYSTEM:SYSUAF ; MCR AUTHORIZE ".

A week or so later... the disk was full!

The first RSH command didn't terminate. AUTHORIZE looped asking if I wanted to create a new SYSUAF. The prompts ended up in the TCPIP$RSH_RUN.LOG file.

Sounds similar to your case, but I'm not convinced that it's something that DCL can fix, as it depends somewhat on the behaviour of the application.

Bottom line is you have to be very careful when executing remote commands.