.png)
Ich habe also einen Nginx-Server, der über https mit Sinatra arbeitet. Wenn ich versuche, eine JNLP-Datei in einer Konfiguration herunterzuladen, die über Mongrel und http (kein s) einwandfrei funktioniert, schlägt der Nginx-Server beim Bereitstellen der Datei mit einem 504-Fehler fehl. Eine anschließende Überprüfung der Protokolle ergibt, dass dieser Fehler auf einen Überlauf der verfügbaren Anzahl von Dateihandles zurückzuführen ist, d. h. „24: zu viele offene Dateien“. Ausführen
sudo lsof -p <nginx worker pid>
erhalte ich eine riesige Liste mit Dateien, die alle so aussehen:
nginx 1771 nobody 11u IPv4 10867997 0t0 TCP localhost:44704->localhost:https (ESTABLISHED)
nginx 1771 nobody 12u IPv4 10868113 0t0 TCP localhost:https->localhost:44704 (ESTABLISHED)
nginx 1771 nobody 13u IPv4 10868114 0t0 TCP localhost:44705->localhost:https (ESTABLISHED)
nginx 1771 nobody 14u IPv4 10868191 0t0 TCP localhost:https->localhost:44705 (ESTABLISHED)
nginx 1771 nobody 15u IPv4 10868192 0t0 TCP localhost:44706->localhost:https (ESTABLISHED)
nginx 1771 nobody 16u IPv4 10868255 0t0 TCP localhost:https->localhost:44706 (ESTABLISHED)
nginx 1771 nobody 17u IPv4 10868256 0t0 TCP localhost:44707->localhost:https (ESTABLISHED)
nginx 1771 nobody 18u IPv4 10868330 0t0 TCP localhost:https->localhost:44707 (ESTABLISHED)
nginx 1771 nobody 19u IPv4 10868331 0t0 TCP localhost:44708->localhost:https (ESTABLISHED)
nginx 1771 nobody 20u IPv4 10868434 0t0 TCP localhost:https->localhost:44708 (ESTABLISHED)
Das Erhöhen der Anzahl der zu öffnenden Dateien ist keine Hilfe, da nginx diese Grenze dann einfach überschreitet. Und kein Wunder, es sieht so aus, als ob es sich in einer Art Schleife befindet, um alle verfügbaren Dateien abzurufen.
Irgendeine Idee, was los ist und wie man es beheben kann?
BEARBEITEN:nginx 0.7.63, Ubuntu Linux, Sinatra 1.0
BEARBEITEN 2:Hier ist der fehlerhafte Code. Es ist Sinatra, das JNLP bedient, was ich schließlich herausgefunden habe:
get '/uploader' do
#read in the launch.jnlp file
theJNLP = ""
File.open("/launch.jnlp", "r+") do |file|
while theTemp = file.gets
theJNLP = theJNLP + theTemp
end
end
content_type :jnlp
theJNLP
end
Wenn ich dies mit Sinatra über Mongrel und http bereitstelle, funktioniert alles einwandfrei. Wenn ich dies mit Sinatra und nginx über https bereitstelle, erhalte ich den obigen Fehler. Alle anderen Teile der Website scheinen gleichwertig zu sein.
BEARBEITEN:Ich habe seitdem auf Passenger 2.2.14, Ruby 1.9.1, Nginx 0.8.40, OpenSSL 1.0.0a aktualisiert und es hat sich nichts geändert.
BEARBEITEN:Der Übeltäter scheint die unendlichen Weiterleitungen aufgrund der Verwendung von SSL zu sein. Ich weiß nicht, wie ich das beheben kann, außer die JNLP-Datei im Stammverzeichnis des Servers zu hosten (was ich lieber nicht tun würde, da ich dann auf eine JNLP-basierte App gleichzeitig beschränkt bin).
Die relevanten Zeilen aus nginx.conf:
# HTTPS server
#
server {
listen 443;
server_name MyServer.org
root /My/Root/Dir;
passenger_enabled on;
expires 1d;
proxy_set_header X-FORWARDED_PROTO https;
proxy_set_header X_FORWARDED_PROTO https;#the almighty google is not clear on which to use
location /upload {
proxy_pass https://127.0.0.1:443;
}
}
Das Lustige daran ist, dass ich das JNLP zunächst in ein Verzeichnis namens „Uploader“ und nicht „Upload“ gelegt habe, aber das schien trotzdem das Problem auszulösen, da diese Proxy_pass-Direktive in den Protokollen erschien. Zweitens wurde das Problem wiederum vermieden, indem ich das JNLP ins Stammverzeichnis verschoben habe, da es aufgrund von SSL kein Proxying gab.
Wie kann ich also die unendliche Proxy_Pass-Schleife in Nginx vermeiden?
Antwort1
nginx lauscht auf Port 443. Wenn Sie eine Anfrage erhalten /uploader, leiten Sie einen Proxy an ... Port 443 weiter. Das ist nginx. Es sieht so aus, als ob Sie einen Proxy an Ihre Sinatra-App leiten sollten, die auf einem anderen Port lauscht? Ich kenne mich mit nginx nicht gut aus, aber das sieht nicht richtig aus.