Esecuzione di un eseguibile come servizio in Debian 8

Ecco i dettagli della versione della macchina Debian che sto usando:

root@my-host-name:~# cat /etc/debian_version
8.9
root@my-host-name:~# uname -a
Linux my-host-name 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 GNU/Linux
root@my-host-name:~#

Per fare il mio lavoro, accedo a questa macchina come root ed eseguo questo comando:

/usr/java/jre1.8.0_131/bin/java -jar /usr/local/jenkins/jenkins.war

Questa applicazione esegue un server Web a cui accedo da altrove.

Ho creato un utente "jenkins" regolare e senza privilegi con il quale eseguire questo account. Quando la macchina si avvia, vorrei che il comando mostrato sopra fosse eseguito automaticamente come questo nuovo utente "jenkins". Allo stesso modo, quando la macchina viene spenta, vorrei che questo processo venisse rimosso con grazia.

Suppongo che ciò che sto dicendo sia che voglio che questa applicazione funzioni come servizio. (Per favore, correggimi se non sono esattamente corretto nel mio uso del termine "servizio".)

Come posso realizzare questo?

ULTERIORI INFORMAZIONI AGGIUNTE DOPO LA PRIMA RISPOSTA INVIATA

Sembra che abbia sia systemd che init .

root@my-host-name:~# ps -elf | grep system
4 S root       156     1  0  80   0 - 10379 -      Jul31 ?        00:00:00 /lib/systemd/systemd-udevd
4 S root       157     1  0  80   0 -  7480 -      Jul31 ?        00:00:00 /lib/systemd/systemd-journald
4 S root       420     1  0  80   0 -  7083 -      Jul31 ?        00:00:00 /lib/systemd/systemd-logind
4 S message+   422     1  0  80   0 - 10713 -      Jul31 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
4 S Debian-+   812     1  0  80   0 -  8914 -      Jul31 ?        00:00:00 /lib/systemd/systemd --user
4 S root       993     1  0  80   0 -  6809 -      Aug01 ?        00:00:00 /lib/systemd/systemd --user
0 R root      5305  4936  0  80   0 -  3182 -      02:51 pts/0    00:00:00 grep system
root@my-host-name:~# ps -elf | grep init
4 S root         1     0  0  80   0 - 44052 -      Jul31 ?        00:00:01 /sbin/init
0 R root      5307  4936  0  80   0 -  3182 -      02:51 pts/0    00:00:00 grep init

Saranno in conflitto? Come interagiscono?

Inoltre, la mia directory / etc / systemd / system è un labirinto di directory e collegamenti a directory:

root@my-host-name:/etc/systemd/system# ls -l
total 48
drwxr-xr-x 2 root root 4096 Apr 13 03:45 bluetooth.target.wants
lrwxrwxrwx 1 root root   37 Apr 13 03:45 dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service
lrwxrwxrwx 1 root root   40 Apr 13 03:44 dbus-org.freedesktop.Avahi.service -> /lib/systemd/system/avahi-daemon.service
lrwxrwxrwx 1 root root   40 Apr 13 03:45 dbus-org.freedesktop.ModemManager1.service -> /lib/systemd/system/ModemManager.service
lrwxrwxrwx 1 root root   53 Apr 13 03:45 dbus-org.freedesktop.nm-dispatcher.service -> /lib/systemd/system/NetworkManager-dispatcher.service
lrwxrwxrwx 1 root root   32 Apr 13 03:45 display-manager.service -> /lib/systemd/system/gdm3.service
drwxr-xr-x 2 root root 4096 Apr 13 03:37 getty.target.wants
drwxr-xr-x 2 root root 4096 Apr 13 03:45 graphical.target.wants
drwxr-xr-x 2 root root 4096 Apr 13 03:37 halt.target.wants
drwxr-xr-x 2 root root 4096 Apr 13 03:45 hibernate.target.wants
drwxr-xr-x 2 root root 4096 Apr 13 03:45 hybrid-sleep.target.wants
drwxr-xr-x 2 root root 4096 Jul 13 09:21 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Apr 13 03:37 paths.target.wants
drwxr-xr-x 2 root root 4096 Apr 13 03:37 poweroff.target.wants
drwxr-xr-x 2 root root 4096 Apr 13 03:37 reboot.target.wants
drwxr-xr-x 2 root root 4096 Apr 13 03:44 sockets.target.wants
lrwxrwxrwx 1 root root   31 Apr 13 03:45 sshd.service -> /lib/systemd/system/ssh.service
drwxr-xr-x 2 root root 4096 Apr 13 03:45 suspend.target.wants
lrwxrwxrwx 1 root root   35 Apr 13 03:37 syslog.service -> /lib/systemd/system/rsyslog.service

Questo afferma qualcosa in più sul meccanismo di avvio utilizzato dalla mia macchina Debian? Dato questo contenuto di directory, è ancora corretto inserire jenkins.service proposto direttamente in / etc / systemd / system, o devo provare a capire questo schema di collegamenti e provare a replicarlo?

Probabilmente stai eseguendo systemd come sistema inint. Per configurare il servizio, ad esempio è necessario creare il file di unità necessario /etc/systemd/system/jenkins.service.

[Unit]
Description=Jenkins
After=network.target

[Service]
Type=simple
ExecStart=/usr/java/jre1.8.0_131/bin/java -jar /usr/local/jenkins/jenkins.war
User=jenkins

[Install]
WantedBy=multi-user.target

Per abilitare l'esecuzione del servizio all'avvio, eseguire systemctl enable jenkins. systemctl start jenkins.serviceavvia il servizio dalla riga di comando. Per la documentazione completa, consultare le pagine man . La home page di Systemd ha anche molto materiale per ulteriori studi.

Nel caso in cui si utilizzi init in stile SysV, è necessario scrivere uno script di init che avvia il demone /etc/init.d/, ad esempio /etc/init.d/jenkins(e contrassegnarlo come eseguibile).

#!/bin/sh
### BEGIN INIT INFO
# Provides:          jenkins
# Default-Start:     2 3 4 5
# Default-Stop:      1
### END INIT INFO

EXEC="/usr/java/jre1.8.0_131/bin/java"
ARGS="-jar /usr/local/jenkins/jenkins.war"
USER="jenkins"
PIDFILE="/run/jenkins.pid"

. /lib/lsb/init-functions

case "$1" in
  start)
    start-stop-daemon --start --background --chuid $USER \
                       --make-pidfile --pidfile $PIDFILE --exec $EXEC -- $ARGS
    ;;
  stop)
    start-stop-daemon --stop --pidfile $PIDFILE --exec $EXEC
    ;;
  *)
    echo "Usage: /etc/init.d/jenkins {start|stop}"
    exit 1
    ;;
esac

exit 0

Nota che devi fork il tuo servizio nello script di init, altrimenti lo script non si chiude, in questo esempio start-stop-daemon  fa il fork ( --background) e cambia user ( --chuid). Per studiare come vengono avviati altri servizi nel tuo sistema usando gli script init puoi studiare i file /etc/init.d/.

Per abilitare l'avvio del servizio all'avvio, eseguire update-rc.d jenkins enable. Per avviare il servizio, eseguire il nuovo script /etc/init.d/jenkins start.

Gli script di inizializzazione compatibili con LSB sono anche compatibili con i sistemi precedenti. Ricordarsi di fare /lib/lsb/init-functionsin modo che systemctl funzioni in modo trasparente durante l'esecuzione diretta dello script.

Il wiki Debian per LSBInitScripts fornisce maggiori dettagli sulle opzioni disponibili, come l'avvio del servizio dopo / prima di altri servizi.