placer le script shell sous le contrôle SystemD

En supposant que j'ai un script shell comme ceci: –

#!/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 

À partir du script bash, nous pouvons essentiellement faire 3 choses:

  1. démarrez le server cherrypy en appelant ./cherrypy_server.sh start
  2. Arrêtez le server cherrypy en appelant ./cherrypy_server.sh stop
  3. redémarrez le server cherrypy en appelant ./cherrypy_server.sh restart

Comment placer ce script shell sous contrôle cherrypy.service file cherrypy.service (avec l'objective évident d'avoir démarré le server cherrypy lors de la redémarrage d'une machine)?

Exemple de reference du file de service systemd ici – https://wiki.archlinux.org/index.php/Systemd#Using_service_file

J'utilise ceux pour Sick Beard et SabNZBd, deux applications python / cherrypy. La différence consiste à savoir quand utiliser "forking". Cela indique essentiellement à Systemd que le binary principal va forger des choses de sorte qu'il faut deviner le PID à partir d'un file. WantedBy est juste pour définir la cible qui exigera que cela démarre, pensez-le comme runlevel. Vous remarquerez également que la deuxième définition utilise un directory pour conserver les informations d'exécution, car cela crée un $process-$port pour chaque démon démarré (vous pouvez avoir plusieurs daemons engendrés par le principal sur différents ports).

IMO, vous pouvez append le script sur ExecStart et assurez-vous qu'il est en forking et append un moyen de find le file PID principal, ou au less un file PID qui signifie «s'il est mort, redémarrez le service».

Peut-être que l'idéal est de créer 1 file de service «simple» pour chaque démon?

 [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 

Et celui-ci est le fourrage

 [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