users process with PID 0 in the system

[Shailender_1]

We are running OpenVMS 7.3-1 on alpha ES40 servers. To kill the idle process we are using a freeware called watcher. Sometime we have realised that the process killed by the watcher doesn't release the global section. They still exist in the syustem with PID 0.

170 2042ACCA CSP_FAB 0
171 0 CSP_FAB 0
172 0 DIFFMOD6 0
173 0 CSP_TK 0
174 204190D0 CSP_FAB 0
175 20438CDF CSP_FAB 0
176 0 CSP_FAB 0
177 0 ETCHMOD6 0
178 0 CSP_FAB 0
179 0 CSP_TK 0
180 2044ACFB CSP_FAB 0

How can we stop such process? Does anyone has any idea ?

[Mrityunjoy Kundu]

hi dear,

Some time those process goes to RWAIT (Resourse wait state) or MWAIT state. Then those process has PID 0.

Some time those processes can be killed by stopping the decnet network and restarting it.
$stop/net decnet
$start/net decnet

[Volker Halle · Accepted solution]

Hi,

you should be looking at the output of SHOW SYSTEM for the state of those processes. The output you've shown is most likely from some kind of application, which is unable to obtain status information from those processes and therefore shows a PID of 0...

Any process running in OpenVMS has to have a non-zero PID.

Volker.

[Shailender_1]

Sho system output doesn't show these process, I cant see any process in the RWAST/MWAIT. Sho user also doesn't report these users. The above list is the contents from the UAF global section.

Background: One of our application checks for the number of users before aloowing any new user to login. Some times it reports that maximum limit already reached and denies new logins into the application. we checked the system and found that the current users where much below the threshold set. We esclated it to the application vendor and gave us one utility which reads the UAF global sections and produces the list of users in the uaf global section. which doesn't match with sho user or show system outputs.

[Volker Halle]

Hi,

this may then simply be an application problem. What is the 'UAF global section' ?

Maybe those processes exited the application abnormally and there was no rundown-handler executed to clean up the entry in the 'UAF global section'.

Volker.

[Volker Halle]

Can you check in ACCOUTING for a process termination record for those processes ?

$ SHOW ACC ! check whether accounting is active

$ ACC/TYPE=PROCESS -
/SINCE= -
/ID=

This would tell you when the given process exited and will also tell you the exit status.

Volker.

[John Gillings]

shailysingh

Killing "idle" processes is almost always a bad idea. It invariably causes more problems than it solves (if you doubt that, consider this posting!). I don't think I've ever seen an automated Idle Process Killer (IPK) that works properly and doesn't have the potential for causing great harm. Please think very hard about why you have an IPK at all, and if the perceived benefits outweigh problems caused by just this issue. You should also research what other problems you may experience by arbitrarily killing processes.

At the very least, you need to make sure the IPK doesn't just $DELPRC the target processes. It should $FORCEX, and you need to make sure the processes have exit handlers to clean up things like global sections and open files. Without properly implemented exit handlers, it's LIKELY you will corrupt files or data structures (indeed, the danging global sections you're describing here are a form of corruption).

$DELPRC is a very big hammer, which should be used VERY carefully.

Generic IPKs are a BAD solution looking for the wrong problem, and should be avoided.

[Dean McGorrill]

john may have it. yrs ago we had a homemade
tty idle watcher someone whipped up that didn't run right and left zombies. later was
fixed to do $forcex, and fixed most of the
problems. Dean