best way to get number of connections incoming to nginx?

nginx logfile rotation

Re: nginx logfile rotation

Ray wrote:
> Am trying to configure for logfile rotation using logrotate with nginx 
> (0.7.61).  As the logrotate script runs, the old logfile is renamed 
> and a new one is created, but nginx still writes to the old (renamed) 
> logfile even with open_log_file_cache set to off according to 
> http://wiki.nginx.org/NginxHttpLogModule#open_log_file_cache
>
> Is there anything that I'm missing out?
>
> Ray.
kill -USR1 `cat /path/to/nginx.pid`

Re: nginx logfile rotation

Re: nginx logfile rotation

Re: nginx logfile rotation

Ray wrote:
> Is there any way other than killing/restarting the nginx processes?  
> Am asking this because it seemed to me that nginx shouldn't need to be 
> restarted for it to use the new log file, if I didn't read the wiki 
> wrongly.
The "kill" command doesn't kill the process. It merely sends a signal to 
it, in this case "USR1" which re-opens the log file.

See 
http://wiki.nginx.org/NginxCommandLine#Controlling_Nginx_Via_the_Signals .
>
> Ray.
>
> On Tue, Sep 1, 2009 at 10:11 AM, Jim Ohlstein <jim@... 
> <mailto:jim@...>> wrote:
>
>     Ray wrote:
>
>         Am trying to configure for logfile rotation using logrotate
>         with nginx (0.7.61).  As the logrotate script runs, the old
>         logfile is renamed and a new one is created, but nginx still
>         writes to the old (renamed) logfile even with
>         open_log_file_cache set to off according to
>         http://wiki.nginx.org/NginxHttpLogModule#open_log_file_cache
>
>         Is there anything that I'm missing out?
>
>         Ray.
>
>     kill -USR1 `cat /path/to/nginx.pid`
>
>
Jim

Re: nginx logfile rotation

Re: nginx logfile rotation

Ray wrote:
> Wow I never knew that could be done with nginx! Thanks a lot 立冰 and 
> Jim for your help, learnt a lot.
>
> I never came upon http://wiki.nginx.org/NginxCommandLine before by 
> browsing through the wiki, where exactly is it linked from?
>

I'm not sure what pages link to it from within the Wiki. Maybe Cliff 
Wells can answer that. I knew I'd find it quickly by googling "nginx 
signals".

The default signal for "kill" is TERM (at least it is in Linux and I 
believe in FreeBSD as well) so by default it kills the process but there 
are other signals that do not kill the process.

> Ray.
>
> On Tue, Sep 1, 2009 at 11:23 AM, Jim Ohlstein <jim@... 
> <mailto:jim@...>> wrote:
>
>     Ray wrote:
>
>         Is there any way other than killing/restarting the nginx
>         processes?  Am asking this because it seemed to me that nginx
>         shouldn't need to be restarted for it to use the new log file,
>         if I didn't read the wiki wrongly.
>
>     The "kill" command doesn't kill the process. It merely sends a
>     signal to it, in this case "USR1" which re-opens the log file.
>
>     See
>     http://wiki.nginx.org/NginxCommandLine#Controlling_Nginx_Via_the_Signals
>     .
>
>
>         Ray.
>
>
>         On Tue, Sep 1, 2009 at 10:11 AM, Jim Ohlstein <jim@...
>         <mailto:jim@...> <mailto:jim@...
>         <mailto:jim@...>>> wrote:
>
>            Ray wrote:
>
>                Am trying to configure for logfile rotation using logrotate
>                with nginx (0.7.61).  As the logrotate script runs, the old
>                logfile is renamed and a new one is created, but nginx
>         still
>                writes to the old (renamed) logfile even with
>                open_log_file_cache set to off according to
>              
>          http://wiki.nginx.org/NginxHttpLogModule#open_log_file_cache
>
>                Is there anything that I'm missing out?
>
>                Ray.
>
>            kill -USR1 `cat /path/to/nginx.pid`
>
>
>     Jim
>
>
>
Jim

Re: php, $_SERVER & server_name

On Mon, Aug 31, 2009 at 02:21:04PM -0700, Cliff Wells wrote:

> On Mon, 2009-08-31 at 14:07 -0700, Michael Shadle wrote:
> > $host is the same as $http_host?
> 
> Yes, because $http_HEADER is available for *all* headers, so even though
> there's already a $host variable, it's also available via the
> generalized $http_host variable:
> 
> http://wiki.nginx.org/NginxHttpCoreModule#.24host
> http://wiki.nginx.org/NginxHttpCoreModule#.24http_HEADER

No, $host gets its value from

1) request line - http://HOST/...,
2) $http_host,
3) $server_name if reques has no "Host" header line.

> > fastcgi_param SERVER_NAME $http_host;
> > 
> > i've had that in there forever.
> > 
> > just like $uri is short for $request_uri right?
> 
> No, $uri and $request_uri are not always equal:
> 
> http://wiki.nginx.org/NginxHttpCoreModule#.24request_uri
> http://wiki.nginx.org/NginxHttpCoreModule#.24uri
> 
> In short, $uri is the *current* URI (after rewrites, redirects, etc),
> $request_uri is the *original* requested URI.

Yes.

> Regards,
> Cliff
> 
> > this should be documented better somewhere
> > 
> > 2009/8/31 Igor Sysoev <is@...>:
> > > On Mon, Aug 31, 2009 at 03:58:28PM -0500, AMP Admin wrote:
> > >
> > >> I'm trying to list a bunch of domains under server_name.  I'm doing this
> > >> because these domains generate dynamic content based on their name.  it
> > >> seems to work fine except for one thing... $_SERVER['SERVER_NAME'] just
> > >> displays the first server_name entry.
> > >>
> > >> So say we have the following:
> > >>
> > >> server_name   *.example1.com *.example2.com *.example3.com;
> > >>
> > >> echo $_SERVER['SERVER_NAME']; displays *.example1.com regardless which
> > >> domain was entered into the browser.
> > >
> > > You need to change
> > >
> > > -fastcgi_param  SERVER_NAME        $server_name;
> > > +fastcgi_param  SERVER_NAME        $host;
> > >
> > > in fastcgi_params.
> > >
> > >
> > > --
> > > Igor Sysoev
> > > http://sysoev.ru/en/
> > >
> > >
> > 
> -- 
> http://www.google.com/search?q=vonage+sucks
> 

--

-- 
Igor Sysoev
http://sysoev.ru/en/

Re: Weird Memleak problem

Hello!

On Mon, Aug 31, 2009 at 06:10:16PM -0400, Paul wrote:

> Oh I also notice another issue, when ram usage is high like this, when i  
> reload nginx it does this:
> root      5776  0.0  0.1  19528  4876 ?        Ss   Aug30   0:00 nginx:  
> master process /usr/local/nginx/sbin/nginx -c conf/ng1.conf
> www       5777  2.3  2.3 184060 94364 ?        S    Aug30  28:53 nginx:  
> worker process is shutting down
> www       5778  2.3  2.3 315500 95496 ?        S    Aug30  29:23 nginx:  

[...]

> and the processes stay in 'process is shutting down' for a LONG time..  
> I've waited quite a while before
> doing a restart instead of reload to clear them out.   Not sure what  
> would cause this?
> Most of my connection timeouts are set between 60-120seconds. Except SSL  
> session one is 10m, but i've waited
> hours for the old processes to shut down.

nginx worker processes wait for all currently processed requests 
to finish before exiting.  It can take hours if there are active 
but slow requests or requests with big responses.

You may use normal network diagnostic tools (netstat, tcpdump, 
...) to see what actually happens on the wire.

Maxim Dounin