Nginx-0.7.53

Changes with nginx 0.7.53 27 Apr
2009

*) Change: now a log set by --error-log-path is created from the 

very
start-up.

*) Feature: now the start up errors and warnings are outputted to an
   error_log and stderr.

*) Feature: the empty --prefix= configure parameter forces nginx to 

use
a directory where it was run as prefix.

*) Feature: the -p switch.

*) Feature: the -s switch on Unix platforms.

*) Feature: the -? and -h switches.
   Thanks to Jerome Loyet.

*) Feature: now switches may be set in condensed form.

*) Bugfix: nginx/Windows did not work if configuration file was 

given
by the -c switch.

*) Bugfix: temporary files might be not removed if the 

“proxy_store”,
“fastcgi_store”, “proxy_cache”, or “fastcgi_cache” were used.
Thanks to Maxim D…

*) Bugfix: an incorrect value was passed to mail proxy 

authentication
server in “Auth-Method” header line; the bug had appeared
in 0.7.34.
Thanks to Simon Lecaille.

*) Bugfix: system error text descriptions were not logged on Linux;
   the bug had appeared in 0.7.45.

*) Bugfix: the "fastcgi_cache_min_uses" directive did not work.
   Thanks to Andrew Vorobyoff.

What are the -p and -s switches for ?

-J

Igor S. wrote:

*) Feature: the -p switch.

*) Feature: the -s switch on Unix platforms.

*) Feature: the -? and -h switches.
   Thanks to Jerome Loyet.

Hello!

On Tue, Apr 28, 2009 at 03:18:27AM +0200, Joe Bofh wrote:

What are the -p and -s switches for ?

The -h switch should give you a clue:

$ nginx -h
nginx version: nginx/0.7.53
Usage: nginx [-?hvVt] [-s signal] [-c filename] [-g directives]

Options:
-?,-h : this help
-v : show version and exit
-V : show version and configure options then exit
-t : test configuration and exit
-s signal : send signal to a master process: stop, quit, reopen,
reload
-p prefix : set prefix path (default: /usr/local/nginx/)
-c filename : set configuration file (default: conf/nginx.conf)

Maxim D.

On Mon, Apr 27, 2009 at 06:49:17PM -0700, Michael S. wrote:

On Mon, Apr 27, 2009 at 6:32 PM, Maxim D. [email protected] wrote:

š-s signal š š : send signal to a master process: stop, quit, reopen, reload

so -s will find the master process somehow? does it use the pid file
defined in nginx.conf, or the default pid file location built in to
the binary? or some other magic?

-s uses pid file defined in nginx.conf, if it’s not defined, then
built-in.

So you may use
./nginx -s reload -c /path/to/nginx.conf
or
./nginx -s reload -p /path/to/nginx

On Mon, Apr 27, 2009 at 6:32 PM, Maxim D. [email protected]
wrote:

 -s signal   : send signal to a master process: stop, quit, reopen, reload

so -s will find the master process somehow? does it use the pid file
defined in nginx.conf, or the default pid file location built in to
the binary? or some other magic?

what is the difference between “stop” and “quit”

i assume “reopen” is to reopen logfiles, and “reload” is graceful
reloading

you should add in a restart as well (forceful restart)

2009/4/27 Igor S. [email protected]:

-s uses pid file defined in nginx.conf, if it’s not defined, then built-in.

hat is th

2009/4/27 Igor S. [email protected]:

I will think, I believe that restart is not good idea at all.

Are there not special cases where it makes sense?

It would essentially be a -TERM and then a start (maybe after a brief
pause to clear any sockets/whatever is still open)

Igor S. wrote:

Changes with nginx 0.7.53 27 Apr
2009

*) Change: now a log set by --error-log-path is created from the 

very
start-up.

could you add this feature: run nginx as a windows service?

On Mon, Apr 27, 2009 at 09:56:40PM -0700, Michael S. wrote:

what is the difference between “stop” and “quit”

“stop” sends -TERM and nginx exits immediately.
“quit” sends -QUIT and nginx exits gracefully. Probably, it should
be called “shutdown”.

i assume “reopen” is to reopen logfiles, and “reload” is graceful reloading

you should add in a restart as well (forceful restart)

I will think, I believe that restart is not good idea at all.

i’ve always had to killall -9 nginx ; /etc/init.d/nginx start after a
recompile.

i did not have to stop nginx before make install though

Is there now a preferred way to install a new binary and restart nginx
given the new options available?

I just tried installing 0.7.53 and it appears the nginx init script does
not like restarting after a new binary has been installed.

So as of now, I have to do this

/etc/init.d/nginx stop
make install
/etc/init.d/nginx start

I’m open to hearing suggestions for minimizing downtime while upgrading.

Hello!

On Tue, Apr 28, 2009 at 09:31:46AM +0200, Joe Bofh wrote:

/etc/init.d/nginx stop
make install
/etc/init.d/nginx start

I’m open to hearing suggestions for minimizing downtime while upgrading.

If you want to minimize downtime - you should follow binary
upgrade procedure as described here:

This gives you zero downtime (i.e. no single client request
missed).

Maxim D.

On Tue, Apr 28, 2009 at 09:31:46AM +0200, Joe Bofh wrote:

/etc/init.d/nginx start

I’m open to hearing suggestions for minimizing downtime while upgrading.

make install
make upgrade

Look inside Makefile for details.

On Tue, Apr 28, 2009 at 08:40:13AM +0200, Chris Wan wrote:

Igor S. wrote:

Changes with nginx 0.7.53 27 Apr
2009

*) Change: now a log set by --error-log-path is created from the 

very
start-up.

could you add this feature: run nginx as a windows service?

nginx will run as windows service in near future.

Igor S. wrote:

On Tue, Apr 28, 2009 at 08:40:13AM +0200, Chris Wan wrote:

Igor S. wrote:

Changes with nginx 0.7.53 27 Apr
2009

*) Change: now a log set by --error-log-path is created from the 

very
start-up.

could you add this feature: run nginx as a windows service?

nginx will run as windows service in near future.

oh, I expect it .

I use instsrv.exe srvany.exe now and nginx can run as windows servece.
but, this command: nginx -s reload don’t work, I shutdown and start it
only.

On Tue, Apr 28, 2009 at 1:23 AM, Maxim D. [email protected]
wrote:

If you want to minimize downtime - you should follow binary
upgrade procedure as described here:

CommandLine | NGINX

This gives you zero downtime (i.e. no single client request
missed).

interesting.

so find the master pid

kill -USR2 $pid
kill -WINCH $pid

Is all that is needed?

2009/4/28 Igor S. [email protected]:

missed).
kill -WINCH $pid

decide keep the new binary or not, then

kill -QUIT $pid.oldbin

to keep, or

kill -TERM $pid

to rollback.

the wiki is out of date then. it says USR2 then WINCH. not WINCH then
QUIT.

So there is no USR2 required? I will update the wiki with these
instructions (is there a version this started in?)

On Tue, Apr 28, 2009 at 08:16:01AM -0700, Michael S. wrote:

interesting.

so find the master pid

kill -USR2 $pid
kill -WINCH $pid

Is all that is needed?

kill -WINCH $pid

decide keep the new binary or not, then

kill -QUIT $pid.oldbin

to keep, or

kill -TERM $pid

to rollback.

On Tue, Apr 28, 2009 at 08:32:16AM -0700, Michael S. wrote:

This gives you zero downtime (i.e. no single client request

to rollback.

the wiki is out of date then. it says USR2 then WINCH. not WINCH then QUIT.

So there is no USR2 required? I will update the wiki with these
instructions (is there a version this started in?)

No, USR2 is required. WINCH is not necessary step.
You may use USR2, sleep 1, -f pid.oldbin, QUIT.
Look inside Makefile

Le 28 avril 2009 23:09, Jérôme Loyet [email protected] a écrit :

Hi Igor,

since 0.7.48 and the fact that headers like Expires or Cache-Control
are take into account … I’m not able to cache everything. If the
backend set a Expires header in the past, then the page is never
cached. Is there a way to make it work like this ?

Thanks
++ jerome

Hi igor,

I made a patch which add two new directives:
proxy_cache_ignore_headers and fastcgi_cache_ignore_headers. By
default, they are set to off and everything works as before. When set
to on, pages are cached even if Expires or Cache-Control said not to.

I need to cache pages even if the backend said not to because I don’t
have access to the backend code and no one can :frowning:

The patch is attached. I’ve tested it with proxy but not with fastcgi.
As the patch is simple, it should not be a problem.

Hope it would help.

++ Jerome