Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (plan9)
Apropos / Subsearch:
optional field

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  pro-
       cesses;  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

       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 sys-
       tem 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

       start     Resume execution of a Stopped process.

       waitstop  Do  not  affect the process directly but, like all other mes-
                 sages 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

       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 inherited across a

       nohang    Clear the hang bit.

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

       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 terminating 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, pro-
       vided the group exists and is owned by the same user.


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