Tomcat 8.5.37 - systemd startup hiba

 ( Mercoory | 2019. január 10., csütörtök - 14:01 )

Ha más is belefutna a több disztribúciót érintő kézzel indul, bootnál systemd-vel pedig elindul és rögtön leálló Tomcat 8.5.37 verziójába, akkor itt egy csúnya , de működő workaround:

/etc/systemd/system/tomcat.service

...
[Service]
...

UMask=0007
RestartSec=10
Restart=always

SuccessExitStatus=143

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hmmm... Nálam a 9-es ezzel pöcc-röff megy, a /etc/tomcat/environment fájlban természetesen minden releváns környezeti változó (CATALINA_PID, CATALINA_HOME, CATALINA_BASE, CATALINA_OPTS, JAVA_OPTS) beállításra kerül, ahogy azt a "gyári" (apache-tomcat-...tar.gz-ben lévő) startup.sh és shutdown.sh igényli:

[Unit]
Description=Apache Tomcat 9
After=syslog.target network.target

[Service]
User=tomcat
Group=tomcat
Type=forking
Environment=TMP=/var/tmp/
EnvironmentFile=-/etc/tomcat/environment
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

Ahol a SuccessExitStatus=143 befigyelt, az a springboot-os alkalmazások, amiknek a saját indítóscriptje gyakorlatilag egy szépen felpimplet "java -jar..." parancs.

Évek óta megy hibátlanul. 8.5.35-ig nem volt semmi gond.
A gond a 8.5.37-es verzióval jött. Stackoverflow is szépen gyűjti ettől a verziótól a gondokat.

Szerk: A többi környezeti változó, természetesen ugyanúgy benne van nálam, ahogy a tiedben is :)

És a "gyári", azaz az apache-tomcat-8.5.37.tar.gz-ben lévő startup.sh/shutdown.sh scripteket hívja? Bár ez mindegy, mert azok meg a catalina.sh-t fogják meghívni, ami meg összerakja a java commandline-t és elindítja. De ez nem a scriptek vagy a systemd hibája:

"Exit code 143 means that the program received a SIGTERM signal to instruct it to exit, but it did not handle the signal properly. This is almost always due to programming errors, and is pretty common with Java applications of all types.(link)"

sokkal inkább a Tomcat-nek.

docker run -d --restart=always tomcat ? :)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Miért is kéne plusz egy réteggel szivatnia magát?

Egy csomó előnye van a konténerizált üzemeltetésnek, az egyiket pont a képen látjuk.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Egy csomó előnye van a dokumentáció elolvasásának - az általam bemásolt unit fájl is így készült, ahogy a springboot-os motyóké is - ott volt a "mágikus" 143-as exit code leírva:

[Unit]
Description=XXXX springboot app
After=syslog.target network.target

[Service]
EnvironmentFile=/srv/xxxx/etc/xxxx.conf
User=jelentes
ExecStart=/srv/xxxx/bin/xxxx.sh $JXXXXJARFILE
SuccessExitStatus=143
Type=forking
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Ahol az xxxx.sh valahogy így néz ki:

#!/bin/bash
cd /srv/xxxx/bin
test -f ../etc/xxxx.conf || exit
source ../etc/xxxx.conf
test -z $1 && exit
JARFILE=$1
test -f $JARFILE || exit
exec 1>&2
java -jar -DLOG_FILE=${XXXXLOGFILE} ${XXXXJAVAOPTS} $JARFILE &

Ehhez sem kell docker meg egyéb fiszemf@szom, csak doksit olvasni, és átlátni, hogy a systemd hogyan működik.

Az a jó az informatikában hogy mindenki meg tudja válogatni hogy mivel szeretne sz.pni. :)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Jelenleg nincs lehetőségem docker-re átállítani a szolgáltatásokat.