cancel
Showing results for 
Search instead for 
Did you mean: 

Wait reason / Blocked on: OTHER

moff
Occasional Advisor

Wait reason / Blocked on: OTHER

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.
11 REPLIES
Duncan Edmonstone
Honored Contributor

Re: Wait reason / Blocked on: OTHER

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

HTH

Duncan
moff
Occasional Advisor

Re: Wait reason / Blocked on: OTHER

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
Honored Contributor

Re: Wait reason / Blocked on: OTHER

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

HTH

Duncan
moff
Occasional Advisor

Re: Wait reason / Blocked on: OTHER

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
Acclaimed Contributor

Re: Wait reason / Blocked on: OTHER

>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
Occasional Advisor

Re: Wait reason / Blocked on: OTHER

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
Acclaimed Contributor

Re: Wait reason / Blocked on: OTHER

>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
Occasional Advisor

Re: Wait reason / Blocked on: OTHER

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
Acclaimed Contributor

Re: Wait reason / Blocked on: OTHER

>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.)
moff
Occasional Advisor

Re: Wait reason / Blocked on: OTHER

Hi Dennis,
SHLIB_PATH was previously unset, although on some of our servers we're also running Oracle DB and on those it was set to the Oracle lib path only.

To get my app to work now I have set or appended /usr/lib/hpux64 to the SHLIB_PATH

$echo $SHLIB_PATH
sh: SHLIB_PATH: Parameter not set.
[... run application - it doesn't work ...]
$export SHLIB_PATH=/usr/lib/hpux64
$echo $SHLIB_PATH
/usr/lib/hpux64
[... run application - it does work ...]


As you say, it's working now so it's not the end of the world if I can't get to the bottom of this.
I'd just like to understand what's changed, because from my PoV I'd done nothing and it went from working to broken, and I know computers are logical beasts that will generally only do what they've been told to :)
Dennis Handly
Acclaimed Contributor

Re: Wait reason / Blocked on: OTHER

>SHLIB_PATH was previously unset

If unset it may look at the embedded path, which may now be wrong.

>To get my app to work now I have set or appended /usr/lib/hpux64 to the SHLIB_PATH

You shouldn't have to append it, since that is the default.

sh: SHLIB_PATH: Parameter not set.
[... run application - it doesn't work ...]

You could use ldd(1) to determine which shlib is different.