Running an Executable as a Service Under Debian 8












1















Here are the version details of the Debian machine I'm using:



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


To do my work, I log into this machine as root and execute this command:



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


This application runs a web server which I then access from elsewhere.



I have created a regular, non-privileged "jenkins" user under which to run this account. When the machine boots, I'd like the command shown above to automatically run as this new "jenkins" user. Similarly, when the machine is shut down, I'd like this process to be taken down gracefully.



I suppose what I'm saying is that I want this application to run as a service. (Please correct me if I am not precisely correct in my use of the term "service".)



How may I accomplish this?



ADDITIONAL INFORMATION ADDED AFTER FIRST ANSWER POSTED



I appear to have both systemd and 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


Will they conflict? How do they interplay?



Also, my /etc/systemd/system directory is a maze of directories and links to directories:



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


Does this state anything additional about the startup mechanism my Debian machine uses? Given this directory content, is it still correct to put the proposed jenkins.service directly in /etc/systemd/system, or must I try to figure out this pattern of links and try to replicate it?










share|improve this question

























  • Looks like your system is running traditional SysV init (pid 1). You should create an init script, systemd is also backward compatible with sysv init scripts, see my answer for details.

    – sebasth
    Aug 2 '17 at 18:26
















1















Here are the version details of the Debian machine I'm using:



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


To do my work, I log into this machine as root and execute this command:



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


This application runs a web server which I then access from elsewhere.



I have created a regular, non-privileged "jenkins" user under which to run this account. When the machine boots, I'd like the command shown above to automatically run as this new "jenkins" user. Similarly, when the machine is shut down, I'd like this process to be taken down gracefully.



I suppose what I'm saying is that I want this application to run as a service. (Please correct me if I am not precisely correct in my use of the term "service".)



How may I accomplish this?



ADDITIONAL INFORMATION ADDED AFTER FIRST ANSWER POSTED



I appear to have both systemd and 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


Will they conflict? How do they interplay?



Also, my /etc/systemd/system directory is a maze of directories and links to directories:



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


Does this state anything additional about the startup mechanism my Debian machine uses? Given this directory content, is it still correct to put the proposed jenkins.service directly in /etc/systemd/system, or must I try to figure out this pattern of links and try to replicate it?










share|improve this question

























  • Looks like your system is running traditional SysV init (pid 1). You should create an init script, systemd is also backward compatible with sysv init scripts, see my answer for details.

    – sebasth
    Aug 2 '17 at 18:26














1












1








1








Here are the version details of the Debian machine I'm using:



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


To do my work, I log into this machine as root and execute this command:



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


This application runs a web server which I then access from elsewhere.



I have created a regular, non-privileged "jenkins" user under which to run this account. When the machine boots, I'd like the command shown above to automatically run as this new "jenkins" user. Similarly, when the machine is shut down, I'd like this process to be taken down gracefully.



I suppose what I'm saying is that I want this application to run as a service. (Please correct me if I am not precisely correct in my use of the term "service".)



How may I accomplish this?



ADDITIONAL INFORMATION ADDED AFTER FIRST ANSWER POSTED



I appear to have both systemd and 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


Will they conflict? How do they interplay?



Also, my /etc/systemd/system directory is a maze of directories and links to directories:



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


Does this state anything additional about the startup mechanism my Debian machine uses? Given this directory content, is it still correct to put the proposed jenkins.service directly in /etc/systemd/system, or must I try to figure out this pattern of links and try to replicate it?










share|improve this question
















Here are the version details of the Debian machine I'm using:



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


To do my work, I log into this machine as root and execute this command:



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


This application runs a web server which I then access from elsewhere.



I have created a regular, non-privileged "jenkins" user under which to run this account. When the machine boots, I'd like the command shown above to automatically run as this new "jenkins" user. Similarly, when the machine is shut down, I'd like this process to be taken down gracefully.



I suppose what I'm saying is that I want this application to run as a service. (Please correct me if I am not precisely correct in my use of the term "service".)



How may I accomplish this?



ADDITIONAL INFORMATION ADDED AFTER FIRST ANSWER POSTED



I appear to have both systemd and 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


Will they conflict? How do they interplay?



Also, my /etc/systemd/system directory is a maze of directories and links to directories:



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


Does this state anything additional about the startup mechanism my Debian machine uses? Given this directory content, is it still correct to put the proposed jenkins.service directly in /etc/systemd/system, or must I try to figure out this pattern of links and try to replicate it?







linux debian debian-jessie






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 2 '17 at 17:06







Dave

















asked Aug 2 '17 at 16:12









DaveDave

244218




244218













  • Looks like your system is running traditional SysV init (pid 1). You should create an init script, systemd is also backward compatible with sysv init scripts, see my answer for details.

    – sebasth
    Aug 2 '17 at 18:26



















  • Looks like your system is running traditional SysV init (pid 1). You should create an init script, systemd is also backward compatible with sysv init scripts, see my answer for details.

    – sebasth
    Aug 2 '17 at 18:26

















Looks like your system is running traditional SysV init (pid 1). You should create an init script, systemd is also backward compatible with sysv init scripts, see my answer for details.

– sebasth
Aug 2 '17 at 18:26





Looks like your system is running traditional SysV init (pid 1). You should create an init script, systemd is also backward compatible with sysv init scripts, see my answer for details.

– sebasth
Aug 2 '17 at 18:26










1 Answer
1






active

oldest

votes


















3














You are likely running systemd as your inint system. To configure your service, you need to create the necessary unit file for example /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


To enable the service to be run at boot, run systemctl enable jenkins. systemctl start jenkins.service starts the service from command line.
For full documentation, see man pages. Systemd home page also has plenty of material for further study.



In case you are using SysV style init, you need to write an init script which starts your daemon in /etc/init.d/, for example /etc/init.d/jenkins (and mark it executable).



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


Note that you must fork your service in your init script, otherwise your script doesn't exit, in this example start-stop-daemon does forking (--background) and changing user (--chuid). To study how other services are started in your system using init scripts you can study the files in /etc/init.d/.



To enable the service to start at boot time, run update-rc.d jenkins enable. To start the service run your new script /etc/init.d/jenkins start.



LSB compatible init scripts are also systemd backwards compatible. Remember to source /lib/lsb/init-functions for systemctl to work transparently when executing the script directly.



Debian wiki for LSBInitScripts provides more details about available options, such as starting the service after/before other service.






share|improve this answer


























  • Thank you! I have added additional information to my original post about systemd vs. init. Is the command you gave, systemctl daemon-reload && systemctl start jenkins.service, intended to be run from the command line so I can start the service without rebooting? Or, is it intended to be inserted into some startup script, so that the service will start upon rebooting?

    – Dave
    Aug 2 '17 at 16:55











  • Edited my answer to include sysv init script example. systemctl daemon-reload loads the new unit file. To start/stop/query your service in systemd you can use systemd start/stop/status jenkins.service respectively (without reboot).

    – sebasth
    Aug 2 '17 at 17:30











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1236961%2frunning-an-executable-as-a-service-under-debian-8%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














You are likely running systemd as your inint system. To configure your service, you need to create the necessary unit file for example /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


To enable the service to be run at boot, run systemctl enable jenkins. systemctl start jenkins.service starts the service from command line.
For full documentation, see man pages. Systemd home page also has plenty of material for further study.



In case you are using SysV style init, you need to write an init script which starts your daemon in /etc/init.d/, for example /etc/init.d/jenkins (and mark it executable).



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


Note that you must fork your service in your init script, otherwise your script doesn't exit, in this example start-stop-daemon does forking (--background) and changing user (--chuid). To study how other services are started in your system using init scripts you can study the files in /etc/init.d/.



To enable the service to start at boot time, run update-rc.d jenkins enable. To start the service run your new script /etc/init.d/jenkins start.



LSB compatible init scripts are also systemd backwards compatible. Remember to source /lib/lsb/init-functions for systemctl to work transparently when executing the script directly.



Debian wiki for LSBInitScripts provides more details about available options, such as starting the service after/before other service.






share|improve this answer


























  • Thank you! I have added additional information to my original post about systemd vs. init. Is the command you gave, systemctl daemon-reload && systemctl start jenkins.service, intended to be run from the command line so I can start the service without rebooting? Or, is it intended to be inserted into some startup script, so that the service will start upon rebooting?

    – Dave
    Aug 2 '17 at 16:55











  • Edited my answer to include sysv init script example. systemctl daemon-reload loads the new unit file. To start/stop/query your service in systemd you can use systemd start/stop/status jenkins.service respectively (without reboot).

    – sebasth
    Aug 2 '17 at 17:30
















3














You are likely running systemd as your inint system. To configure your service, you need to create the necessary unit file for example /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


To enable the service to be run at boot, run systemctl enable jenkins. systemctl start jenkins.service starts the service from command line.
For full documentation, see man pages. Systemd home page also has plenty of material for further study.



In case you are using SysV style init, you need to write an init script which starts your daemon in /etc/init.d/, for example /etc/init.d/jenkins (and mark it executable).



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


Note that you must fork your service in your init script, otherwise your script doesn't exit, in this example start-stop-daemon does forking (--background) and changing user (--chuid). To study how other services are started in your system using init scripts you can study the files in /etc/init.d/.



To enable the service to start at boot time, run update-rc.d jenkins enable. To start the service run your new script /etc/init.d/jenkins start.



LSB compatible init scripts are also systemd backwards compatible. Remember to source /lib/lsb/init-functions for systemctl to work transparently when executing the script directly.



Debian wiki for LSBInitScripts provides more details about available options, such as starting the service after/before other service.






share|improve this answer


























  • Thank you! I have added additional information to my original post about systemd vs. init. Is the command you gave, systemctl daemon-reload && systemctl start jenkins.service, intended to be run from the command line so I can start the service without rebooting? Or, is it intended to be inserted into some startup script, so that the service will start upon rebooting?

    – Dave
    Aug 2 '17 at 16:55











  • Edited my answer to include sysv init script example. systemctl daemon-reload loads the new unit file. To start/stop/query your service in systemd you can use systemd start/stop/status jenkins.service respectively (without reboot).

    – sebasth
    Aug 2 '17 at 17:30














3












3








3







You are likely running systemd as your inint system. To configure your service, you need to create the necessary unit file for example /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


To enable the service to be run at boot, run systemctl enable jenkins. systemctl start jenkins.service starts the service from command line.
For full documentation, see man pages. Systemd home page also has plenty of material for further study.



In case you are using SysV style init, you need to write an init script which starts your daemon in /etc/init.d/, for example /etc/init.d/jenkins (and mark it executable).



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


Note that you must fork your service in your init script, otherwise your script doesn't exit, in this example start-stop-daemon does forking (--background) and changing user (--chuid). To study how other services are started in your system using init scripts you can study the files in /etc/init.d/.



To enable the service to start at boot time, run update-rc.d jenkins enable. To start the service run your new script /etc/init.d/jenkins start.



LSB compatible init scripts are also systemd backwards compatible. Remember to source /lib/lsb/init-functions for systemctl to work transparently when executing the script directly.



Debian wiki for LSBInitScripts provides more details about available options, such as starting the service after/before other service.






share|improve this answer















You are likely running systemd as your inint system. To configure your service, you need to create the necessary unit file for example /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


To enable the service to be run at boot, run systemctl enable jenkins. systemctl start jenkins.service starts the service from command line.
For full documentation, see man pages. Systemd home page also has plenty of material for further study.



In case you are using SysV style init, you need to write an init script which starts your daemon in /etc/init.d/, for example /etc/init.d/jenkins (and mark it executable).



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


Note that you must fork your service in your init script, otherwise your script doesn't exit, in this example start-stop-daemon does forking (--background) and changing user (--chuid). To study how other services are started in your system using init scripts you can study the files in /etc/init.d/.



To enable the service to start at boot time, run update-rc.d jenkins enable. To start the service run your new script /etc/init.d/jenkins start.



LSB compatible init scripts are also systemd backwards compatible. Remember to source /lib/lsb/init-functions for systemctl to work transparently when executing the script directly.



Debian wiki for LSBInitScripts provides more details about available options, such as starting the service after/before other service.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 29 at 18:10

























answered Aug 2 '17 at 16:37









sebasthsebasth

641210




641210













  • Thank you! I have added additional information to my original post about systemd vs. init. Is the command you gave, systemctl daemon-reload && systemctl start jenkins.service, intended to be run from the command line so I can start the service without rebooting? Or, is it intended to be inserted into some startup script, so that the service will start upon rebooting?

    – Dave
    Aug 2 '17 at 16:55











  • Edited my answer to include sysv init script example. systemctl daemon-reload loads the new unit file. To start/stop/query your service in systemd you can use systemd start/stop/status jenkins.service respectively (without reboot).

    – sebasth
    Aug 2 '17 at 17:30



















  • Thank you! I have added additional information to my original post about systemd vs. init. Is the command you gave, systemctl daemon-reload && systemctl start jenkins.service, intended to be run from the command line so I can start the service without rebooting? Or, is it intended to be inserted into some startup script, so that the service will start upon rebooting?

    – Dave
    Aug 2 '17 at 16:55











  • Edited my answer to include sysv init script example. systemctl daemon-reload loads the new unit file. To start/stop/query your service in systemd you can use systemd start/stop/status jenkins.service respectively (without reboot).

    – sebasth
    Aug 2 '17 at 17:30

















Thank you! I have added additional information to my original post about systemd vs. init. Is the command you gave, systemctl daemon-reload && systemctl start jenkins.service, intended to be run from the command line so I can start the service without rebooting? Or, is it intended to be inserted into some startup script, so that the service will start upon rebooting?

– Dave
Aug 2 '17 at 16:55





Thank you! I have added additional information to my original post about systemd vs. init. Is the command you gave, systemctl daemon-reload && systemctl start jenkins.service, intended to be run from the command line so I can start the service without rebooting? Or, is it intended to be inserted into some startup script, so that the service will start upon rebooting?

– Dave
Aug 2 '17 at 16:55













Edited my answer to include sysv init script example. systemctl daemon-reload loads the new unit file. To start/stop/query your service in systemd you can use systemd start/stop/status jenkins.service respectively (without reboot).

– sebasth
Aug 2 '17 at 17:30





Edited my answer to include sysv init script example. systemctl daemon-reload loads the new unit file. To start/stop/query your service in systemd you can use systemd start/stop/status jenkins.service respectively (without reboot).

– sebasth
Aug 2 '17 at 17:30


















draft saved

draft discarded




















































Thanks for contributing an answer to Super User!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1236961%2frunning-an-executable-as-a-service-under-debian-8%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

Mangá

Eduardo VII do Reino Unido