Nach Update auf 3.43.15.20190223 kein Erreichen der WebUI mehr möglich

[quorle]

Update:

Ich habe mal folgendes gemacht:

Code: Alles auswählen

/etc/init.d/S50lighttpd restart

Ausgabe: Stopping lighttpd: OK
Starting lighttpd: OK

Nun sehe ich die WebUI wieder.

Ich werde nun mal IPV6 wieder aktivieren und den RPI neu starten, mal sehen was dann passiert.

UPDATE:

Nach einem Neustart war alles beim alten. Trotzt aktiviertem IPV6 konnte man auf die WebUI zugreifen.
SSH funktioniert auch.

Wenn mir jemand den genauen Speicherort nennt und den passenden Befehl könnte man einmal in der LOG nachsehen.

[jmaus]

Habe ich erledigt, leider ohne Erfolg.
Habe auch jetzt IPV6 im Router deaktiviert. Hilft auch nichts

War ein Versuch wert. Dann gehen mir leider gerade die Ideen aus...

[jmaus]

Wenn mir jemand den genauen Speicherort nennt und den passenden Befehl könnte man einmal in der LOG nachsehen.

Die Logfiles des lighttpd liegen unter /var/log/lighttpd-error.log und dort drin sollte der Grund dann stehen warum er nicht automatisch mit dem Neustart gestartet wird bzw. abgeschmiert ist. Schau da mal rein wenn es das nächste mal nicht mehr geht.

[quorle]

Gerade den Fehler wieder gehabt.

Folgendes tat ich:

Code: Alles auswählen

ps|grep rega

Ergab: 1987 root 0:00 grep rega

Habe ReGa mit:

Code: Alles auswählen

/etc/init.d/S70ReGaHss start

neu gestartet, da die Ausgabe eigentlich ja

Code: Alles auswählen

/bin/ReGaHss -f /etc/rega.conf -l 2

sein sollte.

Im Anschluss muss noch der Lighttpd mit:

Code: Alles auswählen

/etc/init.d/S50lighttpd restart

neu gestartet werden.

Hier einmal die Log vom Lighttpd:

Code: Alles auswählen

# tail /var/log/lighttpd-error.log
2019-02-26 00:17:12: (mod_auth.c.517) password doesn't match for / username: Adm                                                  in, IP: 192.168.2.102
2019-02-26 00:17:12: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:16:58: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:20:21: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:18:51: (mod_auth.c.517) password doesn't match for / username: Adm                                                  in, IP: 192.168.2.102
2019-02-26 00:18:51: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:21:47: (server.c.1457) server started (lighttpd/1.4.52)
2019-02-26 00:21:48: (gw_backend.c.240) establishing connection failed: Connecti                                                  on refused socket: tcp:127.0.0.1:8183
2019-02-26 00:21:48: (gw_backend.c.955) all handlers for /favicon.ico? on  are d                                                  own.
2019-02-26 00:21:50: (gw_backend.c.319) gw-server re-enabled: tcp:127.0.0.1:8183                                                   127.0.0.1 8183

Sollte es noch einmal vorkommen, wo finde ich die Log vom ReGa? Eventuell ein BUG?

[jmaus]

Sollte es noch einmal vorkommen, wo finde ich die Log vom ReGa? Eventuell ein BUG?

Das sieht momentan wirklich nach einem Bug aus. Die syslog ausgaben von ReGa sollten in /var/log/messages landen.

Was mich aber anhand deiner Ausgaben nun interessiert:

1) Heisst dein Nutzer unter dem du dich einloggst wirklich "Adm" ?

2) Hast du in der WebUI unter Sicherheit wirklich die "Authentifizierung" aktiviert? Und hast du irgendein externen Dienst (z.b. ioBroker) das via. XMLRPC mit Nutzername und Passwort regelmäßig zugreift? Wenn ja wäre es ggf hilfreich wenn du mir in einer PN mal die exakten Nutzerdaten (Name+Passwort) verraten könntest damit ich das Problem nachstellen kann. Meine aktuelle Vermutung ist nämlich das irgendetwas in den Authentifizierungsdaten dazu führt das ReGa bzw lighttpd abstürzen...

[stan23]

1) Heißt dein Nutzer unter dem du dich einloggst wirklich "Adm" ?

Nein, da waren nur viele Leerzeichen drin, und der Rest der Zeile nach rechts gerutscht.

So sieht es besser aus:

Hier einmal die Log vom Lighttpd:

Code: Alles auswählen

# tail /var/log/lighttpd-error.log
2019-02-26 00:17:12: (mod_auth.c.517) password doesn't match for / username: Admin, IP: 192.168.2.102
2019-02-26 00:17:12: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:16:58: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:20:21: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:18:51: (mod_auth.c.517) password doesn't match for / username: Admin, IP: 192.168.2.102
2019-02-26 00:18:51: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:21:47: (server.c.1457) server started (lighttpd/1.4.52)
2019-02-26 00:21:48: (gw_backend.c.240) establishing connection failed: Connection refused socket: tcp:127.0.0.1:8183
2019-02-26 00:21:48: (gw_backend.c.955) all handlers for /favicon.ico? on  are down.
2019-02-26 00:21:50: (gw_backend.c.319) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183

[jmaus]

1) Heißt dein Nutzer unter dem du dich einloggst wirklich "Adm" ?

Nein, da waren nur viele Leerzeichen drin, und der Rest der Zeile nach rechts gerutscht.

So sieht es besser aus:

Hier einmal die Log vom Lighttpd:

Code: Alles auswählen

# tail /var/log/lighttpd-error.log
2019-02-26 00:17:12: (mod_auth.c.517) password doesn't match for / username: Admin, IP: 192.168.2.102
2019-02-26 00:17:12: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:16:58: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:20:21: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:18:51: (mod_auth.c.517) password doesn't match for / username: Admin, IP: 192.168.2.102
2019-02-26 00:18:51: (server.c.2052) server stopped by UID = 0 PID = 1911
2019-02-26 00:21:47: (server.c.1457) server started (lighttpd/1.4.52)
2019-02-26 00:21:48: (gw_backend.c.240) establishing connection failed: Connection refused socket: tcp:127.0.0.1:8183
2019-02-26 00:21:48: (gw_backend.c.955) all handlers for /favicon.ico? on  are down.
2019-02-26 00:21:50: (gw_backend.c.319) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183

Verstehe. Und wer ist nun die 192.168.2.102 die angeblich das Passwort falsch eingibt? Die Frage wäre halt wann genau die ReGa anscheinend abschmiert. Wie regelmäßig passiert denn das bei dir? Wenn das recht regelmäßig passiert könntest du ja einfach mal ReGaHss von Hand starten und dann die SSH Konsole über nacht offen lassen und schauen zu welcher Uhrzeit genau das Absturz passiert ist. Dann könnte man schauen (und ich dir ggf. eine Debugversion von ReGaHss zusenden) ob man den eigentlich Grund für den Absturz herausfindet und repariert. Denn natürlich sollte die ReGaHss niemals abstürzen...

Und wenn du lighttpd neustartest, kannst du vorher mal schauen ob denn wirklich alle lighttpd Prozesse zu dem Zeitpunkt auch weg sind? D.h. dort auch mittels "ps aux" aufruf schauen ob der lighttpd-angle und seine lighttpd Subprozesse noch laufen oder ob die wirklich auch weg sind? Das sollte nämlich eigentlich auch nie passieren.

[quorle]

Guten Morgen,

Heute lief alles einwandfrei. Ich habe dir aber die PN mit den Daten gesendet.

Hier war wirklich ein kleiner Konvertierungsfehler drin. Danke für´s berichtigen

[jmaus]

Heute lief alles einwandfrei. Ich habe dir aber die PN mit den Daten gesendet.

Hier war wirklich ein kleiner Konvertierungsfehler drin. Danke für´s berichtigen

Danke. War gerade kurz verwirrt warum jemand anders das Log nochmal neu postet. Aber gut, nun hab ich es kapiert

Wie gesagt, du müsstest ggf. mal mehr Logging machen und ggf. ReGaHss mal von Hand starten und schauen wann genau es abschmiert und ob die lighttpd Prozesse auch wirklich in dem moment weg sind. Sowas sollte normal nicht passieren. Und dann eben auch mal sagen ob du die XMLRPC Authentifizierung nutzt oder nicht und die Passwortdaten folglich so in ioBroker eingetragen hast?

[quorle]

Also die Passwörter stimmen alle in ioBroker. Für ReGa und RPC0 ( XML-RPC ) in ioBroker nutze ich die Https - Authentifizierung.
Für den RPC1 ( CuXD --> BIN-RPC ) nutze ich die httpy - Authentifizierung nicht

Wie meinst du das mit mehr logging? Einfach in der WebUI --> Systemsteuerung --> Zentralen Wartung --> Fehlerprotokoll --> Alles loggen auswählen?