Hello , when run for 5 days, today have 2 segment failure. 2011/09/04 12:00:47 32147#0: worker process 8496 exited on signal 11 (core dumped) 2011/09/04 12:17:32 8497#0: ignore long locked inactive cache entry 57c7c6c612a651727b880a1c9a2c7d2d, count:1 2011/09/04 12:21:31 32147#0: worker process 19185 exited on signal 11 (core dumped) Core was generated by `nginx:'. Program terminby magicbear - Nginx Mailing List - English
may try this: add_header Set-Cookie "uri=$uri; path=/";by magicbear - Nginx Mailing List - English
you can try to add such line to /etc/security/limits.conf nginx soft nofile 131072 nginx hard nofile 1048576 and fastcgi_pass to run PHP you need to set SCRIPT_FILENAME, you may first include fastcgi_params at /etc/nginx (if you install nginx with binary), and then add such line before fastcgi_pass: fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; Piby magicbear - Nginx Mailing List - English
I use at 2x100Mbps server (40% and 10% utilisation), when stable enought, then I will continue to test at 1000Mbps server. splitice Wrote: ------------------------------------------------------- > I havent had any crashes on 3x10mbit servers (90% > utilisation) or 2x100mbit > servers (20% utilisation). > > Seems very stable. > > On Thu, Sep 1, 2011 at 6:04 AM, magby magicbear - Nginx Mailing List - English
OK, It works for 3 days with 40 million request haven't coredump. Thanks. Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Sun, Aug 28, 2011 at 01:07:25PM -0400, > magicbear wrote: > > > Hello, tested for 2 days, the segmentation > failure frequence is > > decreased, but sometime still will dead. > > &by magicbear - Nginx Mailing List - English
If your page can using cache, you can try proxy_cache. And static file don't fallback to Apache, direct using nginx to process. Example config: proxy_cache_path /var/www/cdn_cache levels=1:2 keys_zone=cachedata:128m max_size=4096m; upstream backend { server 127.0.0.1:9000 weight=3 fail_timeout=2s; } location ~ \.(gif|jpg|png|css|js|txt|xml)$ { root /path/to/web; } locationby magicbear - Nginx Mailing List - English
addition information: the server may dead when processed about 20 million requests. Not very high frequencies to dead. 2011/08/27 13:31:21 30433#0: worker process 1944 exited on signal 11 (core dumped) 2011/08/28 14:40:35 30433#0: worker process 14510 exited on signal 11 (core dumped)by magicbear - Nginx Mailing List - English
Hello, tested for 2 days, the segmentation failure frequence is decreased, but sometime still will dead. Here is the coredump information. It seems appear too at official without patch version. GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: youby magicbear - Nginx Mailing List - English
I have patch and it won't dead again, Now run 50 minutes, and handled 330000 request without problem. the problem is not related to proxy_ssl_session_reuse Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Fri, Aug 26, 2011 at 12:17:01PM -0400, > magicbear wrote: > > > It get the same result, I think may be cause by >by magicbear - Nginx Mailing List - English
I am sorry, I just noticed that ngin 1.0.5 has fixed the cache cause segmentation failure bug. And I was test it at 1.0.0. When I remove the following config, the server hasn't dead again now. >> proxy_ssl_session_reuse on; I will continued to keep checking.by magicbear - Nginx Mailing List - English
I think is not your plugins problem. That is nginx core problem. I using the original nginx/1.0.0 will continue to coredump. but the dump position is not same. gdb `which nginx` /var/www/ngx_coredump/core GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free sby magicbear - Nginx Mailing List - English
I tried to disabled my script, but still cause a coredump. here is my nginx.conf user www-data; worker_processes 4; error_log /var/log/nginx/error.log ; pid /var/run/nginx.pid; worker_rlimit_core 8000M; working_directory /var/www/ngx_coredump/; debug_points abort; worker_rlimit_nofile 131072; events { worker_connections 16384; use epoll; # multi_accepby magicbear - Nginx Mailing List - English
It get the same result, I think may be cause by my upload script? I will try to disable it to get result. In another more high load server(without patch) using this script is no this problem. gdb `which nginx` core GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This iby magicbear - Nginx Mailing List - English
http://m-b.cc/tmp/backtrace.txt gdb `which nginx` core GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show wby magicbear - Nginx Mailing List - English
here have the debugging log http://m-b.cc/tmp/debug.log 2011/08/26 19:20:02 21403#0: signal 10 (SIGUSR1) received, reopening logs 2011/08/26 19:20:02 21403#0: wake up, sigio 0 2011/08/26 19:20:02 21403#0: reopening logs 2011/08/26 19:20:02 21403#0: reopen file "/var/log/nginx/error.log", old:9 new:8 2011/08/26 19:20:02 21403#0: reopen file "/var/log/nginx/access.lby magicbear - Nginx Mailing List - English
P.S: I have a cron script that run every minute to upload log to my analytics server, and every minute it will send a USR1 to nginx to reload the log. here is the script, may be help for find bug. #!/bin/bash if [ ! -e /dev/shm/logger ]; then exit 0; fi if [ ! -s /dev/shm/logger ]; then exit 0; fi gzip -c /dev/shm/logger | nc 10.0.0.1 989 rm -f /dev/shm/logger touch /dev/shm/logger chmby magicbear - Nginx Mailing List - English
Hello, I got it 2011/08/26 18:59:27 6564#0: worker process 6565 exited on signal 11 (core dumped) cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=11.04 DISTRIB_CODENAME=natty DISTRIB_DESCRIPTION="Ubuntu 11.04" ===================================================== uname -a Linux sunlight 2.6.38-10-server #46-Ubuntu SMP Tue Jun 28 16:31:00 UTC 2011 x86_64 x86_64 x86_by magicbear - Nginx Mailing List - English
Hello, I found a bug, the stub_status module shows connection and waiting is only increase without decrease. But in fact, system connection haven't such many. Here is the trend chart http://m-b.cc/tmp/bugs.png Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Wed, Aug 24, 2011 at 01:11:43PM -0400, > magicbear wrote: > > >by magicbear - Nginx Mailing List - English
Thanks you, I tested, it works, I will continue to find bug to feedback. Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Wed, Aug 24, 2011 at 01:11:43PM -0400, > magicbear wrote: > > > Thanks for your hard work, I have found that if > using https backend, it > > won't work, server will direct close the > coby magicbear - Nginx Mailing List - English
Thanks for your hard work, I have found that if using https backend, it won't work, server will direct close the connection. curl --head 'http://localhost/track.js' curl: (52) Empty reply from serverby magicbear - Nginx Mailing List - English