Return to BSD News archive
Xref: sserve comp.unix.bsd:12459 comp.sys.sun.admin:17252 Newsgroups: comp.unix.bsd,comp.sys.sun.admin Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!news.service.uci.edu!ucivax!megatek!randy From: randy@megatek.com (Randy Davis) Subject: Re: Why does ps(1) put process names in parentheses? Message-ID: <1993Aug19.211924.12481@megatek.com> Sender: randy@megatek.com (Randy Davis) Reply-To: randy@megatek.com Organization: Megatek Corporation, San Diego, California References: <1993Aug17.223713.2704@lia.com> Date: Thu, 19 Aug 1993 21:19:24 GMT Lines: 41 In article <1993Aug17.223713.2704@lia.com> larry@lia.com writes: |At a site that I maintain, I frequently see output from ps(1) |which looks like the following: | liasi3 4899 0.0 0.0 136 ? IW Aug 16 2:05 (OdrSop) [...] |Questions: |1) What does it mean when a process name is displayed in parentheses | like this? The best my local experts can come up with is that | ps is getting the name from "a different table" than normal. Well, yes and no... All the parentheses around the program name means is that the process itself has re-written its argv[0], which is as simple as a strcpy in C to argv[0] from within the program. There *are* two copies of this data, one of which the user can modify in this way and the other one which is not user accessable. I seem to recall that one of the "ps" outputs will output the unmodifiable table information, i.e. the "true" name - I don't remember which output switch does this. |2) Why do processes get into this state? No telling, from the information you've given. The only processes that I find hard to kill (i.e., impossible to kill), are ones that in a disk-wait state, or any other type of hardware-wait state, where a kernal device driver is waiting for data from a hardware device. I see these most often with NFS operations when the filesystem is not mounted with the "intr" flag set and the remote host goes down, or when doing a time-consuming tape command such as an "mt erase". |3) What is the root cause of the operational problems I am experiencing? | (hard-to-kill processes, etc.). How do I detect/prevent it? First off, is it really a problem?? I.e., do you REALLY need to be killing these processes? If so, and since this process IS an interface to external hardware, then you probably ought to look at the device driver for the optical WORM drive it is controlling, or see what the WORM drive is doing and stop it from the hardware end, so it will send the needed signal to the OS. Randy Davis Email: randy@megatek.com Corporate Network and System Administrator megatek!randy@uunet.uu.net Megatek Corporation, San Diego, California ucsd!megatek!randy