[Erledigt] LanManager: Timeout-Fehler

Hallo,

Ich habe ein ähnliches Konfigurationsproblem wie hier beschrieben:

Vor Version 4.40 oder 4.39 (ich weiß nicht mehr genau) … hatte ich doch Geräte erkannt.

Ich habe alle bisher erkannten Geräte gelöscht, in der Hoffnung, dass es dann funktioniert, aber nein.

Der Fehler:
2024-05-21T19:25:45+0200 <error> lan-manager.scan.js:58 (NmapScan.onError) LANManager fails to discover devices over network - Over scan timeout 120000

Ich bin auf v4.41.0: Ich habe mir erlaubt, mit einem höheren Timeout zu testen, indem ich direkt im Container geändert habe.

Ich denke, ich habe ein anderes Problem als ein Anwendungsproblem, denn in meinem Container erhalte ich ein Nmap-Ergebnis in 3 Sekunden:

rpi3:~/gladys $ docker exec -it gladys sh
/src/server # nmap -sn -R 192.168.0.xxx/24
Starting Nmap 7.94 ( https://nmap.org ) at 2024-05-21 19:27 CEST
[...]
Nmap done: 256 IP addresses (24 hosts up) scanned in 3.30 seconds

Der Docker wird mit privileged = true gestartet …

Das Betriebssystem:

rpi3:~/$ uname -a
Linux rpi3 6.6.20+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.20-1+rpt1 (2024-03-07) armv7l GNU/Lin
rpi3:~/$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm

Auf einer Entwicklungsinstanz habe ich das Problem nicht (vorausgesetzt, ich starte den Server als root, aus Gründen der Nmap-Berechtigungen …)

Ich verstehe es nicht ganz, wenn jemand Tipps hat, um mir zu helfen, bin ich dankbar :wink:

Ich habe gerade einen Test gemacht, einfach so: auf einer Debian-VM mit dem gleichen Docker Compose funktioniert es …

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm

uname -a
Linux Debian12 6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1 (2023-09-07) x86_64 GNU/Linux

Der einzige Unterschied ist auf einer frischen Instanz … (leere Datenbank) .. zur Sicherheit habe ich den Produktions-Pi3 neu gestartet, aber das ändert nichts.

Meine Produktionsdatenbank stammt von … (keine Ahnung - Anfang von Gladys 4?) und ist 9 GB groß.
Falls ich den Mut habe, mache ich einen Test in der Produktion mit einer leeren Datenbank, um Hardware und Betriebssystem auszuschließen …

Hmm … ich bin schon etwas enttäuscht: Mit einer leeren Datenbank wurden 28 Geräte in 6 Sekunden entdeckt. Daraus schließe ich, dass das Problem mit der Weiterentwicklung der Versionen aufgetreten ist und dass ich der Einzige bin, der betroffen ist. Hat jemand einen Tipp, wie ich meine ursprüngliche Datenbank wieder in Ordnung bringen kann? Andernfalls denke ich, dass wir dieses Monolog beenden können :wink:

Es tut mir leid @ProtZ, ich kann dir nicht helfen, aber sei ein bisschen geduldig, ich denke, dass bald jemand Kompetentes vorbeikommen wird, um dir zu helfen!

Hallo @ProtZ :slight_smile:

Wenn du sagst, dass du Tests durchgeführt hast, war das auf genau der gleichen Hardware?

Aus den Logs, die ich sehe, läuft deine ursprüngliche Installation auf einem « armv7l »-Prozessor, also Raspberry Pi 1, 2 oder Zero. Allerdings erwähnst du, dass du auf einem Pi 3 bist, also hast du wahrscheinlich ein ARMv7-System auf deinem Pi 3 installiert, der selbst ARMv8 ist, schade ^^

Dann führst du deine Tests auf einer Debian-VM mit einem amd64-CPU aus, also nehme ich an, eine gute Maschine ^^

Das ist nicht dasselbe!

Vor allem zwischen ARMv7 und v8 gibt es große Leistungsunterschiede im JS-Engine aufgrund von Anweisungen, die in v8 hinzugefügt wurden.

Das heißt, es ist möglich, dass deine Installation « Dinge im Hintergrund zu tun » hat, dafür müsste man die Logs, die CPU-Aktivität, sehen, was passiert.

Jetzt, wenn du vorhast, eine Gladys-Installation « langfristig » wieder auf die Beine zu stellen, rate ich dir dringend, deine Hardware zu überarbeiten. Heute empfiehlt man Mini-PCs, um einen guten CPU zu haben, und vor allem eine SSD-NVMe, die hält. Auf den Pi wird die SD-Karte sehr schnell beschädigt, und das Anschließen einer SSD per USB funktioniert nicht super (häufiges Stromversorgungsproblem, fragwürdige USB-Port-Leistung) :slight_smile: Ich empfehle diesen Mini-PC.

Falls es dich interessiert, ich biete derzeit ein Starter-Kit an, kontaktiere mich privat, wenn es dich interessiert :wink:

Danke @guim31 und @pierre-gilles für eure Antworten.

Wenn du sagst, dass du Tests durchgeführt hast, war das auf genau derselben Hardware?
Genau, der auffälligste Test auf meinem Pi3: Mit meiner ursprünglichen Datenbank von 9 GB ist es ein Fehlschlag (obwohl es einmal funktioniert hat), aber mit einer neuen Installation (Datenbank bei 0) ist es OK.

Aus den Logs, die ich sehe, läuft deine ursprüngliche Installation auf einem Prozessor „armv7l“, also Raspberry Pi 1, 2 oder Zero.
Allerdings erwähnst du, dass du auf einem Pi 3 bist, also hast du wahrscheinlich ein ARMv7-System auf deinem Pi 3 installiert, der selbst ARMv8 ist, schade ^^

Danke, dass du das bemerkt hast! Was für ein Adlerauge! Ich habe es nicht bemerkt, es ist tatsächlich ein Pi3, installiert mit Pi OS Bookworm (Debian 12) und es ist eine Installation mit dem Standardbild des Raspberry-Installers. Seltsam, dass es nicht in v8 angeboten wird, und die Erklärung steht in den Anweisungen unten für die Neugierigen.

Ich bin zu ARM v8 übergegangen, indem ich diesen Anweisungen gefolgt bin.

rpi3:~ $ uname -a
Linux rpi3 6.6.31-v8+ #1766 SMP PREEMPT Fri May 24 12:14:10 BST 2024 aarch64 GNU/Linux

Dann führst du deine Tests auf einer Debian-VM mit einem AMD64-CPU aus, also nehme ich an, eine gute Maschine ^^
Das ist nicht dasselbe!
Das ist auf meinem NAS, das eine separate Maschine ist (Truenas Scale)

Vor allem gibt es zwischen ARMv7 und v8 große Leistungsunterschiede im JS-Engine aufgrund von Anweisungen, die in v8 hinzugefügt wurden.
Ich stelle tatsächlich einen sehr sichtbaren Gewinn fest: Allein dafür schon DANKE.

Das heißt, es ist möglich, dass deine Installation „Dinge im Hintergrund zu tun“ hat, dafür müsste man die Logs, die CPU-Aktivität, sehen, was passiert.

Nicht viel, da läuft nichts und man sieht den nmap:

Und da BAM! Der Auslöser war der Befehl:
nmap -oX - -sn -R 192.168.0.22/24 192.168.0.180/16 192.168.0.182/16

Wenn man ihn manuell ausführt, dauert es sehr lange.

Die Schuldigen, die IPs, die ich im Scanner-Tab von Lan-Manager für die Anwesenheit eingetragen hatte:(
Genauer gesagt die IPs der Geräte, deren Anwesenheit ich kontrollieren wollte, aber /16 statt /24… Ich habe das Netzwerk immer gehasst und es hat mich immer zurückgegeben)

Wenn du vorhast, eine Gladys-„Langzeit“-Installation wieder aufzubauen, empfehle ich dir dringend, deine Hardware zu überarbeiten, heute empfiehlt man Mini-PCs, um einen guten CPU zu haben, und vor allem eine SSD NVMe, die hält.
Auf den Pi wird die SD-Karte sehr schnell beschädigt, und eine SSD an USB anzuschließen funktioniert nicht gut (häufiges Stromversorgungsproblem, fragwürdige USB-Port-Leistung) :slight_smile: Ich empfehle diesen Mini-PC für meinen Teil.

Dieser Mini-PC ist Spitze und gerade im Angebot! Aber meine SD-Karte ist brandneu; die andere hat tatsächlich nur 6 Jahre gehalten und pouf… Daneben habe ich einen Pi4 mit SSD - der bisher keine Stromversorgungsprobleme hatte - oder mein NAS mit NVMe für die Apps, aber das ist Overkill, finde ich

Was ich wollte, war vor allem verstehen, ohne etwas zu ändern (es gab keinen Grund dafür), also ein großes Dankeschön für deine Zeit, das war ein tolles Abenteuer, diese Sache!

Top, wenn du deine Probleme gelöst hast :slight_smile:

Wie du meinst, aber wenn du eine solide Smart-Home-Installation bei dir zu Hause 24/7 mit Dutzenden von Geräten laufen lassen willst, ist das der schnellste Weg, dass alles den Geist aufgibt.

Vielleicht hattest du beim letzten Mal Glück, aber es kann genauso gut einen Monat wie sechs Jahre halten… Und vor allem ist der Leistungsunterschied enorm, sobald deine Installation gut gefüllt ist

Ich empfehle wirklich den Mini-PC!