Ausführen einer ausführbaren Datei als Dienst unter Debian 8

1763
Dave

Hier sind die Versionsdetails des von mir verwendeten Debian-Computers:

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:~# 

Um meine Arbeit zu erledigen, logge ich mich auf dieser Maschine als root ein und führe diesen Befehl aus:

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

Diese Anwendung führt einen Webserver aus, auf den ich dann von anderen Orten aus zugreife.

Ich habe einen regulären, nicht privilegierten "Jenkins" -Benutzer erstellt, unter dem dieses Konto ausgeführt wird. Wenn der Computer hochfährt, möchte ich, dass der oben gezeigte Befehl automatisch als dieser neue Benutzer "Jenkins" ausgeführt wird. Ebenso möchte ich, wenn die Maschine heruntergefahren wird, diesen Prozess ordnungsgemäß herunterfahren.

Ich nehme an, ich sage, dass diese Anwendung als Dienst ausgeführt werden soll. (Bitte korrigieren Sie mich, wenn ich den Begriff "Service" nicht genau richtig verwende.)

Wie kann ich das erreichen?

ZUSÄTZLICHE INFORMATIONEN NACH ERSTER ANTWORT HINZUFÜGEN

Ich scheine sowohl systemd als auch init zu haben .

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 

Werden sie miteinander in Konflikt geraten? Wie spielen sie zusammen?

Außerdem ist mein Verzeichnis / etc / systemd / system ein Labyrinth von Verzeichnissen und Links zu Verzeichnissen:

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 

Gibt es zusätzliche Informationen über den Startmechanismus, den mein Debian-Rechner verwendet? Ist es angesichts dieses Verzeichnisinhalts immer noch korrekt, den vorgeschlagenen jenkins.service direkt in / etc / systemd / system abzulegen, oder muss ich versuchen, dieses Verknüpfungsmuster herauszufinden und zu replizieren?

0
Sieht so aus, als würde auf Ihrem System traditionelles SysV init (pid 1) ausgeführt. Sie sollten ein Init-Skript erstellen, systemd ist auch abwärtskompatibel mit sysv-init-Skripts. Weitere Informationen finden Sie in meiner Antwort. sebasth vor 7 Jahren 0

1 Antwort auf die Frage

2
sebasth

Wahrscheinlich führen Sie systemd als Ihr Inint-System aus. Um Ihren Dienst zu konfigurieren, müssen Sie beispielsweise die erforderliche Einheitendatei erstellen /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 

Um den Dienst zu laden, der beim Booten ausgeführt werden soll, führen Sie Folgendes aus systemctl daemon-reload. systemctl start jenkins.servicestartet den Dienst von der Kommandozeile aus. Die vollständige Dokumentation finden Sie auf den Manpages . Die Systemd -Homepage bietet außerdem viel Material für weitere Studien.

Falls Sie SysV Stil init verwenden, müssen Sie ein Init - Skript schreiben, die in Ihrem Daemon startet /etc/init.d/, zum Beispiel /etc/init.d/jenkins(und markieren Sie es ausführbar).

#!/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 " exit 1 ;; esac  exit 0 

Beachten Sie, dass Sie Ihren Service in Ihr Init-Skript einordnen müssen, andernfalls wird Ihr Skript nicht beendet. In diesem Beispiel führt der start-stop-daemon  forking ( --background) und das Ändern von user ( --chuid) aus. Um zu untersuchen, wie andere Dienste in Ihrem System mit Init-Skripts gestartet werden, können Sie die Dateien darin untersuchen /etc/init.d/.

Führen Sie den Befehl aus, um den Dienst zum Startzeitpunkt zu starten update-rc.d jenkins enable. Starten Sie das neue Skript, um den Dienst zu starten /etc/init.d/jenkins start.

LSB-kompatible Init-Skripte sind auch abwärtskompatibel. Denken Sie an die Quelle /lib/lsb/init-functionsfür systemctl, um transparent zu arbeiten, wenn Sie das Skript direkt ausführen.

Das Debian- Wiki für LSBInitScripts enthält weitere Details zu verfügbaren Optionen, z. B. das Starten des Dienstes nach / vor einem anderen Dienst.

Vielen Dank! Ich habe meinem ursprünglichen Beitrag zusätzliche Informationen über systemd vs. init hinzugefügt. Soll der von Ihnen gegebene Befehl systemctl daemon-reload && systemctl start jenkins.service von der Befehlszeile aus ausgeführt werden, damit ich den Dienst ohne Neustart starten kann? Oder soll es in ein Startskript eingefügt werden, damit der Dienst * beim Neustart gestartet wird? Dave vor 7 Jahren 0
Meine Antwort wurde bearbeitet, um das Beispiel für ein sysv-init-Skript aufzunehmen. `systemctl daemon-reload 'lädt die neue Unit-Datei. Um Ihren Dienst in systemd zu starten / stoppen / abzufragen, können Sie `systemd start / stop / status jenkins.service '(ohne Neustart) verwenden. sebasth vor 7 Jahren 0