worker process exited on signal 11 (core dumped)

[Maxim Dounin]

Hello!

On Wed, Feb 10, 2010 at 02:07:09PM +0300, Vladimir Sopot wrote:

> 
> On Feb 10, 2010, at 1:26 PM, Maxim Dounin wrote:
> 
> >>>> memcached 1.4.4
> >>>> /usr/local/bin/memcached -u nobody -m 256 -c 8192 -d -s /tmp/memcached.sock
> >>> 
> >>> Это интересно, к этому мы вернёмся позже.
> >> 
> >> А что тут?
> > 
> > Если сообщения "memcached sent invalid trailer" не пропали:
> > 
> > 1. Попробовать выключить keepalive (достаточно в конфиге) и 
> > посмотреть пропадут ли.
> 
> Выключил. Посмотрим.
> 
> > 2. Проверить наличие других сообщений о проблемах с memcached, 
> > таких как "memcached sent invalid key in response", "memcached 
> > sent invalid length in response", "memcached sent invalid 
> > response".  Если есть - привести их, и проверить для них пункт 1.
> 
> За ~час, пока не пробовал без keepalive, прилетело 3 пары. За 10 минут после отключения keepalive пока пусто. Keepalive - враг?
> 
> 2010/02/10 12:38:16 [error] 22972#0: *70274 memcached sent invalid trailer while sending to client
> 2010/02/10 12:38:16 [error] 22972#0: *70000 memcached sent invalid response: "D" while reading response header from upstream,
> 
> 2010/02/10 13:06:05 [error] 25051#0: *1223490 memcached sent invalid trailer while sending to client,
> 2010/02/10 13:06:07 [error] 25051#0: *1223473 memcached sent invalid response: "D" while reading response header from upstream
> 
> 2010/02/10 13:15:39 [error] 25057#0: *1629528 memcached sent invalid trailer while sending to client
> 2010/02/10 13:15:39 [error] 25057#0: *1629946 memcached sent invalid response: "D" while reading response header from upstream

Ok, кажется я понял проблему.  Судя по всему memcached_pass не 
дожидается полного прилёта trailer'а ("END") и ругается.  А в 
случае keepalive остатки trailer'а долетают в ответ на следующий 
запрос.

По идее строка "invalid trailer" должна наблюдаться и без 
keepalive (но скорее всего реже), а "invalid response" - только 
если keepalive включён.

Буду смотреть подробнее чуть позже.

> Заметил особенность некасательно этих ^^^ запросов. "subrequests 
> cycle while processing" возникают очень часто на #51 ssi include 
> virtual. Фактически увидел НЕ на #51 всего несколько раз из 
> сотни.

Потому что проверка на циклы срабатывает когда одновременно 
обрабатывается более 50 подзапросов.

> >>>> location ~ /mmc/today/(\d+) {
> >>>> 	internal;
> >> 
> >> Кстати, даже с internal ЭТО доступно из броузера.. Как же так?
> > 
> > С internal происходит 404, а он у вас перехвачен в то же самое но 
> > на php.
> > 
> >>>> 	set $memcached_key "today_$1";
> >>>> 	memcached_pass tablew_mmc;
> >>>> 	error_page 404 502 /main/ssi/today_counter.php?ad=$1;
> >>>> 	}
> 
> - error_page 404 502 /main/ssi/today_counter.php?ad=$1;
> + error_page 404 502 = /main/ssi/today_counter.php?ad=$1;
> 
> location ^~ /main/ {
> 	include fastcgi_params;
> 	}
> 
> location /main/ssi/ {
> 	internal;
> 	include fastcgi_params;
> 	}
> 
> при запросе /main/ssi/today_counter.php имеем 404, при /mmc/today - нормальный ответ.
> Чую западню, но не понимаю где :(

Попадание внешнего запроса в location с флагом internal приводит к 
возврату 404 ошибки.  Случается внутренний редирект на страницу 
ошибки.  И возврат этой страницы, даже если она тоже в location 
с флагом internal - т.к. запрос 404 ошибки уже внутренний.

Maxim Dounin