STOP/ID for process in LEF

[Ruslan R. Laishev]

Hi All!

Just a dumb question: is this (STOP/ID) a legal operation for the process which in LEF state and what is a probably result?

Thanks.

[John Eerenberg]

Generally speaking, yes it is and the result is that the process will be deleted from the system. There are exceptions and possible side effects (such an application not liking a process simply being deleted).

Get on a system and test it (of course don't use it on a process you are not familiar with such as system processes).

john

[Willem Grooters]

Whether it is a LEGAL operation or not, is highly depending on the program itself. It is definitely NOT the preferred way.
It will, in most cases, delete the process but be aware that this may lead to inconsistencies in your data. Since the process will not follow the normal flow of control during image rundown, buffers will not be flushed to disk cuasing data inconsistnecy, it could force database transactions to be break down.

Willem

[Mobeen_1]

Ruslan,
My take on your question :-

Yes, STOP/ID= is the right means to terminate a process on VMS platform.

However as some of our colleagues have indicated in earlier posts, some times this could cause an issue. It really depends on the applications on how they react to stop/id.

I have seen cases where you do a stop/id on a process and it used to go into rwas state and the server at times had to be rebooted to clear.

As a result, we used to use something called FORCEX for a few application servers/processes on our VMS systems and for the rest we would use STOP/ID

Let us know if you have any questions

regards
Mobeen

[Stanley F Quayle]

> As a result, we used to use something called FORCEX for a few application servers/processes on our VMS systems and for the rest we would use STOP/ID

This posting highlights the two ways to "kill" a process:

1. STOP/ID (like "kill -9" in Unix) stops the process immediately and the process does not execute any exit handlers.

2. STOP/EXIT=USER/ID (not available until VMS V7.3-2 without writing a program) causes the process to exit, running all exit handlers. Properly-writen programs will do the "right thing" in its exit handlers.

Doing either of these, of course, is not a good practice -- best to develop an application-level way to signal the process.

LEF state is usually used to wait for completion of an I/O operation. Because the process can't go away until all pending I/O is cancelled, you run the risk of the process becoming a "zombie", waiting in RWAST or other "RW" states. Rebooting is the only approved way to clear this process.

[Mobeen_1]

Stanley,
I totally agree with you on the fact that ... Every Application has to have a decent shutdown with it and that will be the best way to stop an aplication.

Having said that, many a times i have seen applications that don't shutdown with their shutdown tools provided living us to explore the possibility of using either of the 2 methods mentioned above :-)

regards
Mobeen

[Jan van den Ende]

Stanley,



1. STOP/ID (like "kill -9" in Unix) stops the process immediately and the process does not execute any exit handlers.



Even THAT is not exactly true.
STOP/ID is NOT stopping the process, it is a VERY URGENT request to the process to commit suicide as the next action to perform.
But a process in a state that somehow does not perform ANYTHING also does NOT perform suicide. And suicide DOES activate some (harsh) exit handlers.
And if any sufficiently heavy reason prevents the process to die, then it gets into a coma (like the aforementioned RW states). The given example of 'waiting I/O completion' demonstrates the reason: if the process is gone when the IO is delevered to the memory-location that WAS owned by the process, what inconsistencies can than be generated? And worse, the IO carries instructions to tell the process it finished, and should wake up. Where will that message (the AST) be delevered? So, the process waits for that before really dying.
But if the IO deleivery itself got frustrated, it wil wait 'forever'. So, an RWAST process may have to wait in limbo till the next reboot.

(hopefully, maybe, somehow, sometime, some-one in Engeneering will be able to find a _SAFE_ (!!) way to really remove such processes....) ;-)


fwiw

Jan

[Cass Witkowski]

If the process is running DSM (Digital Standard Mumps) a STOP/ID usually will bring down the database on that machine.

So it is better to ask questions first before you shoot

[Stanley F Quayle]

> And suicide DOES activate some (harsh) exit handlers.

I wasn't precise. The application's exit handler doesn't get executed. This is the one that should do the application-specific cleanup.

> (hopefully, maybe, somehow, sometime, some-one in Engeneering will be able to find a _SAFE_ (!!) way to really remove such processes....) ;-)

Since this has been at the top of the wish list for years, it must be REALLY difficult to do...

[Ruslan R. Laishev]

Thanks for answers to All!
So, VMS have not a robust facility to stop process in state other than COM (?) ?

[labadie_1 · Accepted solution]

When somebody with all the knowledge of Ruslan asks for a similar question, I think there must be a very precise context.

may be the following articles will help

[OpenVMS] Process Hangs in LEF or RWAST Due to Timing Issue
http://h18000.www1.hp.com/support/asktima/operating_systems/CTI_SRC941214002940.html

[MOTIF] WSAn: Process Hangs in LEF on SYS$SYNCH With OpenVMS VAX,Alpha
http://h18000.www1.hp.com/support/asktima/operating_systems/CTI_SRC990225004653.html

Regards

Gerard

[Ruslan R. Laishev]

labadie, your bet.

I has been puzzled by VMS732_F11X-V0100 kit description (6.1.2 Process hangs in LEF state) and HP support answers: "you have a bad freeware prog which hung in LEF state, so please undo the F11 ECO"...

After that, I start thinking about a posibility to stop process at all w/o reboot of a node :(

[Jan van den Ende]

Ruslan,


So, VMS have not a robust facility to stop process in state other than COM (?) ?

To me the most important word here is "robust".
There are several ways to stop --most-- processes, but there is a special reason why STOP/ID was implemented as a severe suicide request: now process rundown is under control of VMS, and if VMS decides that the state of some of the processes's statusses indicate that indiscriminate deletion MIGHT cause the CHANCE of inconsistencies, then, rather than taking that risk, the process deletion gets interrupted, until such status gets changed. (and for some specific RWAST states there DO exist SDA procedures to incur such state-change!).

So, it really is part of the stability we all love so much in VMS (and STILL, it IS very desirable that most of those statusses can somehow be wound down!).

Jan

[Hein van den Heuvel]

Ruslan R. Laishev,

All the replies above are true and in the true OpenVMS spirit express and address the concern about system integrety.

But let's go back to the basic question. It of course begs the question 'What problem are you really trying to solve'.

If you just have a run-away compile or link in your terminal session. Hit control-c (^C) or ^Y and be happy.

If there is a batch job running that is not correct, just DELE/ENTRY
http://h71000.www7.hp.com/doc/731FINAL/6489/6489pro_046.html#index_x_1887

More often then not, a STOP/ID will do just fine.
Whether teh process is in COM or LEF or HIB, just whack it!
Of course you give the system little or no chance to clean up, but did you need a that?
That's why I ask 'what problem are you trying to solve'.

The biggest problem with stop/ID used to be that the last few RMS buffers were not flushed and specifically log files would lack final data. VMS (RMS) has recently (ok, a couple of years now) been improved to try and do the right thing.

Hope this helps,

Hein.

[Ruslan R. Laishev]

Hello Hein,
nice to see you question: 'what problem are you trying to solve'.

Ok. I have tried to understand what is a obligation of OpenVMS to entered STOP/ID [/IMAGE] command.


[quote]
Whether teh process is in COM or LEF or HIB, just whack it!
[/quote]
Periodicaly I have a situation on which I cannot kill process in LEF with STOP/ID (it's different programs).

[quote]
Of course you give the system little or no chance to clean up, but did you need a that?
[/quote]
At the time I looking for a way to exclude at all a situation on which a process can hung (unstopably) in the LEF state. :)


[quote]
VMS (RMS) has recently (ok, a couple of years now) been improved to try and do the right thing.
[/quote]
Can you explain it with more details ?

Thanks.

[Willem Grooters]

Ruslan,

Part of it all: what is the process waiting for? Indeed, normally it's some IO, it could also be a timer (and assiciated AST setting some flag). Try to find out using SDA (ANA/SYS).
If you have control over the sources (that is: if you're able to change it) you'd better find a way to handle this properly. If you are sure you flushed your IO-buffers, stopping the process wouldn't normally harm your data - but still, it's undesirable. If the program waits for IO from a device you can access directly (for instance a mailbox), it would be a wise thing to create a "STOP" command that would trigger the program to finish properly. It may involve some programming but it IS the best way.
If the program sends out an IO to a printer and waits for it to complete, you run into this situation if the printer is off-line. You should have this situation handled by the program, so it won't stay in this state in the first place.
It all depends on what you're program is doing.

Willem

[Ruslan R. Laishev]

SDA show call [/next] shows that process is sitting in the sys$rms+offset...

[John Yu_1]

It's legal but as others have pointed out
it causes the program to stop w/o exit handling so transaction mgmt or db images may crash.

It may be a concern if you have txn mgr like TMX or MQSeries.

Forcex is preferred and relatively easy to call.

[Martin P.J. Zinser]

Hello Ruslan,

after you have sent the stop/id to the process and it will not go away, what state is the process in? RWAST, something else?

Greetings, Martin

[Ruslan R. Laishev]

Hi Martin,

no RWAST, it's still in LEF!

[Stanley F Quayle]

> no RWAST, it's still in LEF!

In order for the process to respond to the STOP/ID, the process has to actually run a little bit.

Are all AST's disabled for the process? Is its priority so low that it never gets CPU time? Is the process suspended (SET PROC/SUSP/ID=xxx)?

I have a nifty tool that answers these questions -- what version of VMS are you running, and what platform (VAX/Alpha)?

[Ruslan R. Laishev]

[quote]
Are all AST's disabled for the process?
[/quote]
No.

[quote]
Is its priority so low that it never gets CPU time?
[/quote]
No.

[quote]
Is the process suspended (SET PROC/SUSP/ID=xxx)?
[/quote]
No.

[quote]
I have a nifty tool that answers these questions -- what version of VMS are you running, and what platform (VAX/Alpha)?
[/quote]
VMS/Alpha 7.3-2. I have not the process at the time, only SYSDUMP.DMP.

[Antoniov.]

Have you process priority greater than zero and less than 16?

Antonio Vigliotti

[Stanley F Quayle]

Next time you get into this state, run the attached program, and paste the output here...

[Ruslan R. Laishev]

[quote]
Have you process priority greater than zero and less than 16?
[/quote]
Yep.