Difference between revisions of "Process"

From Hackepedia
Jump to navigationJump to search
Line 1: Line 1:
A process is a program running in a UNIX system.  It communicates with the rest of the system by means of [[syscall]]s, [[descriptors]] or [[shared memory]].  A process is in [[protected memory]] also called [[virtual memory]] because address locations are translated by the [[kernel]] from the real physical addresses.  A process cannot read the memory of another process unless both processes share that memory which needs to be set up by both.   
+
A process is a program running in a UNIX system.  It communicates with the rest of the system or network by means of [[syscall]]s, [[descriptors]] or [[shared memory]].  A process is in [[protected memory]] also called [[virtual memory]] because address locations are translated by the [[kernel]] from the real physical addresses.  A process cannot read the memory of another process unless both processes share that memory which needs to be set up by both.   
  
 
A process is created by the [[fork]] [[syscall]] by a parent process.  The new process is also called the child.  After fork the child retains all memory and [[descriptors]] of its parent.
 
A process is created by the [[fork]] [[syscall]] by a parent process.  The new process is also called the child.  After fork the child retains all memory and [[descriptors]] of its parent.

Revision as of 08:59, 7 October 2005

A process is a program running in a UNIX system. It communicates with the rest of the system or network by means of syscalls, descriptors or shared memory. A process is in protected memory also called virtual memory because address locations are translated by the kernel from the real physical addresses. A process cannot read the memory of another process unless both processes share that memory which needs to be set up by both.

A process is created by the fork syscall by a parent process. The new process is also called the child. After fork the child retains all memory and descriptors of its parent.

A typical process is composed of data (text), uninitialized data (bss), heap and stack. Because of paging a process' text does not need to be loaded completely into memory but is loaded in chunks called pages when it tries to access an area that hasn't been paged in yet (this causes a page fault to indicate to the kernel that more data is needed). When memory pages aren't being used they can be paged out to swap to make room for more memory that other processes may require. When a threshold is reached and processes aren't active for longer periods of time they can be entirely swapped out to disk. This is rather slow and often avoided when possible. Processes can be signal'ed to stop execution, continue execution and to exit including leaving a core file for later analysis. Each process has a unique pid to identify it.


To show all processes in BSD type:

$ ps -kax

To show all processes in SYSV type:

$ ps -ef

Ending a Process

A user can end a process by killing it. The command to do this is kill(1), which takes the pid as an argument and optionally the signal which is supposed to be sent to the process. By default the TERM (15) signal is sent. It is wise to send a TERM signal to a process so that it can trap this signal and do possible safe shutdown's of open files or databases. When it is absolutely necessary to immediately kill a process the KILL (9) signal is used, the process terminates immediately without being able to safely shut anything off. Sometimes a process is "in-disk" (state D in a ps listing) meaning it is awaiting i/o from the kernel. In this state a process cannot be killed at all and it may be wedged forever until the next boot of the system.

$ kill 324
$ kill -TERM 324
$ kill -KILL 324

Here is a list of signals.

Tracing a Process in BSD

BSD has the ktrace command. With it a processes syscalls can be traced. By default ktrace writes the file "ktrace.out". To switch off tracing a simple "ktrace -C" is used. To view the contents of the tracefile you would use kdump. When you need to trace the child of a process the "-i" flag to ktrace is probably best.

12926 ls       CALL  stat(0x469b6170,0x7f7fffff7490)
12926 ls       NAMI  "."
12926 ls       RET   stat 0
12926 ls       CALL  open(0x528916,0,0)
12926 ls       NAMI  "."
12926 ls       RET   open 3
12926 ls       CALL  fchdir(0x3)
12926 ls       RET   fchdir 0
12926 ls       CALL  open(0x528916,0,0)
12926 ls       NAMI  "."
12926 ls       RET   open 4
12926 ls       CALL  open(0x423e5000,0x4,0)
12926 ls       NAMI  "."
12926 ls       RET   open 6
12926 ls       CALL  fstat(0x6,0x7f7fffff7440)
12926 ls       RET   fstat 0

Above is a snippet of a traced ls.

It is possible to see what processes are traced with the fstat command where a "tr" flag is displayed with the inode of the trace file.

$ fstat | grep mplayer
...
pbug     mplayer    11555   wd /usr     8016513 drwx------   r     8192
pbug     mplayer    11555   tr /usr     8016941 -rw-------  rw  1273886
...