Could I kill suspended processes which state is "MUTEX"?
If so, Could you tell me how to kill them?
(0006) Resolving Mutex Hangs?
Re: (0006) Resolving Mutex Hangs?
Processes that are locked in mutual exclusion states can not generally
be directly deleted via $delprc or STOP/ID -- these processes can be
deadlocked against a process quota limit, or can have encountered a
kernel-mode application or system problem.
DECamds -- an optionally-installaed package shipped with OpenVMS -- can
sometimes be used to clear the problem that is causing the process to
deadlock. DECamds is particularly good at resolving quota limitations.
There are, however, cases where only an OpenVMS system reboot can clear
the immediate (wedged) process. Permanently resolving these (non-quota)
cases requires determining the exact cause (lost I/O packet, leaking
quotas, device driver bugs, etc), and resolving it in the underlying
kernel-mode code.
In the process PCB, one can look at the EFWM cell to determine why the
process is wedged -- one can find the address of the JIB in the EFWM cell
indicating a pooled quota limitation, or one can find a resource number
from RSNDEF in this cell. Using the information in the Internals and
Data Structures Manual (https://books.google.com/books?id=ydKIsgCiFVsC), one can
often determine what the cause of the MUTEX is, and one can then resolve
it in local kernel-mode application code, or in local process quotas.
Errors in OpenVMS or in third-party packages will require the assistance
of the appropriate product support organization.
Related topics here in Ask The Wizard include (2347), (5841),
and (7120).
be directly deleted via $delprc or STOP/ID -- these processes can be
deadlocked against a process quota limit, or can have encountered a
kernel-mode application or system problem.
DECamds -- an optionally-installaed package shipped with OpenVMS -- can
sometimes be used to clear the problem that is causing the process to
deadlock. DECamds is particularly good at resolving quota limitations.
There are, however, cases where only an OpenVMS system reboot can clear
the immediate (wedged) process. Permanently resolving these (non-quota)
cases requires determining the exact cause (lost I/O packet, leaking
quotas, device driver bugs, etc), and resolving it in the underlying
kernel-mode code.
In the process PCB, one can look at the EFWM cell to determine why the
process is wedged -- one can find the address of the JIB in the EFWM cell
indicating a pooled quota limitation, or one can find a resource number
from RSNDEF in this cell. Using the information in the Internals and
Data Structures Manual (https://books.google.com/books?id=ydKIsgCiFVsC), one can
often determine what the cause of the MUTEX is, and one can then resolve
it in local kernel-mode application code, or in local process quotas.
Errors in OpenVMS or in third-party packages will require the assistance
of the appropriate product support organization.
Related topics here in Ask The Wizard include (2347), (5841),
and (7120).