Brian wrote:
[snip]
Activity monitor shows approximately 30 or so active processes. Does anyone know why the others don't show up? Thought it might be related to only processes that are started by my userid but that theory wasn't true after testing. Anyway, I'd be interested in knowing what processes are expected to be returned by these calls and which are not.
----------------
Waverly wrote:
I believe I've seen the answer to your question a few times, answered by a few members.
Unfortunately I cant locate them but I found a solution to your being able to extract the list you desire. This comes from a post of Ken's last year.
Its quite a bit of detail here, which I appreciate. More info than less is mostly best.
W.
-----Original Message-----
From: Ken Shmidheiser [mailto:kshmidheiser@...]
Sent: Thursday, February 12, 2004 12:22 PM
To: futurebasic@...
Subject: [FB] Re: OSX Utlity watches running application
In my earlier post it this thread, I was remiss in not explaining how versatile and easily programmable the Unix ps command is in FB^3.
When using the ps command, you need to realize that you are taking a snapshot of your system for an instance of time. Thus, by the time you see the information, it's slightly out of date, but nevertheless useful. (To see an ongoing display of system usage, use ps cousin, top.
I have not been able to figure out how to capture top results in FB.)
You can build your own process table with the ps command by using any of the following with the -o switch:
%cpu percentage cpu usage (alias pcpu)
%mem percentage memory usage (alias pmem)
acflag accounting flag (alias acflg)
command command and arguments
cpu short-term cpu usage factor (for scheduling)
flags the process flags, in hexadecimal (alias f)
gid the effective gid
inblk total blocks read (alias inblock)
jobc job control count
ktrace tracing flags
ktracep tracing vnode
lim memoryuse limit
logname login name of user who started the process
lstart time started
majflt total page faults
minflt total page reclaims
msgrcv total messages received (reads from pipes/sockets)
msgsnd total messages sent (writes on pipes/sockets)
nice nice value (alias ni)
nivcsw total involuntary context switches
nsigs total signals taken (alias nsignals)
nswap total swaps in/out
nvcsw total voluntary context switches
nwchan wait channel (as an address)
oublk total blocks written (alias oublock)
p_ru resource usage (valid only for zombie)
paddr swap address
pagein pageins (same as majflt)
pgid process group number
pid process ID
poip pageouts in progress
ppid parent process ID
pri scheduling priority
re core residency time (in seconds; 127 = infinity)
rgid real group ID
rlink reverse link on run queue, or 0
rss resident set size
rsz resident set size + (text size / text use count) (alias
rssize)
rtprio realtime priority (101 = not a realtime process)
ruid real user ID
ruser user name (from ruid)
sess session pointer
sig pending signals (alias pending)
sigcatch caught signals (alias caught)
sigignore ignored signals (alias ignored)
sigmask blocked signals (alias blocked)
sl sleep time (in seconds; 127 = infinity)
start time started
state symbolic process state (alias stat)
svgid saved gid from a setgid executable
svuid saved uid from a setuid executable
tdev control terminal device number
time accumulated cpu time, user + system (alias cputime)
tpgid control terminal process group ID
tsess control terminal session pointer
tsiz text size (in Kbytes)
tt control terminal name (two letter abbreviation)
tty full name of control terminal
uprocp process pointer
ucomm name to be used for accounting
uid effective user ID
upr scheduling priority on return from system call (alias usrpri)
user user name (from uid)
vsz virtual size in Kbytes (alias vsize)
wchan wait channel (as a symbolic name)
xstat exit or stop status (valid only for stopped or zombie process)
Example: To build a table with the application (or "command"
in Unix parlance), current state, percent of memory used by the application, percent of total cpu cycles used by the application and pid, the command string would look like this:
ps ax -o command,state,%mem,%cpu,pid -c | grep -v root
To sort the results based on memory usage, the command would be:
ps ax -o command,state,%mem,%cpu,pid -c -m | grep -v root
To sort the results based on cpu usage, the command would be:
ps ax -o command,state,%mem,%cpu,pid -c -r | grep -v root
You can run these from the Terminal to experiment, or use the following
FB^3 code to put them in a scrolling edit field:
begin globals
dim as container gC
end globals
local fn BuildWindow
dim as rect r
dim as str15 t
t = "Process Monitor"
setrect( r, 0, 0, 400, 400)
appearance window 1,t,@r,_kDocumentWindowClass,_kWindowCloseBoxAttribute
def SetWindowBackground( _kThemeActiveDialogBackgroundBrush,_zTrue)
text _courier, 10
setrect( r, 20, 20, 364, 380)
edit field 1,"",@r, _framedNoCR_usePlainFrame_noDrawFocus,_leftJust
setrect( r, 364, 19, 380, 381)
scroll button -1,0,0,0,0, @r, _scrollOther
end fn
local fn DoUnixCommand$( cmdStr as str255 ) dim as str255 tempStr, resultStr
open "unix", 2, cmdStr
do
line input #2, tempStr
gC += tempStr + chr$(13)
until eof (2)
close 2
end fn
local fn ProcessMonitor$
end fn = fn DoUnixCommand$(¬
"ps ax -o command,state,%mem,%cpu,pid -c -r | grep -v root" )
// You can also try these:
//"ps ax -o command,state,%mem,%cpu,pid -c | grep -v root" ) //"ps ax -o command,state,%mem,%cpu,pid -c -m | grep -v root" )
local fn DoDialog
if dialog(0) = _wndClose then end
end fn
on dialog fn DoDialog
fn BuildWindow
fn ProcessMonitor$
edit$(1) = #gC : gC = ""
setselect 0, 0 : edit field 0
do
handleevents
until 0
Since Michael is looking for stopped or stalled processes, he will be interested in examining the state field-- particularly the T and Z responses which indicate the process has either stopped or died. In that case, he probably would want to kill then restart the app or, in a worst-case scenario, reboot the machine.
State is given by a sequence of letters, for example, "RWNA". The first letter indicates the run state of the process:
D Marks a process in disk (or other short term, uninter-
ruptible) wait.
I Marks a process that is idle (sleeping for longer than
about 20 seconds).
R Marks a runnable process.
S Marks a process that is sleeping for less than about 20
seconds.
T Marks a stopped process.
Z Marks a dead process (a "zombie").
Additional characters after these, if any, indicate additional
state information:
+ The process is in the foreground process group of its
control terminal.
< The process has raised CPU scheduling priority.
> The process has specified a soft limit on memory require-
ments and is currently
exceeding that limit; such a pro-
cess is (necessarily) not swapped.
A the process has asked for random page replacement
(VA_ANOM, from vadvise(2), for example, lisp(1) in a
garbage collect).
E The process is trying to exit.
L The process has pages locked in core (for example, for
raw I/O).
N The process has reduced CPU scheduling priority (see
setpriority(2)).
S The process has asked for FIFO page replacement (VA_SEQL,
from vadvise(2), for example, a large image processing
program using virtual memory to sequentially address
voluminous data).
s The process is a session leader.
V The process is suspended during a vfork.
W The process is swapped out.
X The process is being traced or debugged.
Here are some guidelines for using the ps report to spot trouble:
* Look for many identical jobs owned by the same user. This may result from someone running a script that starts a lot of background jobs without waiting for any of the jobs to terminate. Talk to the user to find out if that's the case. If necessary, use the kill command to terminate some of the processes.
* Look at the TIME field for processes that have accumulated a large amount of CPU time.
Such processes might be in an endless loop.
* Look at the CPU field to find unimportant processes that consume a large percentage of CPU time.
* Look at the MEM field for processes that consume too large a percentage of memory.
If a process is a memory hog, kill the process.
If many processes are using lots of memory, the system may need more memory.
* Watch for a runaway process that uses progressively more CPU time. You can check this by using the -f option to see the start time
(START) of the process and by watching the TIME field for the accumulation of CPU time.
Ken
--