Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

Plan 9 - man page for proc (plan9 section 3)

PROC(3) 			     Library Functions Manual				  PROC(3)

       proc - running processes

       bind #p /proc


       The proc device serves a two-level directory structure.	The first level contains numbered
       directories corresponding to pids of live processes; each such directory contains a set of
       files representing the corresponding process.

       The  mem file contains the current memory image of the process.	A read or write at offset
       o, which must be a valid virtual address, accesses bytes from address o up to the  end  of
       the  memory  segment  containing o.  Kernel virtual memory, including the kernel stack for
       the process and saved user registers  (whose  addresses	are  machine-dependent),  can  be
       accessed through mem.  Writes are permitted only while the process is in the Stopped state
       and only to user addresses or registers.

       The read-only proc file contains the kernel per-process structure.  Its	main  use  is  to
       recover the kernel stack and program counter for kernel debugging.

       The  read-only  segment file contains a textual display of the memory segments attached to
       the process.  Each line has multiple fields: the type of segment (Stack, Text, Data,  Bss,
       etc.);  one-letter  flags  such	as  R for read-only, if any; starting virtual address, in
       hexadecimal; ending virtual address, and reference count.

       The read-only status file contains a string with eight fields, each followed by	a  space.
       The  fields  are:  the  process name and user name, each 27 characters left justified; the
       process state, 11 characters left justified (see ps(1)); the six 11-character numbers also
       held  in  the  process's  #c/cputime  file,  and the amount of memory used by the process,
       except its stack, in units of 1024 bytes.

       The text file is a pseudonym for the file from which the process was  executed;	its  main
       use is to recover the symbol table of the process.

       The  wait  file	may  be  read to recover Waitmsg records from the exiting children of the
       process.  If the process has no extant children, living or exited, a  read  of  wait  will
       block.	It  is an error for a process to attempt to read its own wait file when it has no
       children.  When a process's wait file is being read, the process will draw an error if  it
       attempts  a  wait  system call; similarly, if a process is in a wait system call, its wait
       file cannot be read by any process.

       Textual messages written to the ctl file control  the  execution  of  the  process.   Some
       require that the process is in a particular state and return an error if it is not.

       stop	 Suspend execution of the process, putting it in the Stopped state.

       start	 Resume execution of a Stopped process.

       waitstop  Do  not  affect  the  process	directly but, like all other messages ending with
		 stop, block the process writing the ctl file until the target process is in  the
		 Stopped  state  or  exits.  Also like other stop control messages, if the target
		 process would receive a note while the message is pending, it is instead stopped
		 and the debugging process is resumed.

       startstop Allow a Stopped process to resume, and then do a waitstop action.

       hang	 Set  a  bit in the process so that, when it completes an exec(2) system call, it
		 will enter the Stopped state before returning to user mode.  This bit is  inher-
		 ited across a fork(2).

       nohang	 Clear the hang bit.

       kill	 Kill the process the next time it crosses the user/kernel boundary.

       Strings	written to the note file will be posted as a note to the process (see notify(2)).
       The note should be less than characters long; the last character is reserved for a  termi-
       nating  NUL character.  A read of at least characters will retrieve the oldest note posted
       to the process and prevent its delivery to the process.	The notepg file is  similar,  but
       the  note  will	be delivered to all the processes in the target process's note group (see
       fork(2)).  However, if the process doing the write is in the group, it  will  not  receive
       the note.  The notepg file is write-only.

       The  textual  noteid  file may be read to recover an integer identifying the note group of
       the process (see RFNOTEG in fork(2)).  The file may be written to  cause  the  process  to
       change to another note group, provided the group exists and is owned by the same user.


       debugger(2), mach(2), cons(3)



All times are GMT -4. The time now is 05:06 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password