lyns@atc.boeing.com (10/11/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
rembo@unisoft.com (Tony Rems) (10/13/90)
In article <2190@megadon.UUCP> you write: >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. Well, you can perform the above task in C by, doing a popen("ps -ef", "r"); check the popen man page. Your other alternative is to go digging into the kernel to check the process table. Why do the work when ps has already done it for you? -Tony
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (10/15/90)
In article <2206@megadon.UUCP> you write: >In article <2190@megadon.UUCP> you write: >>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. > >Well, you can perform the above task in C by, doing a >popen("ps -ef", "r"); Here's the funny part. Using this program: /* popenpsef.c -- demo popen() */ #include <stdio.h> main() { FILE *pp; char line[BUFSIZ]; pp = popen("ps -ef","r"); while ( fgets(line, sizeof line, pp) != NULL ) fputs(line,stdout); } and doing 'time ps -ef' vs. 'time popenpsef' a few times, I get these results: time ps -ef 0.2u 0.3s 0:00 206% 70+427k 0+0io 0pf+0w 0.2u 0.3s 0:00 70% 69+435k 0+0io 0pf+0w 0.2u 0.3s 0:00 206% 71+444k 0+0io 0pf+0w time popenpsef 0.0u 0.0s 0:00 8% 6+15k 0+0io 0pf+0w 0.0u 0.0s 0:00 9% 7+18k 0+0io 0pf+0w 0.0u 0.0s 0:00 5% 6+14k 0+0io 0pf+0w Clearly, ps(1) is doing something slow and large when connected to a tty that it doesn't do when connected to a pipe this way. Despite the "0:00" in the real-time field, the response is noticeably faster with the popen()'ed version. --Blair "Counter-intuition: when you know that if you want mayo you can't have mustard also, even though you've never tried it."
cpcahil@virtech.UUCP (Conor P. Cahill) (10/17/90)
In article <2190@megadon.UUCP> lyns@atc.boeing.com 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. If you are trying to find out if a particular executable is running (as opposed to finding out if any programs named "xyz" are running) you can just try to open the file for writing. If the open fails with ETXTBSY, the executable is being run. Note that this works even if you don't have write permission on the file because the text-busy condition is usually checked before the access permissions. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
cowan@marob.masa.com (John Cowan) (10/17/90)
In article <2207@megadon.UUCP>, bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >Using this program: > > /* popenpsef.c -- demo popen() */ > #include <stdio.h> > main() > { > FILE *pp; > char line[BUFSIZ]; > > pp = popen("ps -ef","r"); > > while ( fgets(line, sizeof line, pp) != NULL ) > fputs(line,stdout); > } > >and doing 'time ps -ef' vs. 'time popenpsef' a few times, >I get these results: > > time ps -ef > 0.2u 0.3s 0:00 206% 70+427k 0+0io 0pf+0w > 0.2u 0.3s 0:00 70% 69+435k 0+0io 0pf+0w > 0.2u 0.3s 0:00 206% 71+444k 0+0io 0pf+0w > > time popenpsef > 0.0u 0.0s 0:00 8% 6+15k 0+0io 0pf+0w > 0.0u 0.0s 0:00 9% 7+18k 0+0io 0pf+0w > 0.0u 0.0s 0:00 5% 6+14k 0+0io 0pf+0w [bogus conclusion about 'ps' behavior deleted] Since your code above doesn't do a pclose(), it doesn't bother to wait for the embedded ps command to terminate. Therefore, the timing statistics refer only to the run time of "popenpsef" itself only. Here's the statistics as generated on my system. BTW, timing was done using the built-in command of the csh, which seems (by the output format) to be what you used as well. time ps -ef >/dev/null 0.2u 0.2s 0:01 30% 0.1u 0.2s 0:01 32% 0.2u 0.2s 0:00 32% 0.2u 0.2s 0:01 30% time popenpsef > /dev/null 0.0u 0.1s 0:01 6% 0.0u 0.1s 0:00 10% 0.0u 0.1s 0:00 6% 0.0u 0.1s 0:01 8% time popenpsef2 >/dev/null 0.2u 0.3s 0:00 46% 0.2u 0.4s 0:00 52% 0.2u 0.4s 0:01 54% 0.2u 0.4s 0:01 58% where popenpsef is your original code, and popenpsef2 inserts a "pclose(pp)" at the end of the program. I ran this on a '386-based Xenix System V box. -- cowan@marob.masa.com (aka ...!hombre!marob!cowan) e'osai ko sarji la lojban
flee@guardian.cs.psu.edu (Felix Lee) (10/21/90)
This is *not* true for SunOS, NFS, and related systems. You are allowed to write into running executables, with possibly disastrous consequences. -- Felix Lee flee@cs.psu.edu
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (10/21/90)
>In article <2207@megadon.UUCP>, > bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >> >>and doing 'time ps -ef' vs. 'time popenpsef' a few times, >>I get these results: > >[bogus conclusion about 'ps' behavior deleted] Mostly bogus :-). The perceived user-time isn't bogus at all. The program returns to the caller (whether command-line or script) _much_ faster when the pclose() is left to the kernel. This probably does require more real CPU time and definitely more kernel-mode time, but less user time, which (I'm glad this is a moderated group or this would start a purists-vs-pragmatists flame war) is what we're paid for, really. >Therefore, the timing statistics >refer only to the run time of "popenpsef" itself only. I prefer to think of it as an "executive" who's "delegated" the dirty work. >Here's the statistics as generated on my system. BTW, timing was done using >the built-in command of the csh, which seems (by the output format) to be >what you used as well. Yes, it was. --Blair "Sometimes, it pays."