On Sat, Apr 21, 2012 at 5:28 AM, Ruslan Ermilov <ru@nginx.com> wrote: > On Sat, Apr 21, 2012 at 02:47:23AM +0200, Grégory Pakosz wrote: >> I'm facing a SIGSEGV when trying to setup a custom error page using >> the following (shortened for the sake of debugging) configuration. > > It's been fixed already: > http://trac.nginx.org/nginx/changeset/4601/nginx > Hi therby gpakosz - Nginx Mailing List - English
Hello, I'm facing a SIGSEGV when trying to setup a custom error page using the following (shortened for the sake of debugging) configuration. /etc/nginx/sites-available/example.com: server { listen 80; server_name example.com; access_log /var/log/nginx/example.com_access.log; error_log /var/log/nginx/example.com_error.log debug; root /var/www; error_page 404 @404; locatiby gpakosz - Nginx Mailing List - English
On Thu, Apr 19, 2012 at 3:35 PM, Maxim Dounin <mdounin@mdounin.ru> wrote: > > You mean nginx worker process crash, right? > > errors get logged into /var/log/nginx/error.log: 2012/04/19 15:34:41 5712#0: worker process 9234 exited on signal 11 2012/04/19 15:34:48 5712#0: worker process 9252 exited on signal 11 2012/04/19 15:34:57 5712#0: worker process 9253 exited on signal 11by gpakosz - Nginx Mailing List - English
Hello, I'm facing the situation where worker process crashes in the php-fpm backend with SIGSEGV: 5712#0: worker process 5713 exited on signal 11 In such a case, what happens to the connection? is it dangling? Crashes in the backend are random, and I have the impression that when too many crashes happen in a row, connection stay open and eventually I'm hitting limit_conn. What do you think? Rby gpakosz - Nginx Mailing List - English
Thank you all for your reply So, adding fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; doesn't really hurt. The box I'm running does shared hosting for a couple of users and I don't really know in advance what they want to install on their account. I'm going to keep those 3 lines in hopeby gpakosz - Nginx Mailing List - English
> > > > > fastcgi_split_path_info ^(.+\.php)(/.+)$; > > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > > fastcgi_param SCRIPT_NAME $fastcgi_script_name; > > > > Those are to handle urls like www.example.com/index.php/some/para/meters. > > Well then Wordpress, Drupal and Joomla can do without them. From your remark, I deduce some othby gpakosz - Nginx Mailing List - English
Hello, Everyone knows there are many nginx tutorials out there and I would like to know what's the "modern way" when writing a php location block, I'm doing (nginx 1.1.: location ~ \.php$ { try_files $uri =404; include fastcgi_params; fastcgi_pass unix:/var/run/php5-fpm/www-data.sock; } And it works pretty well. I quick tested phpinfo, drupal, joomla, wordpress and they all runby gpakosz - Nginx Mailing List - English
Hello, I noticed the following behavior. 1) stop nginx (/etc/init.d/nginx stop on a debian box) 2) remove all logs in /var/log/nginx/ 3) start nginx now /var/log/nginx/access.log and /var/log/nginx/error.log are owned by root:root. in fact it's the same for all other vhosts log files. 4) issue kill -USR1 `cat /var/run/nginx.pid` now /var/log/nginx/access.log and /var/log/nginx/error.log areby gpakosz - Nginx Mailing List - English
> > > > > > Thank you for your answer. May I suggest that explanation enters the wiki > > in the error_page directive section? > > http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page > > : These directives are inherited from the previous level if and > : only if there are no error_page directives on the current level. > > Fair enough! I'by gpakosz - Nginx Mailing List - English
> > The error_page directives are inherited if and only if there is absolutely > NO error_page directive on the current level. Moreover, whenever you use > the error_page directive you are doing two things: 1) explicitly setting > error pages for the specified error codes 2) implicitly resetting error > pages for all the other error codes that are not explicitly set on the > cby gpakosz - Nginx Mailing List - English
Hello, In my server block, I configured a custom 404 error page and I tried to disable access log for /favicon.ico error_page 404 /404.html; location = /favicon.ico { access_log off; } http://pastebin.com/39qXWuq2 It seems that both conflicts. When favicon.ico is present: curl -I http://mydomain.com/favicon.ico reports 200 status code and nothing gets logged into my access log When faviconby gpakosz - Nginx Mailing List - English
Hello, I'm using nginx 1.1.14 on Debian Squeeze. In /etc/nginx.conf I wrote: error_page 404 http://google.com; That error_page directive is written in the http context. So far so good, when I visit http://mydomain.com/foo.txt and foo.txt doesn't exist in root's folder, I'm getting redirected to http://google.com as per the 404 error handling. However, if in my server context, inside /etc/siteby gpakosz - Nginx Mailing List - English