\section{Signals}

\begin{frame}
   {What are Signals?}
   \begin{itemize}
      \item Signals are generally sent by one of two methods
      \begin{itemize}
         \item From the kernel to a user process as a
         result of an exception or programming error
         \item From a user process (via system call) to
         the kernel which will send it to a user
         process
      \end{itemize}
      \item Signals can only be sent between processes owned
      by the same user or from a process owned by the
      superuser to any process
   \end{itemize}

\end{frame}

\cprotect\note{

   Signals are one of the oldest methods of Inter-Process
   Communication (\textbf{IPC}) and are used to notify processes
   about \textbf{asynchronous} events (or \textbf{exceptions}).

   By asynchronous, we mean the signal-receiving process may:
   \begin{itemize}
      \item
      Not expect the event to occur.
      \item
      Expect the event, but not know when it is most likely to occur.
   \end{itemize}
   For example, if a user decides to terminate a running
   program, it could send a signal to the process through the
   kernel to interrupt and kill the process.


   When a process receives a signal, what it does will depend
   on the way the program is written. It can take specific
   actions, coded into the program, to handle the signal or
   it can just respond according to system defaults. Two
   signals:
   \begin{itemize}
      \item \verb?SIGKILL?  (\#9)
      \item \verb?SIGSTOP?  (\#19)
   \end{itemize}
   cannot be  handled and will always terminate the program.

}

\section{Types of Signals}
\begin{frame}
   {Types of Signals and Available Signals}

   \begin{itemize}
      \item Exceptions detected by hardware (illegal memory reference, etc.)
      \item Exceptions such as process termination or sent by user
      \item \verb?kill -l? shows all available signals:
   \end{itemize}
   \begin{figure}[H]
      \includegraphics[height=2.52in]{IMAGES/sigkill}
      \caption{Available Signals}
   \end{figure}


\end{frame}

\cprotect\note{

   There are a number of different types of signals and the
   signal sent by the kernel indicates what type of event (or
   exception) occurred.  Generally, signals are used to handle
   two things, 1) exceptions detected by hardware (such as an
   illegal memory reference), or 2) exceptions generated by the
   environment (such as the premature death of a process from
   the user's terminal).

   To see a list of the signals in \textbf{Linux}, along with their
   numbers use \texttt{kill -l} (that is the letter l not a
   one).  The meaning attached to the signal type indicates
   what event occurred causing the signal to be sent to a
   process (when sent from the kernel).

   The signals from \verb?SIGRTMIN? on are termed \textbf{real-time signals}
   and are a relatively recent addition. They have no
   predefined purpose, and differ in some important ways
   from normal signals; they can be queued up and are
   handled in a \textbf{FIFO} (First In First Out) order.

   The meaning attached to the signal type indicates what
   event caused the signal to be sent. While users can
   explicitly send any signal type to one of their
   processes, the meaning attached may no longer be implied
   by the signal number or type, and can be used in any way
   that the process desires.

   Typing \verb?man 7 signal? will give further documentation.

}

\section{kill}
\begin{frame}
   {kill}

   \begin{itemize}
      \item Users invoke \textbf{kill} to send
      signals to other processes
      \item \textbf{kill} is a misnomer, should be
      send-signal
      \item \texttt{kill [pid]} sends the SIGTERM signal, by
      default
      \begin{itemize}
         \item If process does not handle (or catch) or
         ignore SIGTERM, then process is killed
      \end{itemize}
      \item \texttt{kill -signal [pid]} sends a specific
      signal to a process
   \end{itemize}

\end{frame}

\cprotect\note{

   Since a process cannot send a signal directly to another
   process, it must ask the kernel to send the signal.  Users
   (including the superuser) can send signals to other
   processes (programs) by using \textbf{kill}.

   \textbf{kill} is really a bad name.  Although it
   is used a lot to kill processes, it is really designed to
   send signals to processes.  Therefore, \textbf{kill} is not
   really accurate.

   The default signal sent is \texttt{SIGTERM} (\#15) which can
   be handled, or ignored by the receiving process in order to
   prevent its death.  It is preferable to use this signal to
   give the process a chance to clean up after itself. If this
   signal is ignored, the user can usually send a SIGKILL (\#9)
   signal, which cannot be ignored, to kill the process.

   We use \textbf{kill} to send signals (by either
   number or name):

   \begin{cmd}
$ kill 1234
$ kill -9 1234
$ kill -SIGTERM 1234
   \end{cmd}
}


\section{killall and pkill}
\begin{frame}
   {killall}

   \begin{itemize}
      \item Uses process name instead of pid
      \item Sends signal to all processes with that name
      (assuming appropriate privileges)
   \end{itemize}

\end{frame}

\cprotect\note{

   \begin{cmd}
$ killall bash
$ killall -9 bash
$ killall -SIGKILL bash
   \end{cmd}
}


\begin{frame}
   {pkill}

   \begin{itemize}
      \item Sends signals to process using name
      \begin{cmd}
$ pkill [-signal] [options] [pattern]
      \end{cmd}
      \begin{itemize}
         \item \texttt{-P}: ppid
         \item \texttt{-G}: gid
         \item \texttt{-U}: uid
      \end{itemize}
   \end{itemize}

\end{frame}

\cprotect\note{

   Similar to \textbf{kill} but uses name instead of pid.

   Make \textbf{rsyslog} reread its configuration file:
   \begin{cmd}
$ pkill -HUP rsyslogd
   \end{cmd}
}


