6 votos

la colocación de secuencia de comandos de shell bajo control de systemd

Suponiendo que tengo un shell script como este:-

#!/bin/sh
# cherrypy_server.sh

PROCESSES=10
THREADS=1 # threads per process
BASE_PORT=3035 # the first port used
# you need to make the PIDFILE dir and insure it has the right permissions
PIDFILE="/var/run/cherrypy/myproject.pid"
WORKDIR=`dirname "$0"`
cd "$WORKDIR"

cp_start_proc()
{
 N=$1
 P=$(( $BASE_PORT + $N - 1 ))
 ./manage.py runcpserver daemonize=1 port=$P pidfile="$PIDFILE-$N" threads=$THREADS request_queue_size=0 verbose=0
}

cp_start()
{
 for N in `seq 1 $PROCESSES`; do
  cp_start_proc $N
 done
}

cp_stop_proc()
{
 N=$1
 #[ -f "$PIDFILE-$N" ] && kill `cat "$PIDFILE-$N"`
 [ -f "$PIDFILE-$N" ] && ./manage.py runcpserver pidfile="$PIDFILE-$N" stop
 rm -f "$PIDFILE-$N"
}

cp_stop()
{
 for N in `seq 1 $PROCESSES`; do
  cp_stop_proc $N
 done
}

cp_restart_proc()
{
 N=$1
 cp_stop_proc $N
 #sleep 1
 cp_start_proc $N
}

cp_restart()
{
 for N in `seq 1 $PROCESSES`; do
  cp_restart_proc $N
 done
}

case "$1" in
 "start")
  cp_start
 ;;
 "stop")
  cp_stop
 ;;
 "restart")
  cp_restart
 ;;
 *)
  "$@"
 ;;
esac

A partir de la secuencia de comandos bash, en esencia podemos hacer 3 cosas:

  1. iniciar el cherrypy servidor llamando ./cherrypy_server.sh start
  2. detener el cherrypy servidor llamando ./cherrypy_server.sh stop
  3. reinicie el cherrypy servidor llamando ./cherrypy_server.sh restart

¿Cómo puedo realizar esta secuencia de comandos de shell bajo systemd's de control como cherrypy.service archivo (con el obvio objetivo de tener systemd iniciar el cherrypy servidor cuando un equipo se ha reiniciado)?

Referencia systemd servicio de archivo de ejemplo aquí - https://wiki.archlinux.org/index.php/Systemd#Using_service_file

1voto

coredump Puntos 9198

Yo uso los Enfermos de la Barba y SabNZBd, dos de python/cherrypy aplicaciones. La diferencia es saber cuando usar 'fork'. Que básicamente le dice a systemd que el principal binary tenedor cosas, así que tiene que adivinar el PID de un archivo. WantedBy es solo para definir el objetivo que se requieren esto para empezar, creo que en cuanto al nivel de ejecución. Notarás también que la segunda definición utiliza un directorio para guardar la información de la carrera, que es debido a que se crea un $process-$port para cada empezó demonio (usted puede tener muchos demonios generado por el principal en puertos diferentes).

La OMI puede agregar la secuencia de comandos en ExecStart y asegúrese de que es forking y agregue un camino para que se encuentre el principal PIDfile, o al menos un PIDfile que significa 'si este está muerto, reinicie el servicio'.

Tal vez lo ideal es crear 1 servicio de archivo con la 'simple' para cada demonio?

[Unit]
Description=Internet PVR for your TV Shows
After=cryptsetup.target

[Service]
ExecStart=/usr/bin/python2 /path/to/Sick-Beard/SickBeard.py
Type=simple
User=<user under which to run>
Group=<group of said user>

[Install]
WantedBy=multi-user.target

Y esta es la que se bifurcan uno

[Unit]
Description=Binary Newsreader
After=cryptsetup.target

[Service]
ExecStart=/usr/bin/python2 /path/to/sabnzbd/SABnzbd.py -d -f /path/to/inifile --pid /run/sabnzbd
Type=forking
PIDFile=/run/sabnzbd/sabnzbd-8080.pid
User=<user to run the process>
Group=<group of said user>

[Install]
WantedBy=multi-user.target

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: