SEPIA-Home Server docker Update

[cap-blackbeard]

Hallo,

ich versuche meinen laufenden SEPIA-Container mit bash update-sepia.sh auf Version 2.6.1 upzudaten.

Als Antwort erhalte ich:

Enter 'yes' to continue: yes

Ok. Good luck ;-)

Shutting down Assist-API
Shutting down Teach-API
Shutting down WebSocket Chat-API
Shutting down Elasticsearch
Shutting down Extensions: MaryTTS server

---- wait a second (or 3) ----

---- testing ----

Mir erscheint der Durchlauf sehr kurz. Und die Control-Hub-Info steht weiter auf 1.4.1

Außerdem funktioniert nach der Neuinstallation meines Raspberry-Clients die Spracherkennung nicht und der Client gibt mir den Hinweis, dass ich auf eine neuere Serverversion updaten soll. Ich denke das hängt damit zusammen, dass ich das Update richtig ausführe?

[fquirin]

Mehr als das kommt gar nicht? Denn das ist nur der Anfang des Update scripts was the laufenden Server beendet :thinking:

[cap-blackbeard]

Nö. Mehr kommt nicht. Habe den laufenden Container probiert. Habe den Container beendet und den Setup-Container getestet. Im Terminal von Portainer. Per ssh auf dem Server. Alles mit dem gleichen Ergebnis.

Gibt es nen log?

[fquirin]

Der Terminal Output ist eigentlich das log :grimacing: Nach ---- testing ---- wird das sepia-status.sh Skript ausgeführt was lediglich zwei 'ps' Befehle sind und dann müsste das Terminal Starting backup ... anzeigen (quasi der nächste Log Eintrag). Der einzige Error, der passieren kann wäre also in sepia-status.sh und müsste unmittelbar im Terminal auftauchen :thinking:

Hängt das Terminal fest und muss abgebrochen werden oder springt es zurück in die Eingabe? Kannst du mal bash sepia-status.sh alleine ausführen

[cap-blackbeard]

Es wird abgebrochen und springt zur Eingabe.

bash sepia-status.sh admin 764 762 0 20:58 pts/2 00:00:00 grep java.*sepia-.*

[fquirin]

und diese Zeile: admin 764 762 0 20:58 pts/2 00:00:00 grep java.*sepia-.* kommt beim update script nicht?

[cap-blackbeard]

Wenn ich jetzt bash update-sepia.sh eingebe, kommt:

Ok. Good luck ;-)

Shutting down Assist-API
Shutting down Teach-API
Shutting down WebSocket Chat-API
Shutting down Elasticsearch
./shutdown.sh: line 5: elasticPID.pid: No such file or directory
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
Shutting down Extensions: MaryTTS server

---- wait a second (or 3) ----

---- testing ----

admin        768     755  0 21:00 pts/2    00:00:00 nano admin 764 762 0 20:58 pts/2 00:00:00 grep java.*sepia-.*
admin        803     801  0 21:02 pts/3    00:00:00 grep java.*sepia-.*
admin@406ec6cc15d1:~/SEPIA$ pi@Server01:~$

Das ist neu!

[fquirin]

und danach geht es wieder nicht weiter? Also irgendwas verhält sich da extrem seltsam :grimacing: .

admin@406ec6cc15d1:~/SEPIA$ pi@Server01:~$

Wenn ich mir diese Zeile angucke sieht es so aus als würde der Container komplett beendet und das Terminal springt raus ins Host System. Wie gehst du in den Container rein? Falls du es nicht schon so machst versuch mal sudo docker exec -it sepia_home /bin/bash vom Host System.

[cap-blackbeard]

sudo docker exec -it SEPIA_Home_Framework.1.wrh1xnmleyph8izsfg24gp88z /bin/bash

Ok. Good luck ;-)

Shutting down Assist-API
Shutting down Teach-API
Shutting down WebSocket Chat-API
Shutting down Elasticsearch
./shutdown.sh: line 5: elasticPID.pid: No such file or directory
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
Shutting down Extensions: MaryTTS server

---- wait a second (or 3) ----

---- testing ----

admin@ae637d253be6:~/SEPIA$

[fquirin]

Ich frage mich ob das Terminal vielleicht einfach nur den Fehler verschluckt aus unerklärlichen Gründen :thinking: Versuch mal bitte folgendes:

• sudo docker exec -it SEPIA_Home_Framework.1.wrh1xnmleyph8izsfg24gp88z /bin/bash
• cd ~
• wget https://sepia-framework.github.io/install/sepia-home-rpi-update.sh
• bash sepia-home-rpi-update.sh
• Und dann den Anweisungen folgen

[cap-blackbeard]

Shutting down Assist-API
Shutting down Teach-API
Shutting down WebSocket Chat-API
Shutting down Elasticsearch
./shutdown.sh: line 5: elasticPID.pid: No such file or directory
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
Shutting down Extensions: MaryTTS server

---- wait a second (or 3) ----

---- testing ----

admin@ae637d253be6:~$

sonst tut sich nichts.

[fquirin]

Ich habs gerade noch mal auf meinem x86 64bit System ausprobiert und es lief ohne Probleme durch. Es muss irgendeine Besonderheit geben in deinem Setup, die dafür sorgt, dass der Prozess ohne Fehlermeldung einfach abbricht :thinking: . Was genau war noch mal das Host-System? Die Container werden alle von Portainer gemanagt richtig?

Kannst du ein Backup machen mit bash backup-sepia.sh? Ich baue mal einen Container mit der neuen Version, vielleicht kannst du dann dort wenigstens das Backup importieren.

[cap-blackbeard]

Backup kann ich erstellen. Der Backupordner hat eine Größe von 22,8MB.

Das Host-System ist ein HP ProLiant ML350 Gen6 Server auf dem ich Debian installiert habe. Die Container werden von Portainer gemanagt. Allerdings kämpfe ich noch mit der Netzwerkkonfiguration der Container. Da ist bestimmt nicht alles optimal.

[fquirin]

Das Host-System ist ein HP ProLiant ML350 Gen6 Server auf dem ich Debian installiert habe

Ach das war sogar Debian, komisch, das ist auch mein Default Host System und genug Saft hat die Kiste wahrscheinlich auch. Mir gehen da langsam die Ideen aus :-|. Vielleicht ein Problem mit dem Filesystem, aber das Backup hat ja scheinbar geklappt.

Ich habe den Docker Container upgedated (sepia/home:v2.6.1_amd64). Das bringt wahrscheinlich keinen Unterscheid für das Update (alle wichtigen Daten sind ja im shared folder) aber wer weiß ^^. Ich würde jetzt einmal deinen kompletten shared folder (SEPIA) sichern, zusammen mit dem Backup irgendwo zwischenlagern und dann den Rest des update Skriptes manuell ausführen (ich hoffe das passt so, habe etwas improvisiert ^^):

• cd $HOME/SEPIA
• mkdir -p update && cd update
• rm SEPIA-Home.zip && wget https://github.com/SEPIA-Framework/sepia-installation-and-setup/releases/latest/download/SEPIA-Home.zip
• unzip SEPIA-Home.zip -d $HOME/SEPIA
• cd $HOME
• unzip -o "path/to/your/backup.zip" -d $HOME/SEPIA (hier den Pfad anpassen!)
• cd $HOME/SEPIA
• bash setup.sh und direkt wieder exit (das setzt nur die execute Berechtigungen)
• cat version

Und dann mal testen was passiert ^^.

[cap-blackbeard]

evtl. uninteressant. Aber es gab bzw. gibt keine SEPIA-Home.zip-Datei.

admin@e63040cbbe4e:~/SEPIA/update$ rm SEPIA-Home.zip && wget https://github.com/SEPIA-Framework/sepia-installation-and-setup/releases/latest/download/SEPIA-Home.zip rm: cannot remove 'SEPIA-Home.zip': No such file or directory Habe wget direkt ausgeführt.

Und noch etwas fällt mir gerade auf. Ich habe keinen .zip-Ordner mit einem Backup. Ich habe einen klassische Ordner mit dem Namen: "SEPIA_backup_2022_02_10_192403". Bzw. mittlerweile sind es mehrere. Wegen den vielen Anläufen. Aber keinen .zip-Ordner. Mit diesem Inhalt:

[cap-blackbeard]

Ich habe SEPIA-Backup.zip von 06.02.2022 gefunden! Aber leider keine aktuelleren. Die befinden sich alle lokal auf dem Host im user-Ordner. Evtl. sind das Dateien, die ich mit dem Setup-Container erstellt habe? Wie kommen die da hin ist ne doofe Frage. Aber sollten die nicht im shared folder sein?

[fquirin]

Ich melde mich gleich noch mal aber mir ist was eingefallen, was das komische Verhalten zumindest teilweise erklären würden. Läuft irgendwo ein Skript was den status des Servers überwacht und irgendeine Aktion durchführt wenn der Server down ist? Z.B. den Container neu startet? ^^ Das würde erklären warum es immer nach dem shut-down Skript abschmiert, warum du teilweise komplett aus dem Container rausfliegst und warum es ein bisschen random ist je nachdem wie schnell das Skript reagiert.

Aber es gab bzw. gibt keine SEPIA-Home.zip-Datei

Ach ja das war dumm, der rm sollte eine Vorsichtsmaßnahme sein um ggf alte Zips zu entfernen. Natürlich hatte ich vergessen dass es einen Fehler erzeugt wenn die Datei noch gar nicht existiert.

Ich habe keinen .zip-Ordner mit einem Backup. Ich habe einen klassische Ordner mit dem Namen: "SEPIA_backup_2022_02_10_192403"

Das Update Skript macht 2 Sachen, ein gezipptes Backup im Home Ordner und verschiebt dann den kompletten alten SEPIA Ordner zu diesem SEPIA_backup_2022_02_10_192403. Letzteres habe ich mittlerweile unterdrückt im Docker-Fall weil es da eh keinen Sinn macht und verschwindet beim Neustart.

[fquirin]

Ich habe SEPIA-Backup.zip von 06.02.2022 gefunden! Aber leider keine aktuelleren. Die befinden sich alle lokal auf dem Host im user-Ordner.

Ja, gute Frage, der Container darf doch gar nicht dahin schreiben, zumindest nicht im Normalfall O_o.

So lange du ein Backup deines shared folders hast ist aber alles ok. Das kannst du im Grunde einfach über den aktuellen Ordner drüberkopieren. Besser noch: erst die Daten im aktuellen Ordner löschen und dann die Daten aus dem Backup reinkopieren (so vermeidest du einen mix aus alten und neuen Libraries etc.).

[cap-blackbeard]

Läuft irgendwo ein Skript was den status des Servers überwacht und irgendeine Aktion durchführt wenn der Server down ist?

Ja. Tatsächlich habe ich damals docker im swarm-Modus eingerichtet, da mir die Service-Funktion gefallen hat. Der Service sorgt dafür, dass der Container neu gestartet wird, sobald er down geht.

[fquirin]

Dann hätten wir also endlich die Lösung gefunden :grin: , diesen Service bitte deaktivieren fürs Update ^^. Wie prüft der eigentlich ob der Server noch läuft?

[cap-blackbeard]

Jup. Das wars.

Wie prüft der eigentlich ob der Server noch läuft?

Wie das genau läuft kann ich Dir nicht sagen. Aber man erstellt für jeden Container einen Service. In diesem Service wird dann das zu verwendende Image, Raplicas (docker swarm), Enviroments, Mounts, Networks, Published Ports und z.B. Restart condition definiert.

Ich hatte den swarm mode eingerichtet, da ich ursprünglich mit 2 Rpi3b+ arbeiten wollte. Habe aber schnell gemerkt, dass die 3er mit 1GB RAM zu klein sind. Da ich jetzt den HP-Rechner habe, werde ich mich damit beschäftigen, wie ich den swarm-mode wieder abschalten kann und werde meine Container wohl klassisch laufen lassen. Ich blick nämlich nicht durch, wie den Containern feste IPs zugewiesen werden können... Aber grundsätzlich ist der swarm-mode bzgl. hohe Verfügbarkeit ne coole Sache. Wenn mans braucht ;-)

Übrigens vielen Dank für Dein Engagement! Finde ich absolut unüblich, dass sich jemand so reinhängt!

[fquirin]

Ich hätte gedacht, dass man irgendwie eine Bedingung definieren muss, die beurteilen kann, ob der Server tatsächlich läuft, sowas wie einen Ping-Request etc. :thinking: . Naja Hauptsache es klappt jetzt ^^.

Übrigens vielen Dank für Dein Engagement! Finde ich absolut unüblich, dass sich jemand so reinhängt!

Kein Thema, ich will ja schließlich, dass jeder der Lust auf SEPIA hat es auch ohne Probleme nutzen kann :smiley:

[cap-blackbeard]

Also der ioBroker-Container z.B. nutzt ja irgendwie eine healthcheck. Meinst Du so etwas? Der Service sorgt hauptsächlich dafür, dass der Container auf anderen swarm-Knoten wieder gestartet werden, wenn der ursprüngliche swarm-Knoten down geht.

[fquirin]

Das Update Skript schließt ja nur den Server, der Container sollte eigentlich weiterlaufen, zumindest wenn er mit dem 'on-docker' Skript gestartet wurde. Deshalb habe ich mich nur gefragt woher weiß der Service, dass der SEPIA Server down ist obwohl der Container noch läuft :thinking: . Dazu müsste man eigentlich einen SEPIA enpoint auf Erreichbarkeit prüfen.