*) Change: the "none" parameter in the "ssl_session_cache"
directive;
now this is default parameter.
Thanks to Rob M…
*) Change: now the 0x00-0x1F, '"' and '\' characters are escaped as
\xXX in an access_log.
Thanks to Maxim D..
*) Change: now nginx allows several "Host" request header line.
*) Feature: the "modified" flag in the "expires" directive.
*) Feature: the $uid_got and $uid_set variables may be used at any
request processing stage.
*) Feature: the $hostname variable.
Thanks to Andrei Nigmatulin.
*) Feature: DESTDIR support.
Thanks to Todd A. Fisher and Andras Voroskoi.
*) Bugfix: if sub_filter and SSI were used together, then responses
might were transferred incorrectly.
*) Bugfix: large SSI inclusions might be truncated.
*) Bugfix: the "proxy_pass" directive did not work with the HTTPS
protocol; the bug had appeared in 0.6.9.
*) Bugfix: worker processes might not catch reconfiguration and log
rotation signals.
*) Bugfix: nginx could not be built on latest Fedora 9 Linux.
Thanks to Roxis.
*) Bugfix: a segmentation fault might occur in worker process on
*) Change: now nginx allows several “Host” request header line.
sorry - could you elaborate on this? meaning nginx will (and this would be
weird) be able to send multiple Host lines in one request? or?
No, now nginx accepts several Host headers in a request, and it uses the
first
header to select virtual host. Early nginx refused such requests with
400 code.
Java in some Motorola phones (e.g. K1) sends two Host headers: one is
correct,
and another is “localhost”.
*) Change: now nginx allows several “Host” request header line.
sorry - could you elaborate on this? meaning nginx will (and this would
be
weird) be able to send multiple Host lines in one request? or?
-jf
–
In the meantime, here is your PSA:
“It’s so hard to write a graphics driver that open-sourcing it would not
help.”
– Andrew Fear, Software Product Manager, NVIDIA Corporation
sorry - could you elaborate on this? meaning nginx will (and this would
and another is “localhost”.
got it, thanks. I certainly didnt know that…
-jf
–
In the meantime, here is your PSA:
“It’s so hard to write a graphics driver that open-sourcing it would not
help.”
– Andrew Fear, Software Product Manager, NVIDIA Corporation
On Tue, Jul 08, 2008 at 03:20:02PM +0300, Athan D. wrote:
On Tue, 08 Jul 2008 14:59:07 +0300, Igor S. [email protected] wrote:
This means that someone kills -9 worker process.
I know that Igor, but I’ve seen this log message for first time, and I
thought that’s related to latest build installed yesterday.
Maybe it’s just a coincidence.
If it was not done by some user, then it may be done by master process,
if worker does not exit cleanly by itself.
On Tue, 08 Jul 2008 14:59:07 +0300, Igor S. [email protected] wrote:
This means that someone kills -9 worker process.
I know that Igor, but I’ve seen this log message for first time, and I
thought that’s related to latest build installed yesterday.
Maybe it’s just a coincidence.
On Tue, 08 Jul 2008 16:08:08 +0300, Igor S. [email protected] wrote:
Even more “worker process xxxxx exited on signal 9” errors in daily log,
six in the last ten hours.
Igor, I don’t know why but this problem started after upgraded to
0.6.32;
Never had such an issue with any previous nginx builds. Is there
something
I can do to help you track this problem?
On Wed, Jul 09, 2008 at 02:53:09PM +0300, Athan D. wrote:
On Tue, 08 Jul 2008 16:08:08 +0300, Igor S.
Even more “worker process xxxxx exited on signal 9” errors in daily log,
six in the last ten hours.
Igor, I don’t know why but this problem started after upgraded to 0.6.32;
Never had such an issue with any previous nginx builds. Is there something
I can do to help you track this problem?
Could you run error_log on notice level ?
On this level worker logs signals those it is receive.
After this could you send -HUP signal to master and look error log.
On Tue, 08 Jul 2008 16:08:08 +0300, Igor S. [email protected] wrote:
If it was not done by some user, then it may be done by master process,
if worker does not exit cleanly by itself.
It was not killed by some user, I assume you’re right and master process
killed worker. However I’ll keep an eye on log for a few days because
it’s
first time this happened or to be precise, first time I see the specific
error message.
On Wed, 09 Jul 2008 15:06:10 +0300, Igor S. [email protected] wrote:
Could you run error_log on notice level ?
On this level worker logs signals those it is receive.
After this could you send -HUP signal to master and look error log.
What OS do you use ?
I’m using FreeBSD 7.0 stable (AMD64).
I’ve changed notice level from warn to notice and I’ll keep you informed
about log results. So far, whatever I did I cannot reproduce the error.
Seems it happens randomly, we’ll see.
On Wed, Jul 09, 2008 at 03:57:22PM +0300, Athan D. wrote:
On Wed, 09 Jul 2008 15:06:10 +0300, Igor S. [email protected] wrote:
Could you run error_log on notice level ?
On this level worker logs signals those it is receive.
After this could you send -HUP signal to master and look error log.
What OS do you use ?
I’m using FreeBSD 7.0 stable (AMD64).
Strange, I run 0.6.32 in production on the same OS.
I’ve changed notice level from warn to notice and I’ll keep you informed
about log results. So far, whatever I did I cannot reproduce the error.
Seems it happens randomly, we’ll see.
On Wed, 09 Jul 2008 16:00:13 +0300, Igor S. [email protected] wrote:
Strange, I run 0.6.32 in production on the same OS.
Yeah, really strange Igor. As already told you, I’ve never noticed such
an
error using any previous nginx releases.
Anyway, in the last hours it happened once as you can see in the
following
log excerpt.
-----------------8<-----------------
2008/07/09 19:13:20 [notice] 52325#0: exit
2008/07/09 19:13:20 [notice] 52324#0: signal 23 (SIGIO) received
2008/07/09 19:13:20 [notice] 52324#0: signal 20 (SIGCHLD) received
2008/07/09 19:13:20 [notice] 52324#0: worker process 52325 exited with
code 0
2008/07/09 19:13:20 [notice] 52324#0: signal 23 (SIGIO) received
2008/07/09 19:13:20 [notice] 52326#0: exiting
2008/07/09 19:13:20 [notice] 52326#0: exit
2008/07/09 19:13:20 [notice] 52324#0: signal 23 (SIGIO) received
2008/07/09 19:13:20 [notice] 52324#0: signal 20 (SIGCHLD) received
2008/07/09 19:13:20 [notice] 52324#0: worker process 52326 exited with
code 0
2008/07/09 19:13:20 [notice] 52324#0: exit
2008/07/09 19:13:21 [notice] 54094#0: using the “kqueue” event method
2008/07/09 19:13:21 [notice] 54094#0: nginx/0.6.32
2008/07/09 19:13:21 [notice] 54094#0: OS: FreeBSD 7.0-RELEASE-p0
2008/07/09 19:13:21 [notice] 54094#0: kern.osreldate: 700000, built on
700000
2008/07/09 19:13:21 [notice] 54094#0: hw.ncpu: 2
2008/07/09 19:13:21 [notice] 54094#0: net.inet.tcp.sendspace: 32768
2008/07/09 19:13:21 [notice] 54094#0: kern.ipc.somaxconn: 128
2008/07/09 19:13:21 [notice] 54094#0: getrlimit(RLIMIT_NOFILE):
11095:11095
2008/07/09 19:13:21 [notice] 54095#0: start worker processes
2008/07/09 19:13:21 [notice] 54095#0: start worker process 54096
2008/07/09 19:13:21 [notice] 54095#0: start worker process 54097
2008/07/09 19:13:21 [notice] 54095#0: signal 23 (SIGIO) received
2008/07/09 19:23:21 [notice] 54095#0: signal 15 (SIGTERM) received,
exiting
2008/07/09 19:23:21 [notice] 54096#0: exiting
2008/07/09 19:23:21 [notice] 54096#0: exit
2008/07/09 19:23:21 [notice] 54095#0: signal 23 (SIGIO) received
2008/07/09 19:23:21 [notice] 54095#0: signal 20 (SIGCHLD) received
2008/07/09 19:23:21 [notice] 54095#0: worker process 54096 exited with
code 0
2008/07/09 19:23:21 [notice] 54095#0: signal 23 (SIGIO) received
2008/07/09 19:23:21 [notice] 54095#0: signal 23 (SIGIO) received
2008/07/09 19:23:21 [notice] 54095#0: signal 23 (SIGIO) received
2008/07/09 19:23:21 [notice] 54095#0: signal 23 (SIGIO) received
2008/07/09 19:23:21 [notice] 54095#0: signal 20 (SIGCHLD) received
2008/07/09 19:23:21 [alert] 54095#0: worker process 54097 exited on
signal
9
2008/07/09 19:23:21 [notice] 54095#0: exit
-----------------8<-----------------
It’s the 54097 process that exited with signal 9.
BTW I’m using the unmodified FreeBSD nginx port using only http and
rewrite module.
On Thu, Jul 10, 2008 at 12:06:18AM +0300, Athan D. wrote:
2008/07/09 19:13:20 [notice] 52325#0: exit
code 0
2008/07/09 19:13:21 [notice] 54095#0: start worker processes
2008/07/09 19:23:21 [notice] 54095#0: signal 23 (SIGIO) received
BTW I’m using the unmodified FreeBSD nginx port using only http and
rewrite module.
I do not use the port and run reconfiguration using -HUP signal.
After online upgrade, I exit old nginx using gracefull -QUIT signal.
What do you run at 19:23:21 -
/usr/local/etc/rc.d/nginx.sh WHAT ?
-KILL is sent to a worker after master has got -TERM signal and the
worker
has not exit after 1 second.
On Thu, Jul 10, 2008 at 11:54:18AM +0300, Athan D. wrote:
tests. All other processes are not related to nginx (postfix, mysql,
dovecot, cron, etc) and no entries exist in other logs for that time.
Also, no other user can login this server.
BTW the server I’m using is a VPS (jail) if that counts.
What I see in log is that some/one(thing) has sent -TERM to master:
2008/07/09 19:23:21 [notice] 54095#0: signal 15 (SIGTERM) received,
exiting
On Thu, 10 Jul 2008 08:51:51 +0300, Igor S. [email protected] wrote:
I do not use the port and run reconfiguration using -HUP signal.
After online upgrade, I exit old nginx using gracefull -QUIT signal.
What do you run at 19:23:21 -
/usr/local/etc/rc.d/nginx.sh WHAT ?
Nothing was run on my side Igor. The only thing that could stop or
restart
nginx is the monitor daemon I’m using (monit) but I had it stopped
during
tests. All other processes are not related to nginx (postfix, mysql,
dovecot, cron, etc) and no entries exist in other logs for that time.
Also, no other user can login this server.
BTW the server I’m using is a VPS (jail) if that counts.