IPS auf Raspberry Pi 4 mit Docker Swarm -> Error beim ersten Hochfahren

[CryoGenID]

Hallo liebe Gemeinde,

nach vielen vielen Jahren von IPS auf meiner Windows VM dachte ich mir ich baue mal was Neues
Und zwar hab ich einen Docker Swarm mit 4 Raspberry PI 4 aufgesetzt…
Grundsätzlich läuft das auch…
Aber (ihr ahnt es schon) leider kämpfe ich gerade mit IPS:
Dank den super Tipps von hier (Docker Container mit IP Symcon auf Raspberry PI) konnte ich mein erstes „eigenes“ Image erstellen und dann auch starten…
Und da kommt es schon, ich hänge in einer Endlosschleife fest…
Das hier zeigt das Log:

08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | Creating...
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | Platform: Raspberry Pi
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | Version: 5.4
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | Revision: a4291b6bfb15f5fae678fe10ef39bd1349e62b6f
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | Build: 07/23/20
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | WorkingDir: /var/lib/symcon/
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | SystemDir: /usr/share/symcon/
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | LogDir: /var/log/symcon/
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | Boost Version: 1_72
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | cURL Version: libcurl/7.69.1 OpenSSL/1.1.1f zlib/1.2.11
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | Git2 Version: 1.0.0
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | SSH Version: 0.9.3
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | ZLIB Version: 1.2.11
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | RapidJSON Version: 1.1.0
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | OpenSSL Version: OpenSSL 1.1.1f  31 Mar 2020
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | OpenSSL CertDir: /usr/share/symcon/
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | OpenSSL CertFile: /usr/share/symcon/cacert.pem
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | XML2 Version: 20910
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | XML2 Threads: Yes
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | PHP Version: 7.3.16
08/14/20 14:56:07 | 00000 | MESSAGE | Kernel               | Initializing...
08/14/20 14:56:07 | 00000 | MESSAGE | LocalePool           | Creating...
08/14/20 14:56:07 | 00000 | MESSAGE | LocalePool           | Erkanntes Gebietsschema: de_DE
14.08.2020 14:56:07 | 00000 | MESSAGE | LicensePool          | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | LicensePool          | Kann die Lizenz nicht überprüfen. Läuft im Demo-Modus.
14.08.2020 14:56:07 | 00000 | MESSAGE | LicensePool          | Demo läuft ab am 14.08.2020 15:56:07
14.08.2020 14:56:07 | 00000 | MESSAGE | Settings             | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | ObjectManager        | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | ObjectManager        | Erstelle Root-Kategorie...
14.08.2020 14:56:07 | 00000 | MESSAGE | CategoryManager      | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | VariableManager      | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | InstanceManager      | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | ScriptManager        | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | EventManager         | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | MediaManager         | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | LinkManager          | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | ModuleLoader         | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | FlowHandler          | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | SyncHandler          | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | ProfilePool          | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | ScriptEngine         | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | ScriptEngine         | Erkannte Zeitzone: Europe/Berlin
14.08.2020 14:56:07 | 00000 | MESSAGE | ScriptEngine         | Starte 25 Skript-Threads...
14.08.2020 14:56:07 | 00000 | MESSAGE | TimerPool            | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | DataServer           | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | DiscoveryServer      | Erstelle...
14.08.2020 14:56:07 | 00000 | DEBUG   | DiscoveryServer      | Betrete Multicastgruppe für Schnittstelle 10.0.0.41
14.08.2020 14:56:07 | 00000 | DEBUG   | DiscoveryServer      | Betrete Multicastgruppe für Schnittstelle 10.0.7.9
14.08.2020 14:56:07 | 00000 | DEBUG   | DiscoveryServer      | Betrete Multicastgruppe für Schnittstelle 172.18.0.4
14.08.2020 14:56:07 | 00000 | MESSAGE | DebugServer          | Erstelle...
14.08.2020 14:56:07 | 00000 | MESSAGE | Settings             | Erstelle Einstellungen Thread...
14.08.2020 14:56:07 | 00000 | MESSAGE | Settings             | Aufräumen des Backup Ordners...
14.08.2020 14:56:07 | 00000 | MESSAGE | Kernel               | boost::filesystem::directory_iterator::operator++: Der Wert ist zu groß für den definierten Datentyp: "/var/lib/symc
on/backup"
14.08.2020 14:56:07 | 00000 | MESSAGE | Kernel               | Entferne...
14.08.2020 14:56:07 | 00000 | SUCCESS | Kernel               | *** IPS HERUNTERFAHREN ABGESCHLOSSEN

Er hat da wohl irgendein Problem mit dem backup Ordner… Es ist aktuell alles noch auf „jungfräulich“, d.h. ich habe noch kein Backup o.ä. hinterlegt…

So sieht bei mir das „data“ Verzeichnis aus:

drwxrwxrwx  2 pi pi 4096 Aug 14 16:54 backup
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 cert
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 db
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 media
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 minidump
drwxrwxrwx  3 pi pi 4096 Aug 14 16:47 modules
-rw-rw-rw-  1 pi pi  533 Aug 14 16:56 php.ini
drwxrwxrwx  2 pi pi 4096 Aug 14 16:47 scripts
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 session
drwxrwxrwx  4 pi pi 4096 Aug 14 16:47 webfront

Also die Verzeichnisse etc. wurden alle erfolgreich von IPS angelegt…

Habt ihr eine Idee was das sein kann, damit ich das hinbekomme?

Danke Euch

Viele Grüße

Chris

[CryoGenID]

Kann wirklich niemand helfen? Ich würde das echt gerne zum Laufen bringen

Danke Euch

Viele Grüße

Chris

[paresy]

Wir unterstützen Docker offiziell nur auf x64/amd64 Systemen. Somit müsstest du dein IP-Symcon auf dem Pi ohne Docker installieren damit wir bei Probleme helfen können

paresy

PS: Ich weiß nicht wie die Persistenz beim Swarm Modus läuft - scheinbar hat er ein Problem mit dem Backup Ordner… Gibt es den überhaupt bei dir?

[CryoGenID]

Hallo Paresy,

vielen Dank für Deine Rückmeldung!
Könntet ihr nicht vielleicht doch auch die ARM-Version für Docker offiziell bereitstellen? Ich denke das wird in Zukunft auch immer mehr werden…

Aber zu Deiner Frage (damit wir das hoffentlich doch noch gelöst bekommen):
Es ist eigentlich gar kein Unterschied vom normalen Docker zum Swarm im Bezug auf die Persistenz, d.h. auch hier wird ein Verzeichnis aus dem lokalen Speichersystem angegeben.
So sieht das in meinem Fall aus:

version: "3.8"
services:
  ipsymcon:
    image: localhost:5000/ipsymcon
    environment:
      - TZ="Europe/Berlin"
    volumes:
      - ips_root:/root
      - ips_log:/var/log/symcon
      - ips_data:/var/lib/symcon
    ports:
      - 3777:3777
      - 2001:2001
      - 2010:2010
      - 5544:5544
    deploy:
     mode: replicated
     replicas: 1
volumes:
 ips_root:
  driver: glusterfs
  name: "gv0/ipsymcon__1/root"
 ips_log:
  driver: glusterfs
  name: "gv0/ipsymcon__1/log"
 ips_data:
  driver: glusterfs
  name: "gv0/ipsymcon__1/data"

Und hier der Teil des Dateisystems:

drwxr-xr-x  5 pi   pi   4096 Aug 14 16:46 .
drwxrwxrwx 10 root root 4096 Aug 14 16:46 ..
drwxrwxrwx 11 pi   pi   4096 Aug 14 16:47 data
drwxrwxrwx  2 pi   pi   4096 Aug 20 20:01 log
drwx------  3 pi   pi   4096 Aug 14 16:47 root
pi@DS1:/mnt/gfs__gv0/ipsymcon__1 $ ls -la data/
total 45
drwxrwxrwx 11 pi pi 4096 Aug 14 16:47 .
drwxr-xr-x  5 pi pi 4096 Aug 14 16:46 ..
drwxrwxrwx  2 pi pi 4096 Aug 14 16:54 backup
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 cert
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 db
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 media
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 minidump
drwxrwxrwx  3 pi pi 4096 Aug 14 16:47 modules
-rw-rw-rw-  1 pi pi  533 Aug 20 20:01 php.ini
drwxrwxrwx  2 pi pi 4096 Aug 14 16:47 scripts
drwxrwxrwx  2 pi pi 4096 Aug 14 16:18 session
drwxrwxrwx  4 pi pi 4096 Aug 14 16:47 webfront
pi@DS1:/mnt/gfs__gv0/ipsymcon__1 $ ls -la data/backup/
total 8
drwxrwxrwx  2 pi pi 4096 Aug 14 16:54 .
drwxrwxrwx 11 pi pi 4096 Aug 14 16:47 ..
pi@DS1:/mnt/gfs__gv0/ipsymcon__1 $

Wie du siehst hat IPS beim ersten Start brav alle Verzeichnisse unter „data“ angelegt, es ist auch das „backup“ Verzeichnis da…
D.h. Zugriffsrechte passen…

Wäre toll, wenn Du mir trotzdem helfen könntest

Viele Grüße

Chris

[CryoGenID]

So ich habe nochmal ein paar Stunden investiert…

Leider hat es keine Lösung gebracht…

Ich habe nun innerhalb eines Raspbian Buster Containers per Hand genau 1:1 die Installationsvorgaben für eine normale RaspberryPi Installation gemacht (da ist jetzt ja kein Unterschied mehr), aber der Fehler bleibt bestehen…

@Paresy: Könntet ihr ggf. eine Version bauen, die bei der Stelle einfach nur ein Warning bringt aber nicht gleich komplett abstürzt?

Ich habe mir das ganze Docker-Theater primär wegen IPS angetan und genau DAS geht jetzt nicht

Ich hoffe ihr helft mir (und bestimmt auch anderen Usern in Zukunft)

Danke!

Viele Grüße

Chris

[CryoGenID]

Und wieder ein Update…
Diesmal habe ich (nachdem Du das Thema mit der Persistenz des Daten aufgebracht hast) mal alle volumes aus dem Docker file rausgenommen, damit alles im Container bleibt…
Da ist IPS tatsächlich hochgefahren!

Also liegt das Problem irgendwie an der Volume-Einbindung… Was ich aber sehr komisch finde, da ja alle Dateien etc. vorher sauber von IPS angelegt werden…
Eine Suche nach dem Fehler „boost::filesystem::directory_iterator::operator++: Value too large for defined data type“ hat aber einige Diskussionen über gleiche Fehler hervorgebracht… Da scheint es (unabhängig von Docker, glusterFS, etc.) immer wieder zu Problemen zu kommen…
Siehe z.B. hier: c - error opening file for reading: Value too large for defined data type - Stack Overflow
Es scheint auch teilweise mit 32-bit <-> 64-bit zu tun zu haben… Und mein Docker auf dem Raspi läuft mit 64-bit… Könnte das hier auch ein Thema sein (siehe die Stackoverflow-Info)?

@Paresy: Könntet ihr da ggf. mal schauen? Das wäre klasse! Danke

Viele Grüße

Chris

[paresy]

Für den RPi haben wir aktuell nur eine 32 Bit Version. Ich würde auch vorschlagen, dass du Testweise das System mal auf einem 32 Bit OS hochfährst und schaust ob dies das Problem war.

Wenn ja, ist die Docker Abstraktion zwischen 32 Bit und 64 Bit fehlerhaft und wir könnten dort nur umschiffen (was im aktuell Fall zeitlich nicht rentabel ist, wenn du mich verstehst :)). Auf lange Sicht wird es bestimmt eine 64 Bit Version geben - zumindest schauen wir uns das an, sobald es ein Stable Release vom Raspberry Pi OS in 64 Bit gibt. Die aktuellen Previews sind noch lange nix.

paresy

[CryoGenID]

Hallo Paresy,

danke für Deine Rückmeldung!

Also nachdem ich nochmal ewig Zeit investiert habe, läuft es jetzt bei mit im Docker Swarm (mit 4*Raspberry PI 4) und glusterFS und mit 64-bit

Ich kann jetzt automatisch ein Image erzeugen mit Raspbian Buster + IPS und einer automatischen Backup-Lösung…

Es läuft jetzt so:
IPS läuft komplett im Container, aber alle (aktuell) 5 Sekunden synchronisieren sich die drei Volumes, die sonst nach Außen persistiert werden, in persistentes Backup-Image nach Außen.
Damit habe ich das Absturzproblem gelöst und trotzdem habe ich alle Daten „fast“ in Echtzeit in meinem glusterFS gesichert. Diese werden dann auch automatisch beim Neustart wieder in den Container kopiert, sodass man den Container problemlos starten/stoppen kann.

Damit auch andere User davon profitieren können (ich bin da noch nicht so der Experte mit Docker und so ):
Kann/darf ich das finale erzeugte Image auch im DockerHub zur Verfügung stellen? Oder verstößt das gegen irgendwelche Regeln/Lizenzrechte?

Viele Grüße

Chris