From 9dc6cdc03933d3e2ff7771e309546a1cc4c8c5da Mon Sep 17 00:00:00 2001 From: "Matthias P. Braendli" Date: Wed, 24 Jan 2018 02:15:24 +0100 Subject: Remove GNU Screen, mention systemd --- systemenvironments.tex | 42 +++++++++++++++++++----------------------- 1 file changed, 19 insertions(+), 23 deletions(-) diff --git a/systemenvironments.tex b/systemenvironments.tex index 4e8b59f..9b40c1e 100644 --- a/systemenvironments.tex +++ b/systemenvironments.tex @@ -58,32 +58,21 @@ Services running in a production environment are usually administered remotely, and must be able to run without user intervention, or connection. Traditionally, such services are implemented (in UNIX terminology) as `daemons'. These are started and stopped using the init system contained within the distribution. -The ODR-mmbTools cannot daemonise themselves, so this requires another approach: - -\paragraph{Screen multiplexer} -A simple approach is to use a screen multiplexer such as \emph{GNU Screen} or -\emph{tmux} - either of these can be used to launch a session from which the -user can detach, and later re-attach at will - leaving the tools running within -it. Please see the relevant manpages for more information. - -Although a screen multiplexer alone permits the tools to run without a user -being connected, it alone cannot automatically restart failed processes, and it -is unable to provide warnings in the case of a problem. - -The dab-scripts, already mentioned in \ref{usingexistingwebstreams}, can be -employed to monitor the processes and (if necessary) restart them, and send an -alert via email. +As the ODR-mmbTools cannot daemonise themselves, a process supervisor is used. \paragraph{supervisord} -As an alternative to using the scripts, the execution of the tools can also be -carried out by a dedicated tool. \texttt{supervisor}\footnote{\url{http://supervisord.org}} -is (as the name implies) such a tool. +One possibility is to use +\texttt{supervisord}\footnote{\url{http://supervisord.org}} +which can launch the tools and monitor their proper execution. It will +restart the processes and optionally inform the operator by email. -Once installed, supervisor reads its configuration file in \texttt{/etc/supervisor.conf} +Once installed, supervisord reads its configuration file in +\texttt{/etc/supervisor.conf} and launches the processes that are to be monitored. Each process is described by a file. The following example assumes the tools are run as user \texttt{odr}, and that the multiplex configuration is in \texttt{/home/odr/config.mux}, and -that ODR-DabMux is to be launched.The logs of ODR-DabMux is written to the +that ODR-DabMux is to be launched. +The standard output and standard error streams of ODR-DabMux are written to the specified log files. \begin{lstlisting} @@ -97,13 +86,13 @@ stdout_logfile=/home/odr/logs/mux.out.log stderr_logfile=/home/odr/logs/mux.err.log \end{lstlisting} -Once this configuration has been added to the supervisor configuration, the +Once this configuration has been added to the supervisord configuration, the settings have to be re-read using: \begin{lstlisting} supervisorctl reread \end{lstlisting} -In order for supervisor to start managing and running this process, it needs to +In order for supervisord to start managing and running this process, it needs to be added: \begin{lstlisting} @@ -115,10 +104,17 @@ achieved by customising the configuration template above. Examples are provided in the \texttt{mmbtools-aux} repository, under the \texttt{supervisor} folder - these need to be changed to reflect the paths that are in use on your system. -supervisor also includes a small web-server that can display the state of the +supervisord also includes a small web-server that can display the state of the managed processes. It is enabled with the \verb+[inet_http_server]+ setting in the configuration file. +\paragraph{systemd} +Most recent GNU/Linux distributions use \texttt{systemd} as init system, which +also can handle the supervision of processes. To achieve this, systemd unit +files have to be written for the tools. For more information, see the systemd +documentation.\sidenote{Give an example unit file} + + \subsection{Logging} Collecting information about events is essential within a production environment. This information is essential forensic analysis, and tracing sources of trouble. -- cgit v1.2.3