nginx 502 Bad Gateway nach reboot

Begonnen von timtom, 25 November 2018, 17:19:24

Vorheriges Thema - Nächstes Thema

timtom

Hallo zusammen,

nachdem fhem lange sehr stabil bei mir lief, habe ich jetzt diverse Probleme. Ob das mit dem Upgrade auf Stretch zusammenhängt oder dem letzen fhem Update, kann ich leider nicht mehr nachvollziehen. Leider bin ich kein Linux-Experte und bin auch nach fleißigem googlen nicht auf eine Lösung gekommen. Bin jetzt wieder seit über 5 Std dran und bekomme einfach nichts besser hin.

Ich nutze nginx als Reverse-Proxy, was eigentlich auch gut funktioniert. Mein Problem ist, dass jedes mal wenn ich den RPi2 reboote ich beim Aufruf von fhem folgenden Fehler bekommen "502 Bad Gateway". Soweit ich das beurteilen kann, läuft nginx jedoch.

Wenn ich jedoch dann über "sudo /etc/init.d/nginx restart" nginx neu starte, kann ich fhem wie gewohnt aufrufen. Woran könnte das liegen? Wird beim Systemstart nginx auch per sudo ausgeführt?

Vielen Dank schon mal für eure Hilfe
der Tim

Wernieman

Wie hast Du den Proxy eingerichtet?

Wenn Du einen tiefen reload des Browsers machst (Firefox unter Linux: Ctr-F5, unter Windows/Mac ???) funzt es dann?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

timtom

Zitat von: Wernieman am 26 November 2018, 08:05:27
Wie hast Du den Proxy eingerichtet?
Was meinst du damit genau? Die "sites-enabled" Config funktioniert ja grundsätzlich nach dem manuellen Reload. Irgendwo hakt es, immer nur, wenn der RPi rebooted wird. Nginx startet auch. Man sieht die Standardstartseite, wenn ich die URL aufrufe. Mit URL/fhem kommt dann leider der "502 Bad Gateway". Wenn du mir sagst, was du genau bzgl. Setup benötigst, stell ich's hier ein.

Ich hatte gedacht, dass ggf. an Berechtigungen liegt. Irgendwie habe ich da wohl etwas verhunzt und ich bekomme einen Fehler
error: skipping "/var/log/nginx/access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
Wie sollten denn die Berechtigungen aussehen? Meine sind exemplarisch wie folgt:
-rwxr-xr-x 1 www-data adm 198 Nov 25 17:04 access.log

Zitat von: Wernieman am 26 November 2018, 08:05:27
Wenn Du einen tiefen reload des Browsers machst (Firefox unter Linux: Ctr-F5, unter Windows/Mac ???) funzt es dann?
Leider nicht :(

Wernieman

...because parent directory...
Also gib uns mal die Berechtigung des Direktorys davor! Es betrifft aber eigentlich nur das logging und nicht das Funktionieren des Proxys.

Ich habe hier einige nginx-Proxys vor docker-Containern. Wenn der Container weg ist, gibt es natürlich einen 502. Wenn der Container aber wieder da ist, gibt es sofort die Richige Seite.

Deshalb würde ich gerne wissen, wie Du den Proxy eingerichtet hast.

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

timtom

Zitat von: Wernieman am 26 November 2018, 09:27:05
...because parent directory...
Also gib uns mal die Berechtigung des Direktorys davor!...
Du meinst das hier?
drwxr-xr-x  2 root   adm      4096 Nov 25 00:08 nginx

Zitat von: Wernieman am 26 November 2018, 09:27:05
Deshalb würde ich gerne wissen, wie Du den Proxy eingerichtet hast.
Das ist die config in sites-enabled
server {
    listen 80;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name 192.168.1.x 10.1.0.x dyndns.url.de;

    ssl_certificate           /etc/letsencrypt/live/dyndns.url.de/fullchain.pem;
    ssl_certificate_key       /etc/letsencrypt/live/dyndns.url.de/privkey.pem;
    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/jenkins.access.log;

    location /fhem {

      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;
      proxy_http_version      1.1;
      # proxy_set_header        Upgrade $http_upgrade;
      proxy_buffering         off;
      # proxy_ignore_client_abort off;
      # break;

      proxy_pass          http://localhost:8083;
      proxy_read_timeout  90;

      auth_basic "Restricted Content";
      auth_basic_user_file /etc/nginx/.htpasswd;

      satisfy any;
      allow 192.168.1.0/24;
      allow 192.168.200.0/24;
      allow 10.1.0.0/24;
      deny all;

      # proxy_redirect      http://localhost:8083 https://localhost;
    }
}

Falls du etwas anderes benötigst, lass es mich gerne wissen. Bin in Linux halt nicht so firm. Und wie gesagt, wenn ich nach dem RPi reboot nginx noch einmal neu starte, dann geht es auch wieder. Vorher kann man allerdings sehen, dass nginx auch läuft, jedoch nicht direkt so, wie konfiguriert.

Wernieman

Absicht, das es nur aus dem Internen Netz geht?

Sorry aber aus privaten Gründen bin ich diese Woche erstmal offline
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

timtom

Zitat von: Wernieman am 26 November 2018, 21:24:34
Absicht, das es nur aus dem Internen Netz geht?
Ja, ist beabsichtigt. Mir ist aufgefallen, dass so 1x am Tag fhem nicht zu erreichen ist. Weder über Browser noch über andere Dienste, z.B. alexa. Im Browser kommt ein timeout. Ich kann mich jedoch nach wie vor auf dem Rpi einloggen. Starte ich nginx neu, lasst sich fhem wieder im Browser öffnen und über alexa bedienen.

Ich kenne mich leider nicht so gut mit Linux aus. In welchen logs könnte ich mal schauen, um dem Fehler auf den Grund zu gehen?

timtom

#7
So, mittlerweile habe die einige Fehler behoben.

Leider ist es immer noch so, dass nginx nach dem RPi reboot nicht automatisch startet :( Bzw. eigentlich startet nginx schon, nur funktioniert die config nicht. Erst nach einem manuellen reload. Wie kann man das ändern?

timtom

Lösung gefunden:

In der Config von nginx
proxy_pass http://localhost:8083; ändern in http://127.0.0.1:8083;

CoolTux

Dann solltest Du aber mal Deine /etc/hosts überprüfen.
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

timtom

Zitat von: CoolTux am 29 November 2018, 16:50:51
Dann solltest Du aber mal Deine /etc/hosts überprüfen.

Ich zitiere man die Begründung:

ZitatI cross posted this question at serverfault after 24 hours and I am going to include the resolution to my particular issue here for posterity..

In my configuration, the proxy_pass directive of the relevant nginx location block stated:

proxy_pass http://localhost:4040;
However, the upstream service was actually binding to the ipv4 address, and is also slower to start at bootup than nginx.

When nginx checked the status of the upstream server, its connection was refused. Thereafter when nginx attempted to re-check the status of the upstream server, it continued to check only on the IPV6 address [::1].

To resolve the issue I specified the ipv4 address (127.0.0.1) instead of localhost, thus forcing nginx to use ipv4 only. It all works as expected, now.