.. include:: ../header.txt

.. _jobs:

Job or Process Control
===========================

.. _background:

Background Processes
---------------------

.. index:: background process, &

The default behavior of processes started from the command line is to run in
the foreground, meaning that they take over the terminal and the shell command
prompt is not seen again until the program ends. By putting the **&** at
the end of command line entry places the new process in the background.  Then
the command is displayed so that additional commands may be entered in the same
terminal.

.. seealso:: Examples in section 5.11 and 5.12 of the text book.


.. _ps:

:command:`ps`
-------------

.. index:: ps
.. program:: ps
.. describe:: ps

    Report a snapshot of the current processes.

SYNOPSIS

    :command:`ps` [OPTIONS]

.. note::

    The :command:`ps` command is one that, unfortunately, has different
    options for the BSD and AT&T System V versions of Unix.  The GNU version
    of :command:`ps`, which is used on Linux system, supports both set of
    options.  If the options begin with a dash (``-``), then it is assumed
    to be a System V option, without the dash, means that that BSD options
    are being used.

OPTIONS

    .. option:: -e
    
        List all running processes

    .. option:: -u **userid**
    
        List all processes owned by a specified user

    .. option:: -f
    
        Display a full listing of the processes

    .. option:: -H
    
        List processes as a tree showing parent -- child process
        relationships

    .. option:: -a

        List all processes associated with a terminal.  This should be most,
        if not all, of the user level processes on the system.
    

.. _kill:

:command:`kill`
----------------

.. index:: kill
.. program:: kill
.. describe:: kill

    Send a signal to a process

SYNOPSIS

    :command:`kill` [-s signal | -p] pid

    :command:`kill` -l [signal]

We usually think of using the :command:`kill` command to terminate a
process. Process termination occurs when the sent signal is not *caught* by
the process.  Processes may be programmed to catch and handle any signal
except `SIGKILL`, `9`. When a signal is caught, it interrupts what it is
currently doing and executes a function known as the signal handler.

======= ==========  =====================================
Signal	  Value	     Comment
======= ==========  =====================================
SIGHUP	     1	     Hangup detected on controlling terminal
SIGINT	     2	     Interrupt from keyboard (Default)
SIGQUIT	     3	     Quit from keyboard
SIGILL	     4	     Illegal Instruction
SIGABRT	     6	     Abort signal from abort(3)
SIGFPE	     8	     Floating point exception
SIGKILL	     9	     Kill signal
SIGSEGV	    11	     Invalid memory reference
SIGPIPE	    13	     Broken pipe: write to pipe with no readers
SIGALRM	    14	     Timer signal from alarm(2)
SIGTERM	    15	     Termination signal
SIGUSR1	 30,10,16    User-defined signal 1
SIGUSR2	 31,12,17    User-defined signal 2
SIGCHLD	 20,17,18    Child stopped or terminated
SIGCONT	 19,18,25    Continue if stopped
SIGSTOP	 17,19,23    Stop process
SIGTSTP	 18,20,24    Stop typed at tty
SIGTTIN	 21,21,26    tty input for background process
======= ==========  =====================================

After starting a process, pressing `<cntrl>-c` on the keyboard sends `SIGINT`.

After starting a process, pressing `<cntrl>-z` on the keyboard sends
`SIGSTOP`. Source code debugging programs also often use `SIGSTOP`.

Daemon processes, such as server programs, are often programmed to handle
`SIGHUP` by re-reading their configuration files.  Thus it is common for a
system administrator to enact configuration changes by sending the `SIGHUP`
signal rather than restarting the service.

.. _jobscmd:

:command:`jobs`
----------------

.. index:: jobs
.. program:: jobs
.. describe:: jobs

   List the active jobs from the current shell.  Active jobs are current
   background and stopped processes started from current shell (not
   processes started from other running shells from the same user). The
   listed number for each job can be used with the `fg` and `bg` commands.

.. _fg:

:command:`fg`
-------------

.. index:: fg
.. program:: fg
.. describe:: fg

   Move a background or stopped process to the foreground. Use the `%` key
   along with job number from the `jobs` command to identify the target job.

.. _bg:

:command:`bg`
-------------

.. index:: bg
.. program:: bg
.. describe:: bg

   Restart a stopped process as background process. Use the `%` key
   along with job number from the `jobs` command to identify the target job.

In the following example, we use `sleep` as a convenient command to
illustrate control of jobs.  The first sleep process was started in the
foreground, then stopped and restarted as a background process. The second
sleep process was started in the background and then moved to the
foreground.

::

    1008 timber:~
    $ sleep 120
    ^Z
    [1]+  Stopped                 sleep 120
    1009 timber:~
    $ sleep 200 &
    [2] 4110
    1010 timber:~
    $ jobs
    [1]+  Stopped                 sleep 120
    [2]-  Running                 sleep 200 &
    1011 timber:~
    $ bg %1
    [1]+ sleep 120 &
    1012 timber:~
    $ jobs
    [1]-  Running                 sleep 120 &
    [2]+  Running                 sleep 200 &
    1013 timber:~
    $ fg %2
    sleep 200


.. _nohup:

:command:`nohup`
----------------

.. index:: nohup
.. program:: nohup
.. describe:: nohup

    Prevent termination of the process when the user logs out.

SYNOPSIS

    :command:`nohup` *command* [ command options and arguments ] &

Normally, background processes are terminated when the user logs out.
:command:`nohup` prevents this from happening.