2020/01/31 18:30:55 13617#13617: *557 connect() to unix:/run/php/php7.2-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.2-fpm.sock:", host: "localhost"

PHP-FPM körs inte

Obs: Det här avsnittet innehåller ett processnamn som använder termen ”master.”Förutom när man hänvisar till specifika processer använder den här artikeln termen ”primär” istället.

om PHP-FPM inte körs returnerar NGINX ett 502-fel för varje begäran som är avsedd att nå PHP-applikationen. Om du ser 502s, kontrollera först att PHP-FPM körs. På en Linux-värd kan du till exempel använda ett ps kommando som det här för att leta efter att köra PHP – FPM-processer:

sudo ps aux | grep 'php'

PHP-FPM organiserar sina arbetsprocesser i grupper kallas pooler. Provutmatningen nedan visar att PHP – FPM-primärprocessen körs, liksom två arbetsprocesser i standardpoolen (heter www):

root 29852 0.0 2.2 435484 22396 ? Ssl 16:27 0:00 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)www-data 29873 0.0 1.5 438112 15220 ? Sl 16:27 0:00 php-fpm: pool wwwwww-data 29874 0.0 1.6 438112 16976 ? Sl 16:27 0:00 php-fpm: pool www

om kommandotps inte visar några primära eller poolprocesser i PHP-FPM måste du köra PHP-FPM för att lösa 502-felen.

i en produktionsmiljö bör du överväga att använda systemd för att köra PHP-FPM som en tjänst. Detta kan göra din PHP-applikation mer tillförlitlig och skalbar, eftersom PHP-FPM-demonen automatiskt börjar betjäna din PHP-app när servern startar eller när en ny instans startas. PHP-FPM ingår i PHP-källkoden, så du kan lägga till PHP-FPM som en systemd-tjänst när du konfigurerar PHP.

När ditt PHP-FPM-projekt har konfigurerats som en tjänst kan du använda följande kommando för att säkerställa att det startar automatiskt när servern startar:

sudo systemctl enable php7.2-fpm.service

sudo systemctl is-active php7.2-fpm.service

detta kommando ska returnera en utgång på active. Om det inte gör det kan du starta tjänsten med:

sudo service php7.2-fpm start

NGINX kan inte komma åt uttaget

När PHP-FPM startar skapar det ett eller flera TCP-eller Unix-uttag för att kommunicera med Nginx webbserver. PHP-FPM: s arbetsprocesser använder dessa uttag för att lyssna på förfrågningar från NGINX.

för att avgöra om ett 502-fel orsakades av en socket-felkonfiguration, bekräfta att PHP-FPM och NGINX är konfigurerade att använda samma socket. PHP-FPM använder en separat konfigurationsfil för varje arbetsprocesspool; dessa filer finns på /etc/php/7.2/fpm/pool.g/. Varje pools uttag definieras i ettlisten – direktiv i poolens konfigurationsfil. Till exempel konfigurerarlisten direktivet nedan en pool med namnetmypool för att använda ett Unix-uttag på /run/php/mypool.socka:

listen = /run/php/mypool.sock

om NGINX inte kan komma åt uttaget för en viss pool, kan du avgöra vilken arbetarpool som är involverad i problemet genom att kontrollera vilket uttag som heter i nginx felloggposten. Till exempel, om PHP-FPM hade misslyckats med att starta mypool arbetarpool, skulle nginx returnera en 502 och dess felloggpost skulle innehålla:

connect() to unix:/run/php/mypool.sock failed (2: No such file or directory)

2020/02/20 17:12:03 3059#3059: *4 connect() to unix:/run/php/mypool.sock failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/mypool.sock:", host: "localhost"

Observera att standardvärdena för listen.ownerochlisten.groupmatchar standardägaren och grupp som kör nginx ochlisten.modeStandardvärdet är 0660. Med hjälp av dessa standardvärden bör NGINX kunna komma åt uttaget.

om PHP-FPM lyssnar på ett TCP-uttag kommer pool conifguration ’ slisten direktivet att ha ett värde i form avaddress:port, som visas nedan:

listen = 127.0.0.1:9000

precis som med ett Unix-uttag kan du förhindra 502 fel genom att bekräfta att platsen för detta uttag matchar den som anges i Nginx-konfigurationen.

PHP-FPM är timing ut

om din ansökan tar för lång tid att svara, kommer användarna att uppleva en timeout fel. Om PHP-FPM: s timeout—som är inställd i poolkonfigurationens request_terminate_timeout—direktiv (och standardvärdet är 20 sekunder) – är mindre än nginx timeout (som Standardvärdet är 60 sekunder), svarar NGINX med ett 502-fel. Nginx-felloggen som visas nedan indikerar att dess uppströmsprocess—som är PHP-FPM—stängde anslutningen innan du skickade ett giltigt svar. Med andra ord är detta felloggen vi ser när PHP-FPM Time out:

2020/02/20 17:17:12 3059#3059: *29 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/mypool.sock:", host: "localhost"

i detta fall är PHP-FPM-loggen (som som standard finns på /var/log/php7.2-fpm.log) visar ett korrelerat meddelande som ger ytterligare information:

 WARNING: child 2120, script '/var/www/html/index.php' (request: "GET /index.php") execution timed out (25.755070 sec), terminating

Du kan höja PHP-FPM: s timeout-inställning genom att redigera poolens konfigurationsfil, men det kan orsaka ett annat problem: NGINX kan timeout innan du får ett svar från PHP-FPM. Standard timeout för NGINX är 60 sekunder; om du har höjt din PHP-FPM timeout över 60 sekunder returnerar NGINX ett 504 Gateway Timeout-fel om din PHP-applikation inte har svarat i tid. Du kan förhindra detta genom att också höja din nginx timeout. I exemplet nedan har vi höjt timeout-värdet till 90 sekunder genom att lägga till fastcgi_read_timeout – objektet till http block av /etc/nginx/nginx.conf:

http { ... fastcgi_buffers 8 16k; fastcgi_buffer_size 32k; fastcgi_connect_timeout 90; fastcgi_send_timeout 90; fastcgi_read_timeout 90;}

ladda om din nginx-konfiguration för att tillämpa denna ändring:

nginx -s reload

därefter kan du samla loggar och APM-data (application performance monitoring) som kan avslöja orsaker till latens inom och utanför din ansökan.

samla in och analysera dina loggar

för att felsöka programfel kan du samla in dina loggar och skicka dem till en logghanteringstjänst. Förutom nginx-loggarna som vi undersökte ovan kan PHP logga fel och andra händelser som kan vara värdefulla för dig. Se vår PHP loggning guide för mer information.

När du tar med dina PHP-och NGINX-loggar till en logghanteringstjänst, kombinerat med loggar från relevant teknik som cachningsservrar och databaser, kan du analysera loggar från hela din webbstack på en enda plattform.

samla APM-data från din webbstack

APM kan hjälpa dig att identifiera flaskhalsar och lösa problem, som 502 fel, som påverkar appens prestanda. Skärmdumpen nedan visar nginx APM-data visualiserad i Datadog. Den här vyn sammanfattar begärningsvolym, felfrekvenser och latens för en nginx-baserad tjänst och hjälper dig att undersöka prestandaproblem som 502 fel.

200 OK

ju snabbare du kan diagnostisera och lösa programmets 502 fel, desto bättre. Datadog låter dig analysera mätvärden, spår, loggar och nätverksprestandadata från hela din Infrastruktur. Om du redan är Datadog-kund kan du börja övervaka NGINX, PHP-FPM och mer än 400 andra tekniker. Om du ännu inte har ett Datadog-konto kan du registrera dig för en 14-dagars gratis provperiod och komma igång på några minuter.