Stabilitätsprobleme - Versionsgeschichte

Damboeck am 15. Oktober 2022 um 08:52 Uhr

2022-10-15T08:52:43Z

@@ Zeile 1: / Zeile 1: @@
 = Betrieb von LeTTo in Docker-Containern =
 * Doku in Arbeit
@@ Zeile 17: / Zeile 21: @@
 == Prüfen der Serveraktivität über eine Anfrage am Webserver ==
 Haben wir bei uns noch nicht realisiert, ist aber sicher auch möglich.

Damboeck am 15. Oktober 2022 um 08:40 Uhr

2022-10-15T08:40:22Z

← Nächstältere Version		Version vom 15. Oktober 2022, 08:40 Uhr
Zeile 1:		Zeile 1:
			= Betrieb von LeTTo in Docker-Containern =
			* Doku in Arbeit

			= Betrieb eines lokalen LeTTo-Servers mit TomEE-Server =
	* Im Betrieb des Servers kann es (vor allem bei der Verwendung von tagesaktuellen Versionen) zu '''Serverabstürzen''' kommen wodurch dann der Betrieb von Letto nicht mehr funktioniert.		* Im Betrieb des Servers kann es (vor allem bei der Verwendung von tagesaktuellen Versionen) zu '''Serverabstürzen''' kommen wodurch dann der Betrieb von Letto nicht mehr funktioniert.
	* Hat sich nur die Letto-Instanz "erhängt", reicht es die Letto-Instanz neu zu starten. /opt/letto/restart.sh oder /opt/letto/start.sh		* Hat sich nur die Letto-Instanz "erhängt", reicht es die Letto-Instanz neu zu starten. /opt/letto/restart.sh oder /opt/letto/start.sh
Zeile 6:		Zeile 10:
	* Probleme beim Betrieb des TomEE-Servers werden in der Datei /opt/tomee/logs/catalina.out dokumentiert. Falls die Datei sehr groß ist und häufige Fehler auftreten ist es ratsam den Server zu stoppen (/opt/letto/stop.sh), die Datei catalina.out zu löschen (ggf. zu sichern) und dann den Server neu zu starten, dann ist die Logdatei überschaubarer.		* Probleme beim Betrieb des TomEE-Servers werden in der Datei /opt/tomee/logs/catalina.out dokumentiert. Falls die Datei sehr groß ist und häufige Fehler auftreten ist es ratsam den Server zu stoppen (/opt/letto/stop.sh), die Datei catalina.out zu löschen (ggf. zu sichern) und dann den Server neu zu starten, dann ist die Logdatei überschaubarer.

	= Watchdog =		== Watchdog ==
	* Da der Server-Administrator nicht immer sofort mitbekommt das der Serverdienst nicht mehr verfügbar ist bietet sich an den Server automatisch neu zu starten.		* Da der Server-Administrator nicht immer sofort mitbekommt das der Serverdienst nicht mehr verfügbar ist bietet sich an den Server automatisch neu zu starten.
	* Das automatische Neustarten des Servers kann über das LTI-Service realisiert werden		* Das automatische Neustarten des Servers kann über das LTI-Service realisiert werden
	* Während der '''Datensicherung''' kann es auch zu Verzögerungen des Servers kommen. Um einen Restart des Servers während der Datensicherung zu verhindern ist es sinnvoll zu Beginn der Datensicherung die Datei welche als "sicherungslock" angegeben ist anzulegen und zum Ende der Sicherung die Datei wieder zu löschen. Das Watchdog-Script restartet dann den Server niemals während einer Sicherung. Hängt die Sicherung bleibt dann natürlich der Watchdog auch hängen (ist bei uns aber noch nie passiert).		* Während der '''Datensicherung''' kann es auch zu Verzögerungen des Servers kommen. Um einen Restart des Servers während der Datensicherung zu verhindern ist es sinnvoll zu Beginn der Datensicherung die Datei welche als "sicherungslock" angegeben ist anzulegen und zum Ende der Sicherung die Datei wieder zu löschen. Das Watchdog-Script restartet dann den Server niemals während einer Sicherung. Hängt die Sicherung bleibt dann natürlich der Watchdog auch hängen (ist bei uns aber noch nie passiert).

	= Prüfen der Serveraktivität über eine Anfrage am Webserver =		== Prüfen der Serveraktivität über eine Anfrage am Webserver ==
	Haben wir bei uns noch nicht realisiert, ist aber sicher auch möglich.		Haben wir bei uns noch nicht realisiert, ist aber sicher auch möglich.

Damboeck: /* Watchdog */

2020-09-27T15:51:52Z

Watchdog

← Nächstältere Version		Version vom 27. September 2020, 15:51 Uhr
Zeile 9:		Zeile 9:
	* Da der Server-Administrator nicht immer sofort mitbekommt das der Serverdienst nicht mehr verfügbar ist bietet sich an den Server automatisch neu zu starten.		* Da der Server-Administrator nicht immer sofort mitbekommt das der Serverdienst nicht mehr verfügbar ist bietet sich an den Server automatisch neu zu starten.
	* Das automatische Neustarten des Servers kann über das LTI-Service realisiert werden		* Das automatische Neustarten des Servers kann über das LTI-Service realisiert werden

	~~== Prüfen der Serveraktivität über eine Datei ==~~
	~~Die Datei, welche der Lettoserver mindestens einmal pro Minut löscht, wenn sie vorhanden ist wird in der globalen Konfiguration mit dem Parameter "WatchdogFile" konfiguriert.~~
	~~:[[Datei:ClipCapIt-190522-225816.PNG]]~~
	~~Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.~~

	* Während der '''Datensicherung''' kann es auch zu Verzögerungen des Servers kommen. Um einen Restart des Servers während der Datensicherung zu verhindern ist es sinnvoll zu Beginn der Datensicherung die Datei welche als "sicherungslock" angegeben ist anzulegen und zum Ende der Sicherung die Datei wieder zu löschen. Das Watchdog-Script restartet dann den Server niemals während einer Sicherung. Hängt die Sicherung bleibt dann natürlich der Watchdog auch hängen (ist bei uns aber noch nie passiert).		* Während der '''Datensicherung''' kann es auch zu Verzögerungen des Servers kommen. Um einen Restart des Servers während der Datensicherung zu verhindern ist es sinnvoll zu Beginn der Datensicherung die Datei welche als "sicherungslock" angegeben ist anzulegen und zum Ende der Sicherung die Datei wieder zu löschen. Das Watchdog-Script restartet dann den Server niemals während einer Sicherung. Hängt die Sicherung bleibt dann natürlich der Watchdog auch hängen (ist bei uns aber noch nie passiert).

	= Prüfen der Serveraktivität über eine Anfrage am Webserver =		= Prüfen der Serveraktivität über eine Anfrage am Webserver =
	Haben wir bei uns noch nicht realisiert, ist aber sicher auch möglich.		Haben wir bei uns noch nicht realisiert, ist aber sicher auch möglich.

Damboeck am 27. September 2020 um 15:51 Uhr

2020-09-27T15:51:09Z

@@ Zeile 1: / Zeile 1: @@
 * Im Betrieb des Servers kann es (vor allem bei der Verwendung von tagesaktuellen Versionen) zu '''Serverabstürzen''' kommen wodurch dann der Betrieb von Letto nicht mehr funktioniert.
-* Hat sich nur die Letto-Instanz "erhängt", reicht es die Letto-Instanz neu zu starten.
+* Hat sich nur die Letto-Instanz "erhängt", reicht es die Letto-Instanz neu zu starten. /opt/letto/restart.sh oder /opt/letto/start.sh
-* Hat sich der komplett Glassfish oder TomEE-Server "erhängt", so muss der komplette Glassfish oder TomEE neu gestartet werden.
+* Information über die PID der laufenden LeTTo-Instanz bzw. ob der Server überhaupt läuft erhält man mit /opt/letto/status.sh
 * Das sich der Linux-Server selbst erhängt hat ist bei uns im Betrieb noch nicht aufgetreten und ist dann auf eine Fehlkonfiguration des Servers oder meist auf einen Hardwaredefekt zurück zu führen.
 * Keine Software kann fehlerfrei programmiert werden, wodurch es immer wieder einmal zu einem Server-Absturz kommen kann. Wir versuchen unser Möglichstes um solche Abstürze möglichst zu verhindern.
 = Watchdog =
 * Da der Server-Administrator nicht immer sofort mitbekommt das der Serverdienst nicht mehr verfügbar ist bietet sich an den Server automatisch neu zu starten.
-* Das automatische Neustarten des Servers übernimmt am Besten ein Linux-Cronjob welcher prüft ob der Server noch aktiv ist und dann den Server neu startet.
+* Das automatische Neustarten des Servers kann über das LTI-Service realisiert werden
 == Prüfen der Serveraktivität über eine Datei ==
@@ Zeile 14: / Zeile 14: @@
 :[[Datei:ClipCapIt-190522-225816.PNG]]
 Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.
 * Während der '''Datensicherung''' kann es auch zu Verzögerungen des Servers kommen. Um einen Restart des Servers während der Datensicherung zu verhindern ist es sinnvoll zu Beginn der Datensicherung die Datei welche als "sicherungslock" angegeben ist anzulegen und zum Ende der Sicherung die Datei wieder zu löschen. Das Watchdog-Script restartet dann den Server niemals während einer Sicherung. Hängt die Sicherung bleibt dann natürlich der Watchdog auch hängen (ist bei uns aber noch nie passiert).

Damboeck am 22. Mai 2019 um 21:15 Uhr

2019-05-22T21:15:37Z

← Nächstältere Version		Version vom 22. Mai 2019, 21:15 Uhr
Zeile 1:		Zeile 1:
	* Im Betrieb des Servers kann es (vor allem bei der Verwendung von tagesaktuellen Versionen) zu '''Serverabstürzen''' kommen wodurch dann der Betrieb von Letto nicht mehr funktioniert.		* Im Betrieb des Servers kann es (vor allem bei der Verwendung von tagesaktuellen Versionen) zu '''Serverabstürzen''' kommen wodurch dann der Betrieb von Letto nicht mehr funktioniert.
	* Hat sich nur die Letto-Instanz "erhängt", reicht es ~~mit dem Glassfish-Admin~~ die Letto-Instanz neu zu starten.		* Hat sich nur die Letto-Instanz "erhängt", reicht es die Letto-Instanz neu zu starten.
	* Hat sich der komplett Glassfish-Server "erhängt", so muss der komplette Glassfish~~-Server~~ neu gestartet werden.		* Hat sich der komplett Glassfish oder TomEE-Server "erhängt", so muss der komplette Glassfish oder TomEE neu gestartet werden.
			* Das sich der Linux-Server selbst erhängt hat ist bei uns im Betrieb noch nicht aufgetreten und ist dann auf eine Fehlkonfiguration des Servers oder meist auf einen Hardwaredefekt zurück zu führen.
	* Keine Software kann fehlerfrei programmiert werden, wodurch es immer wieder einmal zu einem Server-Absturz kommen kann. Wir versuchen unser Möglichstes um solche Abstürze möglichst zu verhindern.		* Keine Software kann fehlerfrei programmiert werden, wodurch es immer wieder einmal zu einem Server-Absturz kommen kann. Wir versuchen unser Möglichstes um solche Abstürze möglichst zu verhindern.

Zeile 8:		Zeile 9:
	* Das automatische Neustarten des Servers übernimmt am Besten ein Linux-Cronjob welcher prüft ob der Server noch aktiv ist und dann den Server neu startet.		* Das automatische Neustarten des Servers übernimmt am Besten ein Linux-Cronjob welcher prüft ob der Server noch aktiv ist und dann den Server neu startet.
	* Für die Prüfung kann entweder eine Anfrage an den Server gestellt werden oder über eine Datei die Serveraktivität geprüft werden.		* Für die Prüfung kann entweder eine Anfrage an den Server gestellt werden oder über eine Datei die Serveraktivität geprüft werden.
	=== Prüfen der Serveraktivität über eine Datei ===
			== Prüfen der Serveraktivität über eine Datei ==
	Die Datei, welche der Lettoserver mindestens einmal pro Minut löscht, wenn sie vorhanden ist wird in der globalen Konfiguration mit dem Parameter "WatchdogFile" konfiguriert.		Die Datei, welche der Lettoserver mindestens einmal pro Minut löscht, wenn sie vorhanden ist wird in der globalen Konfiguration mit dem Parameter "WatchdogFile" konfiguriert.
	:[[Datei:ClipCapIt-190522-225816.PNG]]		:[[Datei:ClipCapIt-190522-225816.PNG]]
Zeile 102:		Zeile 104:
	/3 * * * /bin/bash /pfadzumscript/lettowatchdog.sh		/3 * * * /bin/bash /pfadzumscript/lettowatchdog.sh
	</pre>		</pre>

			* Während der '''Datensicherung''' kann es auch zu Verzögerungen des Servers kommen. Um einen Restart des Servers während der Datensicherung zu verhindern ist es sinnvoll zu Beginn der Datensicherung die Datei welche als "sicherungslock" angegeben ist anzulegen und zum Ende der Sicherung die Datei wieder zu löschen. Das Watchdog-Script restartet dann den Server niemals während einer Sicherung. Hängt die Sicherung bleibt dann natürlich der Watchdog auch hängen (ist bei uns aber noch nie passiert).

			= Prüfen der Serveraktivität über eine Anfrage am Webserver =
			Haben wir bei uns noch nicht realisiert, ist aber sicher auch möglich.

Damboeck: /* Prüfen der Serveraktivität über eine Datei */

2019-05-22T21:07:29Z

Prüfen der Serveraktivität über eine Datei

← Nächstältere Version		Version vom 22. Mai 2019, 21:07 Uhr
Zeile 13:		Zeile 13:
	Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.		Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.

	Ein mögliches Script für den Cronjob, welches auch vom [https://letto.at/download/letto/~~lettowatchdog.sh~~ Download-Bereich] als [https://letto.at/download/letto/lettowatchdog.sh lettowatchdog.sh] heruntergeladen werden kann:		Ein mögliches Script für den Cronjob, welches auch vom [https://letto.at/download/letto/ Download-Bereich] als [https://letto.at/download/letto/lettowatchdog.sh lettowatchdog.sh] heruntergeladen werden kann:
	<pre>		<pre>
	#!/bin/bash		#!/bin/bash

Damboeck: /* Prüfen der Serveraktivität über eine Datei */

2019-05-22T21:07:13Z

Prüfen der Serveraktivität über eine Datei

← Nächstältere Version		Version vom 22. Mai 2019, 21:07 Uhr
Zeile 13:		Zeile 13:
	Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.		Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.

	Ein mögliches Script für den Cronjob, welches auch vom Download-Bereich heruntergeladen werden kann.		Ein mögliches Script für den Cronjob, welches auch vom [https://letto.at/download/letto/lettowatchdog.sh Download-Bereich] als [https://letto.at/download/letto/lettowatchdog.sh lettowatchdog.sh] heruntergeladen werden kann:
	<pre>		<pre>
	#!/bin/bash		#!/bin/bash
Zeile 100:		Zeile 100:
	und setzt dort den Cronjob:		und setzt dort den Cronjob:
	<pre>		<pre>
	/3 * * * /bin/bash /~~home/l-damb~~/lettowatchdog.sh		/3 * * * /bin/bash /pfadzumscript/lettowatchdog.sh
	</pre>		</pre>

Damboeck: /* Watchdog */

2019-05-22T21:04:10Z

Watchdog

← Nächstältere Version		Version vom 22. Mai 2019, 21:04 Uhr
Zeile 12:		Zeile 12:
	:[[Datei:ClipCapIt-190522-225816.PNG]]		:[[Datei:ClipCapIt-190522-225816.PNG]]
	Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.		Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.
	mögliches Script für den Cronjob:
			Ein mögliches Script für den Cronjob, welches auch vom Download-Bereich heruntergeladen werden kann.
	<pre>		<pre>
	#!/bin/bash		#!/bin/bash
Zeile 89:		Zeile 90:
	echo $msg		echo $msg
	fi		fi
			</pre>

			Das Script sollte mit den '''Benutzerrechten des Letto-Server-Users''' gestartet werden!

			Um das Script alle 3 Minuten zu starten bearbeitet man die Crontab mit
			<pre>
			crontab -e
			</pre>
			und setzt dort den Cronjob:
			<pre>
			/3 * * * /bin/bash /home/l-damb/lettowatchdog.sh
	</pre>		</pre>

Damboeck: Die Seite wurde neu angelegt: „* Im Betrieb des Servers kann es (vor allem bei der Verwendung von tagesaktuellen Versionen) zu '''Serverabstürzen''' kommen wodurch dann der Betrieb von Lett…“

2019-05-22T21:00:10Z

Die Seite wurde neu angelegt: „* Im Betrieb des Servers kann es (vor allem bei der Verwendung von tagesaktuellen Versionen) zu '''Serverabstürzen''' kommen wodurch dann der Betrieb von Lett…“

Neue Seite

* Im Betrieb des Servers kann es (vor allem bei der Verwendung von tagesaktuellen Versionen) zu '''Serverabstürzen''' kommen wodurch dann der Betrieb von Letto nicht mehr funktioniert.
* Hat sich nur die Letto-Instanz "erhängt", reicht es mit dem Glassfish-Admin die Letto-Instanz neu zu starten.
* Hat sich der komplett Glassfish-Server "erhängt", so muss der komplette Glassfish-Server neu gestartet werden.
* Keine Software kann fehlerfrei programmiert werden, wodurch es immer wieder einmal zu einem Server-Absturz kommen kann. Wir versuchen unser Möglichstes um solche Abstürze möglichst zu verhindern.

= Watchdog =
* Da der Server-Administrator nicht immer sofort mitbekommt das der Serverdienst nicht mehr verfügbar ist bietet sich an den Server automatisch neu zu starten.
* Das automatische Neustarten des Servers übernimmt am Besten ein Linux-Cronjob welcher prüft ob der Server noch aktiv ist und dann den Server neu startet.
* Für die Prüfung kann entweder eine Anfrage an den Server gestellt werden oder über eine Datei die Serveraktivität geprüft werden.
=== Prüfen der Serveraktivität über eine Datei ===
Die Datei, welche der Lettoserver mindestens einmal pro Minut löscht, wenn sie vorhanden ist wird in der globalen Konfiguration mit dem Parameter "WatchdogFile" konfiguriert.
:[[Datei:ClipCapIt-190522-225816.PNG]]
Eine Cronjob muss dann nur mehr die Datei regelmäßig anlegen und kontrollieren ob sie vom Server gelöscht wurde.
mögliches Script für den Cronjob:
<pre>
#!/bin/bash

# Der Letto-Watchdog überprüft ob der Server noch aktiv ist. Hierfür wird eine Datei angelegt, welche in der
# globalen Konfiguration von Letto angegeben werden muss (zB. /opt/letto/lettowatchdog ) damit Letto diese Datei
# alle 60 Sekunden löschen kann. Als Extension hat die Watchdog-Datei immer den Applikationsnamen am Webserver
# z.B /opt/letto/lettowatchdog.letto für die Applikation letto
# oder /opt/letto/lettowatchdog.beta für die Applikation beta
#
# Ist nach 2 Minuten die Datei noch immer vorhanden, so wird der Letto-Server neu gestartet

# !! BITTE ANPASSEN !!
# Watchdog-File: Besteht aus dem Pfad welcher in der globalen Konfiguration angegeben ist, mit der Applikation als Extension
watchdogfile=/opt/letto/lettowatchdog.letto

# Logfile für die Protokollierung des Restart-Vorganges
logfile=/opt/letto/watchdog.info

# Datei welche während der Sicherung erzeugt ist um zu Markieren, dass kein Reboot erfolgen darf da die Sicherung aktiv ist
sicherungslock=/sicherung/sqlsicherungaktiv

#----------------------------------------------------------------------------------------------------------------
datum=$(date)

# Einen Serverzugriff am Glassfish erzwingen
wget http://localhost:8080/letto

# Einen Serverzugriff am Tomcat erzwingen
#wget http://localhost:8088/tomcat

msg="$datum Watchdog wird überprüft"
echo $msg >>$logfile
echo $msg

touch $watchdogfile
sleep 120

if [ -f $watchdogfile ] ; then
# Watchdog hat angeschlagen, der Server muss neu gestartet werden!!

rm $watchdogfile -rf

if [ -f $sicherungslock ] ; then
msg="$datum Server $1 wird nicht neu gestartet da die Sicherung aktiv ist"
echo $msg >>$logfile
echo $msg
else
# Glassfish Server neu starten
msg="$datum Glassfish Server neu starten!"
echo $msg >>$logfile
echo $msg
/opt/glassfish4/glassfish/bin/asadmin stop-domain
/opt/glassfish4/glassfish/bin/asadmin start-domain
msg="$datum Glassfish Server wurde neu gestartet!"
echo $msg
echo $msg >>$logfile

# TomEE neu starten
#msg="$datum Server tomee neu starten!"
#echo $msg >>$logfile
#echo $msg
#/opt/tomee7/bin/shutdown.sh
#sleep 5
#/opt/tomee7/bin/startup.sh
# msg="$datum TomEE Server wurde neu gestartet!"
# echo $msg
# echo $msg >>/home/l-damb/restart.info

fi
else
msg="$datum Watchdog ok"
echo $msg >>$logfile
echo $msg
fi
</pre>