passenger_root with nginx

Hi folks. I am installing nginx with passenger module, then installed rubygem-passenger.

Upon trying to start nginx, I get the following:

Code:
[Tue Jul 04 11:32:09 rich@neb ~] service nginx start
Performing sanity check on nginx configuration:
nginx: [emerg] unknown directive "passenger_root" in /usr/local/etc/nginx/nginx.conf:15

Passenger is installed by itself and located in the $PATH:

Code:
[Tue Jul 04 11:34:19 rich@neb ~] sudo passenger-config validate-install
<snip>
 * Checking whether this Passenger install is in PATH... ✓
 * Checking whether there are no other Passenger installations... ✓

Everything looks good. :-)

I have no reference as to how to cough up the passenger_root directive for nginx, at least on FreeBSD. On MacOS it is brew info nginx --with-passenger but that's useless here.

Given nginx was config'd with passenger module, why would it not expect this directive?

Any insight appreciated. Cheers.
 
I remember something similar with some other nginx module. You need to explicitly load the module in the nginx configuration.

Look for the module in /usr/local/libexec/nginx/ and add it:
Code:
load_module /usr/local/libexec/nginx/ngx_http_fancyindex_module.so;
(example loads the "fancyindex" module)
 
I remember something similar with some other nginx module. You need to explicitly load the module in the nginx configuration.

So will this be an issue with the other modules I've chosen? A general module loading issue?

BTW thanks.
 
Update:
Code:
nginx: [emerg] open() "/usr/local/var/run/nginx.pid" failed (2: No such file or directory)

&&...

Code:
[Tue Jul 04 09:33:25 rich@neb ~] service nginx start
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: [emerg] open() "/usr/local/var/run/nginx.pid" failed (2: No such file or directory)
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
Starting nginx.
limits: setrlimit datasize: Operation not permitted
/usr/local/etc/rc.d/nginx: WARNING: failed to start nginx

It's starting to look like this unmaintained port (according to installation feedback) is quite behind. I'm installing on 11.0-RELEASE-p1. Now, I'm not highly versed in this stuff, but I'm thinking that manually creating the proper directory run/ and nginx.pid (using touch nginx.pid) is a bit unorthodox and somewhat unacceptable. Not to mention I'm assuming nginx.pid is just a normal file.

Rather surprised something like nginx in the forefront of any OS, is a bit unkempt. Any suggestions how I should proceed without bunging things up? I tried installing www/nginx-full but that gave me error 1 and in the end, I should be able to install nginx with my chosen config.

Cheers
 
Code:
nginx: [emerg] open() "/usr/local/var/run/nginx.pid" failed (2: No such file or directory)
This isn't the correct directory. Did you set this yourself?

Code:
# ll /var/run/nginx.pid
-rw-r--r--  1 root  wheel  5 Jul  1 18:49 /var/run/nginx.pid

It's defined in /usr/local/etc/rc.d/nginx:
Code:
_pidprefix="/var/run"
pidfile="${_pidprefix}/${name}.pid"
 
Ah yes, I did. (sorry, was tired). I forgot I have a pointer to the pid in the conf file.

So set to /var/run/nginx.pid, I get a permissions error:
Code:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: [emerg] open() "/var/run/nginx.pid" failed (13: Permission denied)
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
 
Remove the pidfile setting from nginx.conf. It's already being set by the rc(8) script.
 
Still the same permissions issue. Should I un-comment this:?

# user root admin;
 
No, nginx should run on the www account, which it does by default. For security reasons you should never run it on the root account.

You shouldn't really need to edit anything, the default nginx.conf should work. Once you get the standard "Welcome to nginx" working you can start changing the server settings to load your own site.
 
OK that was my next process. Tried with [c,d]user nobody;[/cmd] and #user nobody; and both are still giving me permissions errors on the /var/run/nginx.pid

Code:
#user  nobody;
worker_processes  1;

# This default error log path is compiled-in to make sure configuration parsing
# errors are logged somewhere, especially during unattended boot when stderr
# isn't normally logged anywhere. This path will be touched on every nginx
# start regardless of error log location configured here. See
# https://trac.nginx.org/nginx/ticket/147 for more info.
#
#error_log  /var/log/nginx/error.log;
#

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


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

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   /usr/local/www/nginx;
            index  index.html index.htm;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}

}
 
OK, here's an update:

Installed 11.1-RC1 and got nginx up and running as default. Wrote over the nginx.conf and I got error.log permissions errors, fixed with chmod. Then permissions errors on nginx.pid yet again. So I just replaced [/file]nginx.conf[/file] with the backup of the original [/file]nginx.conf[/file] that worked. I am still getting permissions issues on the nginx.pid file.

So essentially nothing has changed from the default installation which worked, and I'm getting permissions issues on a process ID. I have no further ideas on this one. Any advice appreciated.

It's serving, and I did sudo chmod 755 nginx.pid and the error went away. Why the permissions would sour on the change of the nginx.conf, is strange.

Cheers
 
-rwxrwxr-x 1 root wheel 4 Jul 7 10:55 nginx.pid
-rwxrwxr-x 1 root wheel 24855 Jul 10 21:17 error.log
 
Why are your PID and log files marked as executable? Only directories and executables should have the 'x' permissions. Permissions on regular files like this should be 644 or 640.

Code:
root@j-ports:~ # ll /var/log/nginx/*
-rw-r--r--  1 root  wheel  56096 Jul 11 15:29 /var/log/nginx/access.log
-rw-r--r--  1 root  wheel   7340 Jul 11 09:18 /var/log/nginx/error.log
root@j-ports:~ # ll /var/run/nginx.pid
-rw-r--r--  1 root  wheel  6 Jul  9 16:23 /var/run/nginx.pid

Did you change any of the permissions or ownership of /var/, /var/run/ and/or /var/log/?
 
Because above, you said the following: Remove the pidfile setting from nginx.conf. It's already being set by the [URL='https://www.freebsd.org/cgi/man.cgi?query=rc&sektion=8&manpath=freebsd-release-ports']rc(8)[/URL] script.

Edit: Sorry, I read that wrong. Thought you asked why it was commented out. Answer: I was having permissions issues on everything. I got past it by using 655.

Just tried 644 on /var/log/nginx/err.log and it failed, permission denied. I am changing permissions all the time because nothing is permitted unless I use 655 or better.
 
655 permissions make no sense at all, that would be read-write for the owner and read-execute for group and everyone else.
 
655 permissions make no sense at all, that would be read-write for the owner and read-execute for group and everyone else.

I'm not arguing with you. It's the only thing that works. On 11.1-RC1 and 11.0-RELEASE. nginx reports permissions issues if it isn't. I'm taking this to the nginx list.
 
I simply don't understand why you need to change the permissions at all. I've never had that problem in all the years I've used nginx.
 
On both versions of FreeBSD, this has happened. Both clean installations. This is why I'm asking, because it's driving me up the wall.
 
I am but I usually run that on Apache, not nginx (I maintain a bunch of servers running Apache22 + Passenger for a client).
 
Well, upon further investigation, such as my OSX workstation, such warnings in the nginx -t results, are normal. My Passenger version was not up to date (it updated in my update script), so I corrected that and now Passenger is accepting routing. Now I have an rbenv issue which is the next mountain.

nginx should clean up its act. nginx.pid permissions should not be an issue, as stated above. SirDice is completely correct in that a simple file with only a processID should not be a challenge, and should not be reported as such. Permissions of 644 should give up the ID just fine. sudo nginx -t rids the permissions error.
 
Three installations on fresh operation systems, same reports on nginx -t, with other reports in different operating systems over time? You guys are not a significant sample space. If the nginx.pid was not readable due to permissions issues, then how is it serving?
 
Back
Top