☰

Respuesta 404 inesperada de php-fpm cuando el archivo existe y es legible

tag-icon • tag-icon nginx php-fpm arch-linux
Respuesta 404 inesperada de php-fpm cuando el archivo existe y es legible

Estoy ejecutando un sitio simple basado en PHP usando nginx. Después de una actualización reciente de varios componentes del sistema, el sitio dejó de funcionar. Cuando intento acceder al sitio, aparece una página en blanco con el texto "Archivo no encontrado". Los registros del servidor me dicen que

FastCGI enviado en stderr: "Secuencia de comandos principal desconocida" mientras leía el encabezado de respuesta desde arriba

y el registro de PHP contiene

- - 25/Jan/2020:17:18:50 +0100 "GET /index.php" 404 - 0.151 2048 0.00%

La configuración de nginx es la siguiente.

# configuration file /etc/nginx/nginx.conf:

user http http;
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    types_hash_max_size 2048;
    types_hash_bucket_size 128;

    sendfile        on;

    keepalive_timeout  65;

    # some server blocks elided

    include /home/myuser/www/com.mydomain.conf;
}

# configuration file /etc/nginx/mime.types:
types {
application/A2L                    a2l;
# lots of types elided so as not to exceed post size limit
}

# configuration file /etc/nginx/fastcgi.conf:

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;
fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;


# configuration file /home/myuser/www/com.mydomain.conf:
server {
  listen 80;
  server_name mydomain.com;
  # enforce https
  return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name mydomain.com;

    client_max_body_size 16m;

    root /home/myuser/www/com.mydomain;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri $fastcgi_script_name =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_index index.php;
        fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
   }
}

nginx y php-fpm se ejecutan como usuario httpy index.phpese usuario puede acceder al archivo:

-rwxrwxr-x 1 http http 1,7K  8. Nov 10:40 /home/myuser/www/com.mydomain/index.php

Lo he comprobado $document_rooty $fastcgi_script_nameestoy en lo cierto al pasarlos como SCRIPT_NAMEpara prueba.

¿Qué estoy haciendo mal?

Editar:De hecho, esto parece un problema de permisos, pero todavía no lo entiendo. Si muevo el contenido del sitio para /usr/share/webapps/realizar una prueba, funciona. Desafortunadamente, esa no es una opción para uso en producción. Con los archivos en su ubicación prevista (original), puedo ejecutar cosas como sudo -u http php /home/myuser/www/com.mydomain/test.phpy obtener el resultado esperado. ¿Qué podría impedir que php-fpm (o el socket) acceda a esos archivos? open_basedirno está configurado.

Respuesta1

Aparte de todas las cosas que pueden salir mal en la interacción entre nginx y php-fpm (discutidas en varias preguntas en este sitio), systemd permite otro error, que resultó ser el culpable en este caso.

El archivo de la unidad php-fpm.service contenía la ProtectHome=truedirectiva. Pude remediar esto ejecutando systemctl edit php-fpm.servicey especificando

[Service]
ProtectHome=false

información relacionada