\section{Creating Processes}

\begin{frame}
   {Creating Processes}

   \begin{itemize}
      \item First user process is called \textbf{init} and has
      \texttt{pid = 1}
      \item Subsequent processes are \textbf{forked} from
      \textbf{init} or other running processes
      \item Forking from a \textbf{parent} produces a
      \textbf{child} process, in every way a equal and a peer
      of the parent.
      \item If the parent dies, the child is ``adopted'' by
      \textbf{init}
      \item There are also kernel-created processes; these have
      names surrounded by \verb?[..]? in the output from
      \textbf{ps}
   \end{itemize}
   \begin{info}
      \textbf{systemd}-based systems run a special process
      named \textbf{kthreadd} with \verb?pid=2? whose job is
      to adopt orphaned children, who will then show
      \verb?ppid=2?.
   \end{info}

\end{frame}

\cprotect\note{


   An average \textbf{Linux} system is always creating new
   processes.  This is often called \textbf{forking}; the
   original parent process keeps running while the new
   child process starts.

   Often rather than just a fork, one follows it with an
   \textbf{exec}, where the parent process terminates and
   the child process inherits the process ID of the parent.
   The term \textbf{fork and exec} is used so often people
   think of it sometimes as one word.

   Older \textbf{UNIX} systems often used a program called
   \textbf{spawn} which is similar in many ways to fork and
   exec, but differs in details.  It is not part of the
   \textbf{POSIX} standard and is not a normal part of
   \textbf{Linux}.

   To see how new processes may start, consider a web
   server that handles many clients.  It may launch a new
   process every time a new connection is made with a
   client.  On the other hand, it may simply start only a
   new \textbf{thread} as part of the same process; in
   \textbf{Linux} there really is not much difference on a
   technical level between creating a full process or just
   a new thread as each mechanism takes about the same time
   and uses roughly the same amount of resources.

   As another example, the \textbf{sshd} daemon is started
   when the \textbf{init} process executes the
   \textbf{sshd} init script, which then is responsible for
   launching the \textbf{sshd daemon}.  This daemon process
   listens for \textbf{ssh} requests from remote users.

   When a request is received, \textbf{sshd} creates a new
   copy of itself to service the request.  Each remote user
   gets their own copy of the \textbf{sshd} daemon running
   to service their remote login. The \textbf{sshd} process
   will start the login program to validate the remote
   user.  If the authentication succeeds, the login process
   will fork off a shell (say \textbf{bash}) to interpret
   the user commands, and so on.

   Internal kernel processes take care of maintenance work,
   such as making sure buffers get flushed out to disk, that
   the load on different CPUs is balanced evenly, that
   device drivers handle work that has been queued up for
   them to do, etc. These processes often run as long as the
   system is running, sleeping except when they have
   something to do.

}



\begin{frame}
   {Creating Processes in a Command Shell}

   When a user executes a command in a command shell
   interpreter, such as \textbf{bash}:
   \begin{itemize}
      \item A new process is created (forked from the user's
      login shell)
      \item A wait system call puts the parent shell process to
      sleep
      \item The command is loaded onto the child process's space
      via the \textbf{exec} system call, replacing
      \textbf{bash}
      \item The command completes executing, and the child
      process dies via the exit system call
      \item The parent shell is re-awakened by the death of the
      child process and proceeds to issue a new shell prompt
      \item The parent shell then waits for the next command
      request from the user, at which time the cycle will be
      repeated

   \end{itemize}

\end{frame}

\cprotect\note{

   If a command is issued for \textbf{background}
   processing (by adding an ampersand (\texttt{\&}) at the
   end of the command line) the parent shell skips the
   wait request and is free to issue a new shell prompt
   immediately allowing the background process to execute
   in parallel.  Otherwise, for \textbf{foreground}
   requests, the shell waits until the child process has
   completed or is stopped via a signal.

   Some shell commands (such as \textbf{echo} and
   \textbf{kill}) are built into the shell itself and do
   not involve loading of program files.  For these
   commands, neither a \textbf{fork} nor an \textbf{exec} is issued
   for the execution.
}


