Unlock HIB State Process in OpenVMS

[Gattho]

Hi, well my problem is that I have a process in HIB state and I will like to unlock or reactive it. How can I do it.

Could anybody help, Thanks.

[Oswald Knoppers_1]

Why do you think that a HIBernating process is a problem?

To wake the process you need a program calling the $WAKE system service with the PID of the hibernating process.

But really, what is your problem?

Oswald

[abrsvc]

Perhaps there is a mis-understanding of what the HIB state means? Typicaly when a program needs towait for an event, the programmer will place the processin HIB (hibernate) state. This means that there will be effectively NO resource consumption for that process (CPU or I/O) until the event occurs. When the triggering event happens, the process is awakened (thus the $wake system service) and processing proceeds. It is normal to see processes in HIB or LEF (local event flag wait) which is a similar concept.

Perhaps rather than wondering why the HIB doesn't go away, focus should be on what the process is supposed to do. In other words, what is the root issue here? What should be happening that is not?

Also, please indicate the VMS version and the hardware that is involved.

Thanks,
Dan

[Robert Gezelter]

Gattho,

HIB is a normal scheduling state. A process goes into the HIBernate scheduling state when it invokes SYS$HIBER. This is often done when a program is using the AST mechanism to process events.

Details of HIBER can be found in the various editions of "OpenVMS Internals and Data Structures", the most recent of which were authored by Ruth Goldenberg, et al. A somewhat less extensive reference is the OpenVMS Programming Concepts manual and the OpenVMS System Services manual, both of which are available from the OpenVMS www site at http://www.hp.com/go/openvms

I did an introduction to ASTs at various DECUS symposia. The slides from the most recent incarnation of that session, from the 2000 Compaq Enterprise Technology Symposium, are available at http://www.rlgsc.com/cets/2000/435.html

Two phenomena are common:

- Often, processes using the AST mechanism do so little processing that they appear to be permanently in HIB. This is often incorrect, as is shown by increasing IO counts.

- If the process is truly forever in HIB, with absolutely no activity, it is likely that an event was incorrectly processed for some reason. This can only be corrected by a detailed review and analysis of the code.

I hope that the above is helpful. If the problem is an event getting improperly handled, doing a $WAKE on the process will not be productive, and has a good chance of creating more difficult problems.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

The simplistic answer to this is to toss a wake at the code

http://www.decuslib.com/freeware/freewarev80/hoffman_examples/wake.c

but in the best case (when the next time the bug surfaces) the application and the code will stall again. In the worst case, this application is performing sequential processing and the code has failed to notice an event, and the code is now irrevocably stuck.

Put another way, what you've asked for probably won't work. But there's the code. Have at.

The application code that you are maintaining here likely contains a bug in its processing somewhere, and you're going to have to debug that code to figure out why it went wrong and why the code is now in a hibernation state.

Not fun, I know.

Often not an easy problem to solve, either.

Hibernation is a perfectly normal state.

A missed event, on the other hand, is a problem.

Finding where that event was lost is your task.

There are probably as many different ways to insert a bug into application $hiber and $wake processing as there are programmers.

In particular, the usual debugging technique is either print-based debugging (simpler) or using the OpenVMS debugger (more advanced, more capable).

If you'd like to discuss this further and can provide additional details on the application processing around the $hiber and $wake, I might be able to do better than the above; than what is effectively a wild guess at what's going on here, and toward the application environment. Regardless, this stuff usually involves rummaging around in the application source code looking for bugs.

And a request:

http://mattgemmell.com/2008/12/08/what-have-you-tried

As currently posed, your question is unfortunately not answerable. And again, the above answer is a wild guess.

[John Gillings]

Gattho,

$WAKE a sleeping process at your peril.

As others have stated, HIB is a voluntary state, usually indicating that the process is waiting for some asynchronous event which will generate a $WAKE.

So, there are two possibilities to explain continuing HIB state

1) The event it's waiting for has not happened.

If that's the case and you issue a $WAKE, there are two sub possibilities

1.a) The program is coded correctly and will check that the event truly has occurred. Since it hasn't, the process will immediately return to HIB state. You get nowhere.

1.b) The program will proceed on the (incorrect) assumption that the event has occured. What happens next depends on many things, but it's unlikely to be anything you desire. You may break stuff.

2) The event has occurred, but somehow the $WAKE has been lost.

If that's the case then an external $WAKE may "fix" the immediate problem, but it also means there's a bug in the program. Obviously that will need to be found and fixed. $WAKEing the process will lose any state information that might help you identify the problem.

You need to balance the risks...

[John McL]

Gattho,

Let's start at the start. Which process are you worried about and what image (i.e. program) is it running?

I've just done a $ SHOW SYSTEM on a machine here and I found that the first 20 processes are all in HIB. These are all system processes like SWAPPER, CLUSTER_SERVER, SHADOW_SERVER, NET$ACP etc. This situation is quite normal.

Several of our application processes are also in HIB state, and again this is normal.

What's the process name and what image is it running?

People here will probably tell you to do different things (and sometimes nothing at all) if it is a system process, a process that is running a third-party application, or a process that is running an application that you wrote or was written by one of your colleagues.