Uruchamianie procesu Java z Systemd

Próbuję wykonać skrypt powłoki z systemd. Skrypt działa poprawnie z wiersza poleceń.

Skrypt (runServer.sh) uruchamia proces Java i wygląda następująco:

#!/bin/bash
java -jar -Dresources=/home/pruss/dev/ServerDeploy5-4.1/Server/resources/MyServer.jar "0" "Test"

Wewnątrz /usr/lib/systemd/system(lub /lib/systemd/system/w innych systemach operacyjnych) utworzyłem plik usługi (myService.service):

[Unit]
Description=My Servers service
[Service]
ExecStart=/home/pruss/dev/ServerDeploy5-4.1/Server/runServer.sh
User=root
Type=oneshot
[Install]
WantedBy=multi-user.target

Wynik

Job for myService.service failed. See "systemctl status myService.service" and "journalctl -xn" for details.

Próbuję:

systemctl status myService.service


   Loaded: loaded (/usr/lib/systemd/system/myService.service; disabled)
   Active: failed (Result: exit-code) since Thu 2015-07-23 12:27:38 BST; 26s ago
   Main PID: 28413 (code=exited, status=203/EXEC)

Możesz nie potrzebować skryptu powłoki. Możesz rozpocząć proces z pliku myService.service pod warunkiem, że użyjesz pełnej ścieżki do pliku binarnego java i pliku jar. Powinno to wyglądać mniej więcej tak

ExecStart=/usr/bin/java -jar /home/pruss/dev/ServerDeploy5-4.1/Server/resources/MyServer.jar

Działa na CentOS 7.2.

Nie jestem pewien, kto dał temu kciuk w dół ...

Znalazłem rozwiązanie i opublikowałem je, aby zaoszczędzić innym wysiłku.

To, co widzisz powyżej, działa. Jednak ostateczna usługa to:

[Unit]
Description=MyProgramThing
[Service]
ExecStart=/home/prus/dev/Blah-4.1/Server/runServer.sh
Type=simple
User=prus
[Install]
WantedBy=multi-user.target

Co ważne, w skrypcie powłoki musiałem podać pełną ścieżkę do pliku .jar. java -jar /home/myprog.jar itp

tj. ./myJar.jar nie działał. Mam nadzieję, że to pomaga.

Spójrz na moją odpowiedź dotyczącą stackoverflow, która szczegółowo opisuje, jak utworzyć systemdusługę dla aplikacji Java:

/programming//a/22121547/272180

To jest mój systemowy szablon dla procesu Java

[Unit]
Description=Spring MVC Java Service

[Service]
User=spring-mvc
# The configuration file application.properties should be here:
WorkingDirectory=/usr/local/spring-mvc


# Run ExecStartPre with root-permissions
PermissionsStartOnly=true

ExecStartPre=-/bin/mkdir -p /var/log/spring-mvc


ExecStartPre=/bin/chown -R spring-mvc:syslog /var/log/spring-mvc
ExecStartPre=/bin/chmod -R 775 /var/log/spring-mvc


Environment="ENV=stage"

#https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart=
ExecStart=/usr/bin/java \
        -Dlog4j.configurationFile=log4j2-spring.xml \
        -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector \
        -Dspring.profiles.active=stage \
        -Denvironment-type=stage \
        -XX:+UseConcMarkSweepGC \
        -XX:CMSInitiatingOccupancyFraction=80 \
        -XX:NewSize=756m \
        -XX:MetaspaceSize=256m \
        -Dsun.net.inetaddr.ttl=5 \
        -Xloggc:/var/log/spring-mvc/gc.log \
        -verbose:gc \
        -verbosegc \
        -XX:+DisableExplicitGC \
        -XX:+PrintGCDetails \
        -XX:+PrintGCDateStamps \
        -XX:+PreserveFramePointer \
        -XX:+StartAttachListener \
        -Xms768m \
        -Xmx768m \
        -XX:+HeapDumpOnOutOfMemoryError \
        -jar spring-mvc.war

SuccessExitStatus=143
StandardOutput=journal
StandardError=journal


KillSignal=SIGINT
TimeoutStopSec=20
Restart=always
RestartSec=5
StartLimitInterval=0
StartLimitBurst=10

LimitNOFILE=500000
LimitNPROC=500000

#https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LimitCPU=
#LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME=¶

SyslogIdentifier=spring-mvc

[Install]
WantedBy=multi-user.target


# https://www.freedesktop.org/software/systemd/man/journalctl.html
#check logs --- journalctl -u spring-mvc -f -o cat

Miałem ten sam problem (kod = zakończony, status = 203 / EXEC).

Nie zapomnij przyznać użytkownikowi uprawnień do wykonywania skryptów.

Możesz zmienić 777 na coś bardziej restrykcyjnego.

chmod 777 /home/yourscript.sh

lub

chmod u+x /home/yourscript.sh

Następnie:

systemctl daemon-reload 
systemctl start yourScript.service 
systemctl enable yourScript.service

Konieczne może być dodanie WorkingDirectory =, aby wiedział, od czego należy uruchamiać.