Shell freezes after backgroud task completes

[Leslie Chaim]

Maybe it's one of these Mondays...

Anyway, I have this issue I start my cmd like this:
cmd arg1 arg2 arg3 < in > out &

It seems to me that if I run another command when the background process is about to complete that the Shell just hangs up. I've tried it many times.

cmd is a Perl script which interprets arg1 and then calls System() and a new Java process. So my input/output handles goes from the Shell to Perl to Java, however only Java uses the input/output.

The commands which I use is:
wc -l out
ps -fe | egrep 'java|perl'
...

Thanks,

[Leslie Chaim]

A few corrections to my original post and some more questions:

I changed system() to exec(), still same problem. I thought that exec() would help, in any case exec() is the ???right thing??? and that is what I need.

After examining this "freezing" problem further I found that the problem exists even if I give no command:

Say I start like this:
PROMPT> cmd arg1 arg2 arg3 < in > out &
I immediately get back my
PROMPT>
Now I check from another terminal until the job finishes; I come back and press

The Shell freezes up!:(

From my other terminal I checked that the exec()ED process finished, and what is really strange is the hanging Shell starts chewing up CPU cycles like crazy.

Please Help. Thanks.

One more question, is there ANY way to alter what shows up in the COMMAND column of the ps cmd output?

[Jose Mosquera]

Hi,

Try to check any hang conditions with:
nohup the aouput will be redirected to nohup.out

Rgds.

[James Murtagh]

Hi Leslie,

Sounds complicated this one! First we need to know what OS and shell you are using. Also, does the shell ever come back?

When a normal background completes it will wait until the next command and append the standard output (normally the Done message) to the standard out of the new command. This is probably where the problem lies....

You said you are checking for the exec process to finish - what about the background process id? Also, does the CPU cycles affect user or system mode?

If you are familiar with q4 I could maybe check what the shell is waiting on?

Also, are you seeing many zombie processes?

And finally, what do you want to see in the command field?

Regards,

James.

[Leslie Chaim]

JM: Sounds complicated this one!
LC: Well, thanks:)

JM: First we need to know what OS and shell you are using. Also, does the shell ever come back?
LC: uname ???a returns: HP-UX sdc6host B.11.00 U 9000/800 129901567 unlimited-user license, I hope this is enough info;) I am using ksh, and the shell never comes back

JM: When a normal background completes it will wait until the next command and append the standard output (normally the Done message) to the standard out of the new command. This is probably where the problem lies....
LC: I ???think??? I have an idea but I need some more clarification please.

JM: You said you are checking for the exec process to finish - what about the background process id? Also, does the CPU cycles affect user or system mode?
LC: The background PID does get eliminated. I am not a Sys admin and I am not sure to how to check the affects of user or system. Though the uptime commands??? output does look ???normal??? or usual. Attached are some commands which I ran which shows you some output of galnce, top, and ps. You will also see the huge difference if I do a kill ???stop and then a kill -cont

JM: If you are familiar with q4 I could maybe check what the shell is waiting on?
LC: No, I am not familiar with q4, but I???m willing to learn;)

JM: Also, are you seeing many zombie processes?
LC: CO

JM: And finally, what do you want to see in the command field?
LC: /opt/java1.4/bin/PA_RISC2.0/java -cp .:/oracle/app/product/8

Instead of seeing ???java ?????? I would like to see something like ???my_program???

And nohup does not change anything.

Thanks in advance,
Leslie

[James R. Ferguson]

Hi Leslie:

You might try applying patch PHCO_27418 (ksh cumulative patch). No reboot is necessary to install.

Regards!

...JRF...

[James Murtagh]

Hi Leslie,

Still seems complicated! :)

Its hard to see if the shell hangs from the input or from trying to write the output from the background job finishing. The ksh patch may help, especially if you are on an old version. You can use "what /usr/bin/ksh" or use "swlist -l product|grep -i ksh" to check what version you are on.

We will need to monitor the process using the "el" flags to ps, and also check using the process id instead of the user id. I think this is best shown by examples, and I'll try and show how to have your command shown in the CMD field.

With a shell script called james.ksh that looks like the following:

sleep 60
xclock

this is what you will see....

# james.ksh &
[1] 3575
# ps -el | grep 3575
1 S 0 3576 3575 0 168 24 42fe9ac0 16 40c2a3c0 pts/0 0:00 sleep
1 S 0 3575 2929 0 158 24 43037600 55 42ff2040 pts/0 0:00 ksh
<---------xclock starts here
# ps -el | grep 3575
1 S 0 3579 3575 5 154 24 42fe9ac0 58 a25240 pts/0 0:00 xclock
1 S 0 3575 2929 2 158 24 43037600 55 42ff2040 pts/0 0:00 ksh

You can also use adb to check the wait channel of the process:

# echo 0xa25240/D|adb -k /stand/vmunix /dev/kmem
per_processor_selects:
per_processor_selects: 0
<------ xclock killed
#
<------ carraige return, this is where your ksh hangs
[1] + Done james.ksh &

Now, if you want the command shown in the ps listing, change the script to be:

#!/usr/bin/ksh
sleep 60
xclock

# james.ksh &
[1] 3589
# ps -el|grep 3589
1 S 0 3589 2929 0 158 24 42edc440 50 42a3f040 pts/0 0:00 james.ksh
1 S 0 3590 3589 0 168 24 42ed4900 16 40c2a3c0 pts/0 0:00 sleep
# ps -el|grep 3589
1 S 0 3589 2929 2 158 24 42edc440 50 42a3f040 pts/0 0:00 james.ksh
1 S 0 3593 3589 6 154 24 42ed4900 58 a25240 pts/0 0:00 xclock
#
[1] + Done james.ksh &

Hope the format is ok as I am pasting this output. Now if you take the last example you see process 2929 spawns 3589 which spawns 3590....you have to keep tracking the child processes to find where any problems are. If you can do this for your background process and for the hung (or rather very busy) ksh we may spot something. Also, you may want to check the wait channel for the ksh process.

Also, do you have the "tusc" program on any of your servers?

Regards,

James.