Two little bugs

Server NGINX
1

I find two little bugs. Don’t know whether others mentioned or not.

  1. if the argument of nginx -c is a relative path, it wil trigger a
    segment fault. Meant to be implemented like that? Because since 0.5.x to
    current release contain this bug.

  2. In nginx 0.9.x, the man is also “nginx 8”. Meant to upgrade in some
    following revision?

Posted at Nginx Forum:

2

Hi,

On Tue, Dec 07, 2010 at 01:45:53AM -0500, speedfirst wrote:

I find two little bugs. Don’t know whether others mentioned or not.

  1. In nginx 0.9.x, the man is also “nginx 8”. Meant to upgrade in some
    following revision?

this is not the bug and ``8’’ is not version number.

See man page - Wikipedia
as well as man page - Wikipedia for details.

–
Sergey A. Osokin
[email protected]
[email protected]

3

On Tue, Dec 07, 2010 at 01:45:53AM -0500, speedfirst wrote:

I find two little bugs. Don’t know whether others mentioned or not.

  1. if the argument of nginx -c is a relative path, it wil trigger a
    segment fault. Meant to be implemented like that? Because since 0.5.x to
    current release contain this bug.

Could you show a test case ?
I can not reproduce the issue.

–
Igor S.
http://sysoev.ru/en/

4

On Wed, Dec 8, 2010 at 7:36 AM, speedfirst [email protected] wrote:

nginx/sbin/nginx -c nginx.conf
[/code]

will get segment fault

I can’t reproduce this either. Please provide output of nginx/sbin/nginx
-V

–
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

5

For example,

nginx/sbin/nginx -c /opt/nginx/nginx.conf

is OK, because /opt/nginx/nginx.conf is an absolute path

However,

nginx/sbin/nginx -c nginx.conf

will get segment fault

I debug the source code, the problem is located in the function
“ngx_conf_full_name”. Seems the cycle used in that function is not yet
initialized when trying to get the full path.

Posted at Nginx Forum:

6

On Tue, 7 Dec 2010 10:38:26 +0300, Igor S. [email protected] wrote:

  1. if the argument of nginx -c is a relative path, it wil trigger a
    segment fault. Meant to be implemented like that? Because since
    0.5.x to current release contain this bug.

Could you show a test case ?
I can not reproduce the issue.

While using Ubuntu 10.10+Nginx 0.8.53

  1. using full path works:
    sudo nginx -c /etc/nginx/nginx.conf

  2. using relative path fails:
    sudo nginx -c nginx.conf
    with error:
    [emerg]: open() “/usr/local/nginx/nginx.conf” failed (2: No such file
    or directory)

As seen bellow, my --conf-path=/etc/nginx/nginx.conf.
Why is nginx trying to open it at /usr/local/nginx/nginx.conf?
Is it hard wired at some other place in the code?

Regards,

M.

$ nginx -V
nginx version: nginx0.8.53
TLS SNI support enabled
configure arguments: --conf-path=/etc/nginx/nginx.conf
–error-log-path=/var/log/nginx/error.log
–http-client-body-temp-path=/var/lib/nginx/body
–http-fastcgi-temp-path=/var/lib/nginx/fastcgi
–http-log-path=/var/log/nginx/access.log
–http-proxy-temp-path=/var/lib/nginx/proxy
–lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid
–with-http_ssl_module --without-http_limit_req_module
–without-mail_pop3_module --without-mail_smtp_module
–without-mail_imap_module --without-http_uwsgi_module
–without-http_scgi_module --without-http-cache

7

Hi,

  1. using relative path fails:
    sudo nginx -c nginx.conf
    with error:
    [emerg]: open() “/usr/local/nginx/nginx.conf” failed (2: No such file
    or directory)

It’s supposed to fail.

As seen bellow, my --conf-path=/etc/nginx/nginx.conf.
Why is nginx trying to open it at /usr/local/nginx/nginx.conf?
Is it hard wired at some other place in the code?

Because you’re passing only filename.

Skip -c option if you want to use path from build-time conf-path.

Best regards,
Piotr S. < [email protected] >

8

On Wed, 8 Dec 2010 17:04:40 +0100, “Piotr S.”
[email protected] wrote:

  1. using relative path fails:
    sudo nginx -c nginx.conf
    with error:
    [emerg]: open() “/usr/local/nginx/nginx.conf” failed (2: No such
    file or directory)

It’s supposed to fail.

How come?

I we have defined --conf-path=/etc/nginx/nginx.conf and that file
exists at that place;
I would expect that in case of any trouble at opening the
config file stated in the command line,
be it ‘nginx -c nginx.conf’ or ‘nginx
-c /whatever/path/anyfile-nginx.conf’,
nginx would try an [emerg]: open() “/etc/nginx/nginx.conf”,
not, as it is doing now, an [emerg]: open()
“/usr/local/nginx/nginx.conf”

As seen bellow, my --conf-path=/etc/nginx/nginx.conf.
Why is nginx trying to open it at /usr/local/nginx/nginx.conf?
Is it hard wired at some other place in the code?

Because you’re passing only filename.

It shouldn’t matter.
For the sake of portability in whatever filesystem it happens to be,
if in trouble, nginx should look for the config file stated at
–conf-path= not at some pre-wired location, be it /usr/local/nginx/ or
whatever.

Best regards,

M.

9

Hello!

On Wed, Dec 08, 2010 at 05:29:07PM +0000, Mark A. wrote:

How come?

I we have defined --conf-path=/etc/nginx/nginx.conf and that file
exists at that place;
I would expect that in case of any trouble at opening the
config file stated in the command line,
be it ‘nginx -c nginx.conf’ or ‘nginx
-c /whatever/path/anyfile-nginx.conf’,
nginx would try an [emerg]: open() “/etc/nginx/nginx.conf”,
not, as it is doing now, an [emerg]: open()
“/usr/local/nginx/nginx.conf”

Relative path in -c is resolved from --prefix, that’s why you see
“/usr/local/nginx/” + “nginx.conf”.

Note that I don’t argue if it breaks POLA or not, it’s just how it
currently works. I personally think that paths in command line
arguments should be resolved from pwd.

Maxim D.

10

Hi,

It shouldn’t matter.

Yes, is should.

For the sake of portability in whatever filesystem it happens to be,
if in trouble, nginx should look for the config file stated at
–conf-path= not at some pre-wired location, be it /usr/local/nginx/ or
whatever.

No, for 2 reasons:

  1. “–conf-path” is path to a file, not a directory. It points to the
    default configuration and if you skip -c option then nginx is using
    this
    file.
  2. When you specify relative filename (nginx -c nginx.conf) then nginx
    is
    looking in directory specified during build in “–prefix”. For example,
    with
    “–prefix=/etc/nginx” (like it’s set in OpenBSD and FreeBSD ports),
    nginx -c
    nginx.conf is opening file from /etc/nginx/nginx.conf location.

Don’t blame nginx for your misuses.

Best regards,
Piotr S. < [email protected] >

11

On Wed, 8 Dec 2010 20:42:35 +0300, Maxim D. [email protected]
wrote:

Relative path in -c is resolved from --prefix, that’s why you see
“/usr/local/nginx/” + “nginx.conf”.
Note that I don’t argue if it breaks POLA or not, it’s just how it
currently works.
I personally think that paths in command line
arguments should be resolved from pwd.

So do I.

Thank you Maxim.

M.

12

On Wed, Dec 08, 2010 at 08:42:35PM +0300, Maxim D. wrote:

file or directory)
-c /whatever/path/anyfile-nginx.conf’,
nginx would try an [emerg]: open() “/etc/nginx/nginx.conf”,
not, as it is doing now, an [emerg]: open()
“/usr/local/nginx/nginx.conf”

Relative path in -c is resolved from --prefix, that’s why you see
“/usr/local/nginx/” + “nginx.conf”.

Note that I don’t argue if it breaks POLA or not, it’s just how it
currently works. I personally think that paths in command line
arguments should be resolved from pwd.

If nginx has been built with empty prefix, i.e, --prefix= then it uses
pwd.

–
Igor S.
http://sysoev.ru/en/

13

Hello!

On Wed, Dec 08, 2010 at 11:42:48PM +0300, Igor S. wrote:

with error:
config file stated in the command line,
currently works. I personally think that paths in command line
arguments should be resolved from pwd.

If nginx has been built with empty prefix, i.e, --prefix= then it uses pwd.

Yes. But I think command line arguments should use pwd regardless
of prefix.

While resolving paths in config from prefix/conf_prefix is
somewhat convenient (though conf_prefix semantics is questionable,
too, it probably should always use dirname of current config
instead) - using the same logic for command line arguments breaks
POLA. People expect both

$ vi test-configs/nginx.conf

and

$ nginx -t -c test-configs/nginx.conf

to work with the same file.

Maxim D.

14

edogawaconan Wrote:

On Wed, Dec 8, 2010 at 7:36 AM, speedfirst wrote:

nginx/sbin/nginx -c nginx.conf

will get segment fault

I can’t reproduce this either. Please provide
output of nginx/sbin/nginx -V

Hey, I’m working on nginx dev for Zimbra. Here are my “-V” output.

speedfirst@u10:/opt/zimbra$ nginx/sbin/nginx -c conf/nginx.conf -V
nginx version: nginx/0.8.48
built by gcc 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
TLS SNI support enabled
configure arguments: --prefix=/opt/zimbra/nginx-0.8-zimbra
--with-cc-opt='-g -I/opt/zimbra/cyrus-sasl-2.1.23.3z/include
-I/opt/zimbra/openssl-1.0.0a/include -I/opt/zimbra/include'
--with-ld-opt='-L/opt/zimbra/cyrus-sasl-2.1.23.3z/lib
-L/opt/zimbra/openssl-1.0.0a/lib -L/opt/zimbra/lib' --with-debug
--with-http_ssl_module --with-http_stub_status_module --with-pcre
--with-http_upstream_zmauth_module --with-mail --with-mail-sasl
--with-mail_ssl_module --error-log-path=/opt/zimbra/log/nginx.log
--http-log-path=/opt/zimbra/log/nginx.access.log
--http-client-body-temp-path=/opt/zimbra/data/tmp/nginx/client
--http-proxy-temp-path=/opt/zimbra/data/tmp/nginx/proxy
--http-fastcgi-temp-path=/opt/zimbra/data/tmp/nginx/fastcgi

And I try to use /opt/zimbra/conf/nginx.conf with the relative path.
According to above comments, nginx uses “–prefix” so it should try to
find /opt/zimbra/nginx-0.8.48/conf/nginx.conf. If not found, should
report an [emerg] error, rather than segment fault. Did I make something
wrong in build? Could I send the source I have to you to check?

speedfirst@u10:/opt/zimbra$ sudo nginx/sbin/nginx -c conf/nginx.conf
[sudo] password for speedfirst:
Segmentation fault

Posted at Nginx Forum: