Keine commits mehr unter FHEM Code changes

Begonnen von betateilchen, 28 November 2025, 09:11:08

Vorheriges Thema - Nächstes Thema

CoolTux

Also eigentlich müsste das in eine .htaccess Datei geschrieben werden und diese Datei kommt dann in das webroot der Subdomaine
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Otto123

#31
aber .htaccess ist doch nur die "Hilfe" wenn man die site Datei nicht bearbeiten kann? Zumindest habe ich das bisher immer so gesehen. Und eine subdomain gibt es ja auf dem Server nicht, der steht für sich allein.
Habs aber noch so gemacht wie Du gesagt hast. Kann ich irgendwo im Log sehen das es greift?

Irgendetwas wirkt zumindest jetzt, ich habe noch eine Begrenzung der Anfragen pro IP im Proxy eingebaut.

man könnte noch den Chrome 125 aussperren, der macht den meisten Verkehr
Zitat1.983.265 (90.23%)    288.311 (64.35%)    11.75 GiB (79.40%)    Chrome/125.0.0.0
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Sidey

Hallöchen,

nur mal 5ct von mir.

Der mirror im git lief einige Zeit nicht, leider so lange dass auch der cache weg war.
Ich habe den Workflow repariert und den Workflow etliche male laufen lassen.
Bis r30600 ist der Job gestern gekommen, seit dem hängt er an dem HTTP Status 503.

Mein erster Gedanke war, dass vielleicht die Workflows Schuld an den vielen Anfragen sind.
Die hohe Last aus dem Screenshot passt aber nicht richtig zu den runs.

Als Abgleich:
Der reparierte Workflow lief erstmalig "Dec 6, 3:01 AM" für eine Stunde.
Der Workflow lief heute 3:17 AM und 11:37 AM je unter 2 Minuten. (Abbruch wegen http 503)


An welchem Tag haben die Probleme denn angefangen?

Grüße Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Otto123

#34
Zitat von: Sidey am 09 Dezember 2025, 19:37:46An welchem Tag haben die Probleme denn angefangen?
Immer mal geht das seit ein paar Tagen so, in der Regel waren es aber nur Minuten bis ein halbe Stunde.
Seit gestern 16:30 Uhr lief dann fast Dauerlast, sieht man doch in dem Bild ganz gut. Alles was über 150 ms ist, ist quasi aus dem normalen Rahmen. Also im Bild sind auch die grünen Peaks lediglich "Seite erreicht" innerhalb eines Timeouts von 25 sec.
Am 6.12. gab es keine hohe Belastung, ich denke Du bist nicht Schuld :)

Aber ob Du derzeit eine Fehlerfreie Runde drehen kannst, kann ich nicht vorhersagen. Die Belastung ist derzeit nicht von Dauer sondern eher in Impulsen. welche IP initiert das?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Otto123

#35
ich habe jetzt noch den Chrome User Agenten 125.x.x.x und leere Agenten (die wohl bots gerne setzen) im proxy nur für svn.fhem.de geblockt.

Chrome 125 hatte heute mit 2,7 Mio Hits die Spitze. :)

Ich hoffe das keine Nebeneffekte. Eigentlich wollte ich heute was vernünftiges machen ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz