Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: captures in regex location
После применения патча (и полной радости по поводу скорости отдачи :)
заметил в nginx/logs/error_log что-то нехорошее, но мне непонятное:
2009/03/06 15:58:08 [alert] 6285#0: worker process 30134 exited on
signal 11
*** glibc detected *** nginx: worker process: corrupted double-linked
list: 0x00000000006c3500 ***
======= Backtrace: =========
/lib64/libc.so.6[0x7fe90f9a5118]
/lib64/libc.so.6[0x7fe90f9a7f94]
/lib64/libc.so.6(__libc_malloc+0xa1)[0x7fe90f9a9891]
nginx: worker process[0x418553]
nginx: worker process[0x414830]
nginx: worker process[0x436766]
nginx: worker process[0x42428b]
nginx: worker process[0x41fae3]
nginx: worker process[0x41fc0c]
nginx: worker process[0x4283b3]
nginx: worker process[0x42898e]
nginx: worker process[0x428e7d]
nginx: worker process[0x4266aa]
nginx: worker process[0x426846]
nginx: worker process[0x41c9b7]
nginx: worker process[0x4162e7]
nginx: worker process[0x41b923]
nginx: worker process[0x41a393]
nginx: worker process[0x41bfc5]
nginx: worker process[0x403f84]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x7fe90f94f586]
nginx: worker process[0x402b49]
======= Memory map: ========
00400000-00451000 r-xp 00000000 08:02
766219 /usr/local/nginx/sbin/nginx
00650000-00651000 r--p 00050000 08:02
766219 /usr/local/nginx/sbin/nginx
00651000-0065a000 rw-p 00051000 08:02
766219 /usr/local/nginx/sbin/nginx
0065a000-0087e000 rw-p 0065a000 00:00
0 [heap]
7fe908000000-7fe908021000 rw-p 7fe908000000 00:00 0
7fe908021000-7fe90c000000 ---p 7fe908021000 00:00 0
7fe90eaa0000-7fe90eab6000 r-xp 00000000 08:02
33014 /lib64/libgcc_s.so.1
7fe90eab6000-7fe90ecb6000 ---p 00016000 08:02
33014 /lib64/libgcc_s.so.1
7fe90ecb6000-7fe90ecb7000 r--p 00016000 08:02
33014 /lib64/libgcc_s.so.1
7fe90ecb7000-7fe90ecb8000 rw-p 00017000 08:02
33014 /lib64/libgcc_s.so.1
7fe90ecb8000-7fe90f0fa000 rw-p 7fe90ecb8000 00:00 0
7fe90f0fa000-7fe90f105000 r-xp 00000000 08:02
33063 /lib64/libnss_files-2.9.so
7fe90f105000-7fe90f304000 ---p 0000b000 08:02
33063 /lib64/libnss_files-2.9.so
7fe90f304000-7fe90f305000 r--p 0000a000 08:02
33063 /lib64/libnss_files-2.9.so
7fe90f305000-7fe90f306000 rw-p 0000b000 08:02
33063 /lib64/libnss_files-2.9.so
7fe90f306000-7fe90f310000 r-xp 00000000 08:02
32927 /lib64/libnss_nis-2.9.so
7fe90f310000-7fe90f50f000 ---p 0000a000 08:02
32927 /lib64/libnss_nis-2.9.so
7fe90f50f000-7fe90f510000 r--p 00009000 08:02
32927 /lib64/libnss_nis-2.9.so
7fe90f510000-7fe90f511000 rw-p 0000a000 08:02
32927 /lib64/libnss_nis-2.9.so
7fe90f511000-7fe90f526000 r-xp 00000000 08:02
32846 /lib64/libnsl-2.9.so
7fe90f526000-7fe90f725000 ---p 00015000 08:02
32846 /lib64/libnsl-2.9.so
7fe90f725000-7fe90f726000 r--p 00014000 08:02
32846 /lib64/libnsl-2.9.so
7fe90f726000-7fe90f727000 rw-p 00015000 08:02
32846 /lib64/libnsl-2.9.so
7fe90f727000-7fe90f729000 rw-p 7fe90f727000 00:00 0
7fe90f729000-7fe90f730000 r-xp 00000000 08:02
33061 /lib64/libnss_compat-2.9.so
7fe90f730000-7fe90f92f000 ---p 00007000 08:02
33061 /lib64/libnss_compat-2.9.so
7fe90f92f000-7fe90f930000 r--p 00006000 08:02
33061 /lib64/libnss_compat-2.9.so
7fe90f930000-7fe90f931000 rw-p 00007000 08:02
33061 /lib64/libnss_compat-2.9.so
7fe90f931000-7fe90fa80000 r-xp 00000000 08:02
32916 /lib64/libc-2.9.so
7fe90fa80000-7fe90fc80000 ---p 0014f000 08:02
32916 /lib64/libc-2.9.so
7fe90fc80000-7fe90fc84000 r--p 0014f000 08:02
32916 /lib64/libc-2.9.so
7fe90fc84000-7fe90fc85000 rw-p 00153000 08:02
32916 /lib64/libc-2.9.so
7fe90fc85000-7fe90fc8a000 rw-p 7fe90fc85000 00:00 0
7fe90fc8a000-7fe90fc9f000 r-xp 00000000 08:02
32938 /lib64/libz.so.1.2.3
7fe90fc9f000-7fe90fe9e000 ---p 00015000 08:02
32938 /lib64/libz.so.1.2.3
7fe90fe9e000-7fe90fe9f000 r--p 00014000 08:02
32938 /lib64/libz.so.1.2.3
7fe90fe9f000-7fe90fea0000 rw-p 00015000 08:02
32938 /lib64/libz.so.1.2.3
7fe90fea0000-7fe90fecf000 r-xp 00000000 08:02
536054 /usr/lib64/libpcre.so.0.0.1
7fe90fecf000-7fe9100ce000 ---p 0002f000 08:02
536054 /usr/lib64/libpcre.so.0.0.1
7fe9100ce000-7fe9100cf000 r--p 0002e000 08:02
536054 /usr/lib64/libpcre.so.0.0.1
7fe9100cf000-7fe9100d0000 rw-p 0002f000 08:02
536054 /usr/lib64/libpcre.so.0.0.1
7fe9100d0000-7fe9100dd000 r-xp 00000000 08:02
32918 /lib64/libcrypt-2.9.so
7fe9100dd000-7fe9102dd000 ---p 0000d000 08:02
32918 /lib64/libcrypt-2.9.so
7fe9102dd000-7fe9102de000 r--p 0000d000 08:02
32918 /lib64/libcrypt-2.9.so
7fe9102de000-7fe9102df000 rw-p 0000e000 08:02
32918 /lib64/libcrypt-2.9.so
7fe9102df000-7fe91030d000 rw-p 7fe9102df000 00:00 0
7fe91030d000-7fe91032b000 r-xp 00000000 08:02
33138 /lib64/ld-2.9.so
7fe91037a000-7fe91051e000 rw-p 7fe91037a000 00:00 0
7fe910527000-7fe910528000 rw-s 00000000 00:09
1451778944 /dev/zero (deleted)
7fe910528000-7fe91052a000 rw-p 7fe910528000 00:00 0
7fe91052a000-7fe91052b000 r--p 0001d000 08:02
33138 /lib64/ld-2.9.so
7fe91052b000-7fe91052c000 rw-p 0001e000 08:02
33138 /lib64/ld-2.9.so
7fff18516000-7fff1852b000 rw-p 7ffffffea000 00:00
0 [stack]
7fff18549000-7fff1854a000 r-xp 7fff18549000 00:00
0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00
0 [vsyscall]
2009/03/06 17:03:45 [alert] 6285#0: worker process 2578 exited on
signal 11
2009/03/06 17:04:23 [alert] 6285#0: worker process 29952 exited on
signal 11
2009/03/06 17:04:45 [alert] 6285#0: worker process 1441 exited on
signal 11
2009/03/06 17:06:06 [alert] 6285#0: worker process 29891 exited on
signal 11
2009/03/06 17:07:10 [alert] 6285#0: worker process 3198 exited on
signal 11
2009/03/06 17:08:20 [alert] 6285#0: worker process 29937 exited on
signal 11
2009/03/06 17:11:28 [alert] 6285#0: worker process 2470 exited on
signal 11
2009/03/06 17:13:09 [alert] 6285#0: worker process 3144 exited on
signal 11
2009/03/06 17:34:37 [alert] 6285#0: worker process 3034 exited on
signal 11
2009/03/06 17:51:39 [alert] 6285#0: worker process 30952 exited on
signal 11
куда копать, какая еще информация может быть полезной?
Спасибо!
On Mar 6, 2009, at 9:48 AM, Igor Sysoev wrote:
On Fri, Mar 06, 2009 at 01:22:30AM +0300, Vladimir Sopot wrote:
Хотелось бы, как раз, сохранить текущий порядок: проверка
существования файла переписывает URI в "старый" формат, "когда
компьютеры были большими" и адресация на сайте была несколько другая
(при этом файла вообще может и не существовать). А тем, которые EN,
уже однозначно подсовывается новый формат и посылается вдаль, туда,
где о старом варианте ничего не знают.
А в чем вообще прелесть "новых технологий" и location ~* upic\.jpg$
{}
(ну и location ~* "^(................)$" {})?
Новые технологии - это captures в locations.
Что касается location ~* upic\.jpg$ {}, то вот это
location / {
...
}
location ~* upic\.jpg$ {
...
}
всегда было правильным методом в отличие от:
location / {
if ($request_uri ~* upic.jpg) {
break;
}
}
Правило такое - $request_uri и "$request_file_name ~" в if означает,
что
это неправильно, так для этих вещей специально были сделаны
оптимизированные
locations.
On Mar 6, 2009, at 12:32 AM, Igor Sysoev wrote:
On Fri, Mar 06, 2009 at 12:15:28AM +0300, Vladimir Sopot wrote:
On Mar 5, 2009, at 11:37 PM, Igor Sysoev wrote:
On Thu, Mar 05, 2009 at 11:30:14PM +0300, Vladimir Sopot wrote:
А-ха!
В моем if-е подразумевался break, чтобы больше условий (типа
проверки
географии и пр.) в этом server-е не выполнялось. Что должно быть
внутри нового location-а для того же функционала?
Как выглядят if'ы ?
Наверняка, что-то не так с last-break, но работает :)
if ($request_uri ~* upic.jpg) {
break;
}
if (!-f $request_filename) {
rewrite "^(................)$" http://$2$3$4 last;
return 404;
}
if ($country = EN) {
rewrite (.*) http://somewhere.com$1 break;
}
location ~* upic\.jpg$ {
...
}
location ~* "^(................)$" {
if ($country = EN) {
rewrite ^ http://somewhere.com$request_uri?;
}
error_page 404 http://$2$3$4;
}
Только в этом случае "if ($country = EN)" будет выполняться до
проверки
существования файла.
А ещё можно сделать так:
server_name ~^([bos])(\d)p\.site;
set $root /wwwroot/site/$2/$1/;
root $root;
}
Но
if ($request_uri ~* upic.jpg) {
break;
}
нужно однозначно менять на
location ~* upic\.jpg$ {
...
}
On Mar 5, 2009, at 10:43 PM, Igor Sysoev wrote:
On Thu, Mar 05, 2009 at 10:34:51PM +0300, Vladimir Sopot wrote:
Mot*^&@W$ ;".%($ :^?:(;!
Спасибо, действительно, надо обращать больше внимания на имена
файлов
и места сохранения аттачей.
Но всплыл другой непонятный "фич" -
server {
server_name ~^([bos])(\d)p\.site;
root /wwwroot/site/$2/$1/;
}
работает отлично. Но как только внутри, после root ...
появляется
if ($request_uri ~* upic.jpg) {
# не важно что, хотя бы даже пустота
}
всё снова ломается :(
regex в if/rewrite меняют captures, даже если они не сработали.
Несовпавший location regex не трогает captures. Поэтому нужно
переходить
на прогрессивные технологии:
location ~* upic\.jpg {
...
}
P.S. спасибо за ненужную "|" :)
On Mar 5, 2009, at 6:56 PM, Igor Sysoev wrote:
On Thu, Mar 05, 2009 at 06:46:03PM +0300, Vladimir Sopot
wrote:
В эту сторону я уже думал и на такой location - ругается, да.
Но патч вроде ложится -
nginx-0.7.39/src/http # patch -p2 <patch.location_captures
Это первый патч, нужен patch.location_captures1
patching file ngx_http_core_module.c
patching file ngx_http_request.h
patching file ngx_http_script.c
patching file ngx_http_script.h
patching file modules/ngx_http_rewrite_module.c
и objs/nginx получается другого размера, если без патча.
On Mar 5, 2009, at 5:30 PM, Igor Sysoev wrote:
On Thu, Mar 05, 2009 at 05:22:43PM +0300, Vladimir Sopot
wrote:
Увы,
2009/03/05 16:54:16 [error] 18720#0: *5440 open() "/
wwwroot/
site///e/
ea/0/12720.jpg" failed (2: No such file or directory),
client: 94.188.35.148, server: ~^(s)(\d)\.site, request:
"GET /e/
ea/
0/12720.jpg HTTP/1.1", host: "s0.site", referrer:
"http://site/ea/12720.html"
Тоесть сервер точно матчится, но вот $1-2 не
устанавливаются :(
Куда бы еще копнуть? Уж больно хочется и конфиг порезать
и на
регекспах сэкономить :)
А патч точно приложен ?
Что показывает nginx, если в конфиг добавить такое:
location ~ \.TXT$ {
alias /wwwroot/;
}
?
# uname -a
Linux site 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04
+0100
x86_64
x86_64 x86_64 GNU/Linux
# ./configure --with-http_stub_status_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --without-http_access_module --without-http_autoindex_module --without-http_browser_module --without-http_charset_module --without-http_limit_zone_module --without-http_map_module --without-http_memcached_module --without-http_referer_module --without-http_ssi_module --without-http_userid_module --without-http_proxy_module --without-http_proxy_module
...........
checking for PCRE library ... found
...........
Configuration summary
+ using system PCRE library
...........
# pcre-config --version
7.8
On Mar 5, 2009, at 4:14 PM, Igor Sysoev wrote:
On Thu, Mar 05, 2009 at 03:46:55PM +0300, Vladimir Sopot
wrote:
Помимо описанного сервера есть еще секции
server {
server_name ~^([b|o])(\d)\.site;
.......
}
server {
listen *:80 default bind sndbuf=64k;
server_name site
..........
}
и добавление пустого сервера не исправило ситуацию.
У меня для
server {
listen 8000;
server_name ~^([b|o])(\d)z\.site;
root /wwwroot/site/$1/$2/;
}
в логах такая ошибка:
[error] 58504#0: *1 open() "/wwwroot/site/b/1/dir/
index.html"
failed
(2: No such file or directory), client: 127.0.0.1, server:
~^([b|
o])
(\d)z\.site, request: "GET /dir/index.html HTTP/1.0",
host:
"b1z.site"
То есть, путь "/wwwroot/site/b/1/dir/index.html"
формиурется
правильно.
Кстати, "|" в "([b|o])" - лишняя.
On Mar 5, 2009, at 2:43 PM, Igor Sysoev wrote:
On Thu, Mar 05, 2009 at 01:57:49PM +0300, Vladimir Sopot
wrote:
Спасибо, но что-то оно не того
server {
server_name ~^([b|o])(\d)z\.site;
# if ($host ~* (.)(\d)) {
set $store_type $1;
set $store_id $2;
# }
root /wwwroot/site/$store_id/$store_type/;
}
В таком виде не работает (404), если убрать
комментарии -
все
становится на свои места. Забрать root внутрь
location /
{ }
тоже
ничего не дает. root /wwwroot/site/$2/$1/ тоже не
работает
Скорее всего, regex вообще не исполняется, потому что
сервер
один -
проверять нечего. Нужно добавить пустой сервер, чтобы
nginx
начал
проверять
server_name:
server { server_name _; }
On Mar 5, 2009, at 1:17 PM, Igor Sysoev wrote:
On Thu, Mar 05, 2009 at 12:14:55PM +0200, Andrew
Sitnikov
wrote:
А можно такое же ещё и для server_name?
IS> Новый патч с поддержкой server_name.
можно пример ?
Наверное, как-то так:
server {
listen 8000;
server_name ~^(?:www\.)?(.+)$;
location / {
root /path/to/$1;
}
}
--
Игорь Сысоев
http://sysoev.ru
--
Игорь Сысоев
http://sysoev.ru
--
Игорь Сысоев
http://sysoev.ru
--
Игорь Сысоев
http://sysoev.ru
--
Игорь Сысоев
http://sysoev.ru
|