404 on Nginx.

[benjaminisawolfe]

I'm running HHVM 3.4.0-dev+2014.09.05 with Nginx 1.4.6 on Ubunti 14.04.I have 5 virtual hosts running on HHVM. The fifth host, whose configuration file is virtually identical to the others, is producing 404s. When I swap out HHVM for PHP, the 404s go away, which leads me to conclude it's an HHVM issue.

Here's my config file, with some identifying features removed:

server {
        server_name development.mysite.com www.development.mysite.com;
        listen 2xx.1xx.5xx.1xx:80;
        rewrite ^ https://$host$request_uri? permanent;

        fastcgi_read_timeout 60;
}

server {
        server_name development.iforetold.com www.development.iforetold.com;
        listen 2xx.1xx.5xx.1xx:443;
        server_name_in_redirect off;
        ssl on;
        ssl_certificate /home/mysite.com/ssl.cert;
        ssl_certificate_key /home/mysite.com/ssl.key;
        root /home/imysite.com/public_html;
        index index.html index.htm index.php;
        access_log /var/log/virtualmin/development.mysite.com_access_log;
        error_log /var/log/virtualmin/development.mysite.com_error_log debug_http;
        fastcgi_param GATEWAY_INTERFACE CGI/1.1;
        fastcgi_param SERVER_SOFTWARE nginx;
        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_FILENAME /home/mysite.com/public_html$fastcgi_script_name;
        fastcgi_param SCRIPT_NAME $fastcgi_script_name;
        fastcgi_param REQUEST_URI $request_uri;
        fastcgi_param DOCUMENT_URI $document_uri;
        fastcgi_param DOCUMENT_ROOT /home/mysite.com/public_html;
        fastcgi_param SERVER_PROTOCOL $server_protocol;
        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;
        fastcgi_param HTTPS $https;

        # unless the request is for a valid file, send to bootstrap
        if (!-e $request_filename) {
                rewrite ^(.+)$ /index.php?q=$1 last;
        }

        # catch all
        error_page 404 /index.php;

        # use fastcgi for all php files
        location ~ \.php$ {
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                include fastcgi_params;
        }

        # deny access to apache .htaccess files
        location ~ /\.ht {
                deny all;
        }

}

My HHVM debug log reports receiving index.php and nothing else. My init.d file is standard, except for changing a few directories and the user running HHVM. My server.ini file follows:

; php options

pid = /home/hhvm/run/pid
date.timezone = America/Denver
display_errors = On
display_startup_errors = On
upload_max_filesize = 52428800
default_socket_timeout = 600
max_execution_time = 600
max_input_time = 600
memory_limit = 1000M
post_max_size = 52428800

; hhvm specific

hhvm.server.port = 9000
hhvm.server.type = fastcgi
hhvm.server.default_document = index.php
hhvm.log.level = Verbose
hhvm.log.always_log_unhandled_exceptions = true
hhvm.log.runtime_error_reporting_level = 8191
hhvm.log.use_log_file = true
hhvm.log.file = /home/hhvm/logs/error.log
hhvm.repo.central.path = /home/hhvm/hhvm.sq3
hhvm.mysql.typed_results = false
hhvm.log.header = true
hhvm.server.fix_path_info = true

I'll stress that the weird thing about this is that all the other sites work fine. No problems at all.

Help!

[paulbiss]

This is probably related to #3285

[paulbiss]

Closing as a dup of #3285, pretty sure they're the same issue.

[r3wt]

@paulbiss before i waste your time with another identical issue, is this nginx issue the one that results in these entries in the hhvm error log:

FastCGI protocol: received an invalid record

I get these errors on occasion, usually when there's an error in a route closure. i use slim framework

[paulbiss]

@r3wt I believe that's a separate issue, but we've had a number of those opened in the past, unless you have more details it's probably not going to be easy to figure out what's causing it unfortunately.