NGINX verweigert Neustart – [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use)

In diesem Artikel möchte ich einige Informationen zur NGINX-Fehlermeldung „[emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use)“ wiedergeben.

Als ich heute Morgen die E-Mail-Reports meiner Server durchgesehen habe, fiel mir die Meldung ins Auge, dass auf einem meiner Server die NGINX-Konfiguration nicht erneut eingelesen werden konnte. Auch der Versuch eines manuellen Neustarts wurde mit folgender Meldung quittiert:

# sudo service nginx restart
* Restarting nginx nginx [fail]

Konfiguration überprüfen

Die obige Meldung gibt noch keinerlei Hinweise auf die Ursache des Fehlers. Mit dem folgenden Kommando lässt sich die Konfiguration des NGINX überprüfen und der Fehler etwas eingrenzen:

# sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] listen() to 0.0.0.0:80, backlog 511 failed (98: Address already in use)
nginx: configuration file /etc/nginx/nginx.conf test failed

Die Fehlermeldung sagt aus, dass der NGINX-Prozess nicht erneut an den Port 80 gebunden werden kann, da dieser bereits verwendet wird. Für mich noch immer etwas verwirrend, da NGINX ja noch läuft und selbstverständlich auf Port 80 lauscht. Weshalb dadurch plötzlich kein Neustart mehr möglich ist, erschließt sich mir noch nicht.

Eine Lösung

Bei der Internetrecherche nach einer Lösung, bin ich auf einen englischsprachigen Troubleshootingguide gestoßen, welcher empfiehlt, alle Prozesse, die auf Port 80 lauschen, mit dem folgenden Kommando zu beenden:

sudo fuser -k 80/tcp

Anschließend konnte ich den NGINX wie gewohnt neu starten (restart) oder die Konfiguration neu einlesen (reload). Das Problem scheint damit erstmal behoben zu sein.

3 Gedanken zu „NGINX verweigert Neustart – [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use)

  1. onli

    Nginx kann sich eigentlich nicht selbst blockieren. Denn du hast recht, er wird ja neu gestartet, was beim abschalten den Port freigeben sollte. Funktionierte zu dem Zeitpunkt nginx denn noch?

    Vor allem wenn nicht: Du solltest nächstes mal schauen, welcher Prozess genau den Port blockiert. Vielleicht war es nur ein nginx-Zombie, aber es könnte ja auch Malware sein. Ein Befehl dafür ist `sudo lsof -i tcp:80`.

    Antworten
    1. Jörg Kastning Beitragsautor

      Hallo onli,
      zum Zeitpunkt der Fehlermeldung hat der NGINX die gehostete Webanwendung weiterhin korrekt ausgeliefert.

      Den von dir genannten Befehl hatte ich auch ausgeführt und folgende Ausgabe erhalten:

      $ sudo lsof -i tcp:80
      COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
      nginx 27659 root 6u IPv4 752594145 0t0 TCP *:http (LISTEN)
      nginx 27659 root 7u IPv6 752594146 0t0 TCP *:http (LISTEN)
      nginx 27768 www-data 6u IPv4 752594145 0t0 TCP *:http (LISTEN)
      nginx 27768 www-data 7u IPv6 752594146 0t0 TCP *:http (LISTEN)
      nginx 27769 www-data 6u IPv4 752594145 0t0 TCP *:http (LISTEN)
      nginx 27769 www-data 7u IPv6 752594146 0t0 TCP *:http (LISTEN)

      Für mich sieht das so aus, als wenn ausschließlich NGINX-Prozesse den Port gebunden haben.

      Der Fehler lässt sich bisher auch nicht reproduzieren.

      Viele Grüße
      Jörg

      Antworten
  2. Marius

    Es passiert regelmäßig, daß sich Dienstprozesse nicht mehr beenden lassen. In dem Fall kann sich auch ein Apache oder NGINX nicht mehr selbst neustarten, weil der Prozess, der auf dem Port gebunden ist, nicht mehr auf ein Signal ala SIG_TERM reagiert. Beim Neustart machen die DIenste auch nichts anderes, als ein SIG_HUB an Ihren Prozess zu schicken.

    In dem Fall, nicht lange suchen : killall -9 und dann neustarten

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.