Tomcat beim Start ausführen

[Morale]

Guten Morgen,

ich bin relativer Linux Neuling und habe in der Arbeit einen Server (CentOS) zugewiesen bekommen, auf dem ich mich quasi "einlernen" darf.

Produktiv wird er für ein Programm genutzt welches Tomcat nutzt.
Damit dieses Programm auch bei einem Neustart gleich verfügbar ist, soll antürlich auch der Tomcat gleich beim hochfahren starten.
Dazu habe ich mir im Netz ein Script besorgt (es leicht angepasst) und es in /etc/rc.d/init.d/ gepackt:


#---------------------------- /etc/init.d/tomcat ------------------------
#!/bin/bash
#
# tomcat
#
# chkconfig: 235 20 80
# description: Start up the Tomcat servlet engine.

# Source function library.
. /etc/init.d/functions


RETVAL=$?
CATALINA_HOME="/opt/tomcat"

case "$1" in
start)
if [ -f $CATALINA_HOME/bin/startup.sh ];
then
echo $"Starting Tomcat"
/bin/su tomcat $CATALINA_HOME/bin/startup.sh
fi
;;
stop)
if [ -f $CATALINA_HOME/bin/shutdown.sh ];
then
echo $"Stopping Tomcat"
/bin/su tomcat $CATALINA_HOME/bin/shutdown.sh
fi
;;
*)
echo $"Usage: $0 {start|stop}"
exit 1
;;
esac

exit $RETVAL
#----------------------- end of /etc/init.d/tomcat ----------------------


Soweit so gut, Tomcat startet auch beim Neustart.
Das Programm auch, allerdings fkt. es nicht richtig.
Im Programm muss man einen Mandanten auswählen (der kommt aus der MySQL DB) und dies ist leider nicht möglich, wenn Tomcat über dieses Script startet.
Startet man dagegen die startup.sh direkt in CATALINA_HOME geht es.

Hat jemand eine Idee?
Auch bezüglich auf den Inhalt des cripst (Verbesserungen, Fehler?)

Vielen Dank :)

[marce]

ich würde vermuten, daß irgendeine Umgebungs-Einstellung nicht vorhanden ist, wenn der Tomcat über's Init-Script gestartet wird.

Vergleich einfach mal env / set der beiden Umgebungen.

Ansonsten würde ich mal im catalina.out oder im Applikations-Log nachschauen, ob da was geworfen wird. Evtl. ist auch einfach die MySQL-DB noch nicht sauber gestartet, wenn der Tomcat startet, Java-Apps machen ihre Verbindungen normalerweise 1x beim Start auf und wenn das fehlschlägt war's das (wenn nicht entsprechend anders programmiert) - das sollte sich aber auch aus den Logs ergeben.

Grundlegend sollte es keinen Unterschied machen, wie der Tomcat gestartet wird.

[drcux]

"su" ist keine gute Wahl, unter Centos gibt es "daemon", siehe

https://blog.hazrulnizam.com/create-init-script-centos-6/

[marce]

wobei daemon (aus dem Kopf heraus) eigentlich nur den Vorteil bietet, daß es automatisch in den Hintergrund schickt - und das wäre beim Standard-Tomcat-Script eh gegeben.

[drcux]

wobei daemon (aus dem Kopf heraus) eigentlich nur den Vorteil bietet, daß es automatisch in den Hintergrund

Nicht nur: Ausführen unter einen anderem User wobei AFAIK auch die Umgebungsvariablen angepasst werden und noch einiges anderes.

[marce]

naja, das "anderer User" macht su ja "per se" und die Umgebung passt der Tomcat über eigene Scripte an, die entsprechend durch catalina.sh bzw. startup.sh gesourced werden.

zudem würde su mit passendem Parameter die "normale" Login-Shell des Users verwenden, so daß dabei auch alles passen sollte.

Wir zumindest fahren hier seit Jahren ohne Probleme mit der su-Lösung.

[nopes]

Durchaus interessant, ehrlich gesagt war (ehrlicher weise ist ;)) su auch meine best practice dazu, wie auch immer daemon gibt es auch bei Debian, und es macht schon ein paar nette Dinge für einen
daemon(1) turns other processes into daemons. There are many tasks that
need to be performed to correctly set up a daemon process. This can be
tedious. daemon performs these tasks for other processes.

The preparatory tasks that daemon performs for other processes are:

· First revoke any setuid or setgid privileges that daemon may have
been installed with (by system administrators who laugh in the face
of danger).

· Process command line options.

· Change the root directory if the --chroot option was supplied.

· Change the process uid and gid if the --user option was supplied.
Only root can use this option. Note that the uid of daemon itself
is changed, rather than just changing the uid of the client
process.

· Read the system configuration file (/etc/daemon.conf by default, or
specified by the --config option) unless the --noconfig option was
supplied. Then read the user's configuration file (~/.daemonrc), if
any. Generic options are processed first, then options specific to
the daemon with the given name. Note: The root directory and the
user must be set before access to the configuration file can be
attempted so neither --chroot nor --user options may appear in the
configuration file.

· Disable core file generation to prevent leaking sensitive
information in daemons run by root (unless the --core option was
supplied)...Geht noch weiter, aber schon das "Bisschen" reicht mir -> daemon ist zu bevorzugen...

[marce]

wobei es da wohl so aussieht, daß daemon bei Debian wohl ein ded. Binary ist und unter CentOS ein Script aus /etc/init.d/functions (welches intern runuser verwendet) und beide sind von den möglichen Optionen und Funktionsumfang nicht identisch.

... solange ich also die functions nicht inkludiere unter CentOS habe ich daemon als Aufruf nicht zur Verfügung.

// Die debian-Aussage ist Vermutung basierend auf Google-Foo, da gerade keine Heiligenschein-Kiste zur Hand.

edit: siehe auch http://unix.stackexchange.com/questions/72881/how-can-i-run-a-shell-script-as-a-daemon-under-redhat/72930#72930

[nopes]

Die Mutmaßung ist korrekt
$ which daemon
/usr/bin/daemonDann sieht die Welt natürlich auch schon wieder anders aus, schließlich will man ja was einheitliches erstellen, da sind so Distributions spezifische Dinge natürlich für die Tonne, kein Wunder also, dass eine www Suche su als best practice liefert...

[marce]

... und jetzt schauen wir mal noch nach, wie das alles bei systemd aussieht.

vermutlich sollte da wenigstens über die Disitrubtionswelt verteilt die Einheitlichkeit wieder größer werden...

[Morale]

Danke für die Posts/Hinweise.
Bin leider noch nicht dazu gekommen etwas davon umzusetzen.