lyn@carter.BCASDL.BOEING.COM ( Lyn Stewart ) (07/13/90)
Has anyone got a method for finding out if a process is running short of "ps -ef | grep processname" in a pipe. There must be a better way from within a c program. Lynwood A. Stewart Boeing Commercial Airplanes lyns@atc.boeing.com
cpcahil@virtech.uucp (Conor P. Cahill) (07/15/90)
In article <200001@carter.BCASDL.BOEING.COM> lyn@carter.BCASDL.BOEING.COM ( Lyn Stewart ) writes: >Has anyone got a method for finding out if a process is running short of >"ps -ef | grep processname" in a pipe. There must be a better way from >within a c program. An easy way to see if a particular executable is running is to try to open the file with write permissions. If you get the errno ETXTBSY, the executable is being run. If you don't know the full pathname to the executable, or if you need additional information (other than the fact that the program is running, like who is running it or how much cpu it is using, etc) you need to run ps and parse the output (or replicate the ps code in your program). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
guy@auspex.auspex.com (Guy Harris) (07/15/90)
(Another one for the FAQ list? Or is it already there?) >Has anyone got a method for finding out if a process is running short of >"ps -ef | grep processname" in a pipe. There must be a better way from >within a c program. 1) Processes in most UNIX systems don't have names, they have process IDs. If you have 10 people on your machine running "cat", they are doing so in 10 distinct processes, but the "name" of those processes, as reported by "ps", will all be "cat". If they gave the same arguments to "cat", the entire command line as reported by "ps" should be the same. 2) The innards of "ps" differ quite a bit from UNIX implementation to UNIX implementation - including potentially from version to version of any particular thread of UNIX implementations. Some, but not all, provide programmatic interfaces to let you do some of what "ps" does; SunOS 4.x provides the "kvm" library, and some of the later S5 releases, including S5R4, provide "/proc". 3) If you know the process ID of the process, you can, in most modern UNIX systems, determine whether a process with that process ID exists; use the "kill" call to send that process signal number 0. This will not actually do anything *to* that process; however, it will do all the same checking that sending a real signal would do. As such, if the "kill" fails, returning -1 and setting "errno" to ESRCH, you know no process with that process ID exists; if it succeeds, or fails with any other error (e.g. EPERM), you know it exists. One caveat: different flavors of UNIX report different things if the process has exited but the corpse hasn't yet been reaped by its parent. As I remember, 4.2BSD and later indicate that it doesn't exist (I don't think 4.1BSD and earlier supported sending "signal 0"), and S5 systems report that it does (I forget whether S3 had "signal 0", but I don't think it did). POSIX appears to require the S5 behavior. Another caveat; I didn't say, in the first sentence of 3), "determine whether that process exists", I said "determine whether a process with that process ID exists". Your process could have exited; if enough time had passed since it did, and enough other processes created new processes with by forking, some new process could be assigned the same process ID as the old process, giving you a "false positive".
konczal@mail-gw.ncsl.nist.gov (Joseph C. Konczal) (07/18/90)
From: "Conor P. Cahill" <cpcahil@virtech.uucp> Date: 15 Jul 90 01:59:57 GMT An easy way to see if a particular executable is running is to try to open the file with write permissions. If you get the errno ETXTBSY, the executable is being run. Where does this happen, what kind of Unix? I have overwritten executable files that are currently running under various revisions of BSD, SunOS, even VMS, without ever getting errno ETXTBSY. After the image is loaded into core, why should the OS care what you do to the copy still on disk? ETXTBSY is not even listed in the `Errors' section of the SunOS `open' man page. --Joe Konczal konczal@mail-gw.ncsl.nist.gov
cpcahil@virtech.uucp (Conor P. Cahill) (07/18/90)
In article <23896@adm.BRL.MIL> konczal@mail-gw.ncsl.nist.gov (Joseph C. Konczal) writes: > > From: "Conor P. Cahill" <cpcahil@virtech.uucp> > Date: 15 Jul 90 01:59:57 GMT > > An easy way to see if a particular executable is running is to try > to open the file with write permissions. If you get the errno ETXTBSY, > the executable is being run. > >Where does this happen, what kind of Unix? I have overwritten >executable files that are currently running under various revisions of >BSD, SunOS, even VMS, without ever getting errno ETXTBSY. After the As a minimum it happens on System V.*, HP-UX, and Ultrix (that is all that I have access to at the momemt). Are you overwriting by unlinking the original as opposed to opening & writing on top of what was there? -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
yval@tasu17.UUCP (Yuval Yarom) (07/18/90)
In article <23896@adm.BRL.MIL> konczal@mail-gw.ncsl.nist.gov (Joseph C. Konczal) writes: | | From: "Conor P. Cahill" <cpcahil@virtech.uucp> | Date: 15 Jul 90 01:59:57 GMT | | An easy way to see if a particular executable is running is to try | to open the file with write permissions. If you get the errno ETXTBSY, | the executable is being run. | |Where does this happen, what kind of Unix? I have overwritten |executable files that are currently running under various revisions of |BSD, SunOS, even VMS, without ever getting errno ETXTBSY. After the |image is loaded into core, why should the OS care what you do to the |copy still on disk? ETXTBSY is not even listed in the `Errors' |section of the SunOS `open' man page. | |--Joe Konczal konczal@mail-gw.ncsl.nist.gov It seems that ETXTBSY does not appear in the SunOS manuals, but it does work (at least here). I think that this featureis not documented because it works only if the executable is running on the local machine. -- Yuval Yarom yval@taux01.nsc.com
guy@auspex.auspex.com (Guy Harris) (07/19/90)
>Where does this happen, what kind of Unix? I have overwritten >executable files that are currently running under various revisions of >BSD, SunOS, even VMS, without ever getting errno ETXTBSY. Err, you *are* aware that VMS is not any "kind of Unix", and as such 1000% irrelevant here, right? (Yes, I know there is some amount of UNIX compatibility supplied with VAX C or something like that; that doesn't count, and things like EUNICE don't count, either. Neither do DEC's plans to make VMS POSIX-compliant; POSIX doesn't specify ETXTBSY.) I'm quite surprised to heard you've never gotten that error under BSD. I'm not surprised you've not gotten it under SunOS, at least if it was SunOS 4.x, as SunOS 4.x never returns ETXTBSY. In addition, earlier releases of SunOS may not have done the check for NFS-mounted file systems, even if the program was running on the same machine on which the open for writing was done (I know it didn't do any checking if they happened on different machines); if the BSD you were running was one with NFS added to it, that might explain how you managed not to get ETXTBSY under BSD. (You *are* speaking of *overwriting* the executable file, not unlinking it and copying a new one in, right? The BSD "install" script unlinks the target and then copies a new version in, which avoids the problem. BSD, unlike System V, does not continue the stupid V7 tradition of disallowing removing the last link to a busy text file....) >After the image is loaded into core, why should the OS care what you do >to the copy still on disk? In most modern versions of UNIX the image isn't necessarily "loaded into core"; it's often demand-paged from the "copy still on disk". >ETXTBSY is not even listed in the `Errors' section of the SunOS `open' >man page. You have 4.x, then.