Wait reason / Blocked on: OTHER

[moff]

Hi,
We've got an application which had been working fine across several different servers on a Superdome but has stopped working on all.
When it's run it doesn't do anything; it sits there and shows up in ps -ef but doesn't even get as far as writing its usual start up log files.

At the vendor's suggestion I've checked
/var/adm/syslog/syslog.log
/var/adm/msgbuf
but there's nothing of note in them.

Looking at CPU/Disk/Memory the server is doing no work.

I've used glance (4.7) and gpm to look at the process. In gpm Process Wait States it shows "Blocked On" as Other 100%. In glance it shows Other 100% in the Event column.

Is there any way to determine what this block/wait event is?

This is on HPUX 11.31.

thanks.

[Duncan Edmonstone]

From the help page for glance:

OTHER The process was started
before the midaemon was
started and has not been

resumed, or the block state
is unknown.

So either the process you have been looking at has been blocked since before midaemon was started, or it can't figure out why it is blocked.

Not very helpful I know... are you able to restart the app/process? M
HTH

Duncan

[moff]

Hi Duncan,
Thanks for the reply. The application process has been restarted several times, midaemon has been running since last week, so presumably this means the Other falls into the second of your explanations? :)

[Duncan Edmonstone]

I guess so... do you have tusc installed on the system? You could try attaching to the process to get a look at what system calls (if any) it is doing.

HTH

Duncan

[moff]

Hi,
I've attached the output from tusc

Is the ERR#2 ENOENT an indication of the problem?
I am coming at this from a very sketchy unix/HPUX background and feling rather out of my depth here :)

[Dennis Handly]

>I've attached the output from tusc. Is the ERR#2 ENOENT an indication of the problem?

No, you have stopped it in dld.so where it is doing a shlib path search.

If this process is blocked it's because you don't have enough CPU or memory resources.

[moff]

Hi,
This has been resolved; I set my SHLIB_PATH=/usr/lib/hpux64 and everything's ok now.

Thanks for people's input, especially the pointer to tusc.

[Dennis Handly]

>I set my SHLIB_PATH=/usr/lib/hpux64 and

For Integrity you should really be using LD_LIBRARY_PATH. And since /usr/lib/hpux64 is the default, you can just unset it.

[moff]

Hi Dennis,
Could you elaborate please? I'm afraid I'm coming at this from an apps point of view and just set env vars to whatever the installation manual says.
Are LD_LIBRARY_PATH and SHLIB_PATH mutually exclusive?
I'm interested by your mention of it being a default - does that imply that something's changed outside of the app that has caused the requirement to explicitly set this value?

Thanks.

[Dennis Handly]

>Are LD_LIBRARY_PATH and SHLIB_PATH mutually exclusive?

No but LD_LIBRARY_PATH is standard and SHLIB_PATH is only for HP-UX. LD_LIBRARY_PATH works for everything but PA32 shlibs.

>does that imply that something has changed outside of the app that has caused the requirement to explicitly set this value?

If you had to set it to the default it means the value before you set it was bad. Can you echo $SHLIB_PATH before you set it.

(Or you can just ignore it since it's working.)