Работает после установки только если ещё раз перезагрузиться, до этого отдаёт ssl сертификат и перестаёт отвечать на запросы.
В реальности он не работает также если выполнить service ahttpd restart Но работает если запустить ahttp -l (то есть без демонизации) Чудеса.
Проблема где-то в районе ф-ции message-handler. Но что там происходит, почему влияет демонизация и почему все работает до service ahttpd restart - я не понимаю :(.
Точнее в response-handler при вызове with-ahttpd-session, похоже.
Будем посмотреть…
Посмотрел. Там всё очень неважно: на первый взгляд кажется, что дело в самом guile. Например, после `service ahttpd restart` не работает вызов string-downcase (управление оттуда не возвращается), хотя она, извините, primitive-proc. Далее, let-values обрабатывается нормально, а let*-values — подвисает, не вычисляя ни один из своих аргументов. Однако эта гипотеза, скорее всего не верна, или не совсем верна, потому как даже в 5.1 версия guile у нас всё та же — 1.8.7, отличаются только alt-релизы. Выходит, проблема ещё глубже? Самое ужасное, что на моей системе после dist-upgrade проблема не воспроизводится.
(В ответ на комментарий №5) > Самое ужасное, что на моей системе после dist-upgrade проблема не > воспроизводится. А что обновилось?
Created attachment 5612 [details] Запуск ahttpd с демонизацией через start-stop-daemon
Точно не знаю, что обновилось, но предлагаю подойти к проблеме немного с другой стороны. Перед тем, как увидел «что же там внутри», я был уверен, что дело в каком-нибудь файле, который не удаляется при перезапуске ahttpd. Но в явном виде проблем с файлами обнаружено не было. Что же получается? При первом после перезагрузки системы запуске, программа работает как положено, а при повторном подвисает в совершенно неожиданных местах. В связи с этим, предлагаю поймать первого пробегающего мимо архитектора Linux-систем и спросить у него, где может накапливаться разница между первым и вторым запуском демона. Именно демона, т.к. повторный запуск в foreground функционирует нормально. А пока никто мимо не пробежал и на вопрос не ответил, то, как оказалось, проблему можно обойти отказавшись от штатной демонизации, и положившись на start-stop-deamon (патч прилагается). В связи с этим, кстати, можно заключить, что guile «башню сносит» именно где-то в районе deamonize, которая определена где-то в недрах libguile-vhttpd…
(In reply to comment #8) > Точно не знаю, что обновилось, но предлагаю подойти к проблеме немного с > другой стороны. > > Перед тем, как увидел «что же там внутри», я был уверен, что дело в > каком-нибудь файле, который не удаляется при перезапуске ahttpd. Но в явном > виде проблем с файлами обнаружено не было. Что же получается? При первом после > перезагрузки системы запуске, программа работает как положено, а при повторном > подвисает в совершенно неожиданных местах. Если первый запуск ahttpd после загрузки был без демонизации, влияет ли это на последующий запуск с демонизацией? > В связи с этим, предлагаю поймать первого пробегающего мимо архитектора > Linux-систем и спросить у него, где может накапливаться разница между первым и > вторым запуском демона. Именно демона, т.к. повторный запуск в foreground > функционирует нормально. Возможно, демон не убивается до конца, или оставляет за собой файлы, влияющие на демонизацию. Возможно, демонизация просто кривая, и работает только один раз. > А пока никто мимо не пробежал и на вопрос не ответил, то, как оказалось, > проблему можно обойти отказавшись от штатной демонизации, и положившись на > start-stop-deamon (патч прилагается). В связи с этим, кстати, можно заключить, > что guile «башню сносит» именно где-то в районе deamonize, которая определена > где-то в недрах libguile-vhttpd… Демонизация с помощью start-stop-deamon - это костыль для убогих. Отказываться от штатной демонизации имеет смысл только если вы запускаете ahttpd из systemd с помощью файла ahttpd.service, которого в пакете alterator-fbi не видно.
(В ответ на комментарий №9) > (In reply to comment #8) > Возможно, демон не убивается до конца, Процесса нет, я проверял. > или оставляет за собой файлы, влияющие на демонизацию. Вроде нет таких. > Возможно, демонизация просто кривая, и работает только один раз. Она работает, но сам демон начинает глючить. И, возвращаясь к исходному вопросу, как можно сделать «один раз» не используя файлы? Т.е. откуда она может знать, что данный раз — не первый? :)
Припоминаются болтающиеся сегменты shm и IIRC семафоры; см. тж. http://lists.altlinux.org/pipermail/devel/2003-August/095235.html http://lists.altlinux.org/pipermail/community/2001-August/440930.html
(In reply to comment #11) > Припоминаются болтающиеся сегменты shm и IIRC семафоры; см. тж. > http://lists.altlinux.org/pipermail/devel/2003-August/095235.html > http://lists.altlinux.org/pipermail/community/2001-August/440930.html И очереди - в SysV IPC три типа объектов. Инструмент для просмотра: ipcs(1).
Решил углубиться ещё дальше. guile/libguile/strings.c 341 char * 342 scm_i_string_writable_chars (SCM orig_str) 343 { 344 SCM buf, str = orig_str; 345 size_t start; 346 347 get_str_buf_start (&str, &buf, &start); 348 if (IS_RO_STRING (str)) 349 scm_misc_error (NULL, "string is read-only: ~s", scm_list_1 (orig_str)); 350 351 scm_i_pthread_mutex_lock (&stringbuf_write_mutex); 352 if (STRINGBUF_SHARED (buf)) 353 { 354 /* Clone stringbuf. For this, we put all threads to sleep. 355 */ 356 357 size_t len = STRING_LENGTH (str); 358 SCM new_buf; 359 360 scm_i_pthread_mutex_unlock (&stringbuf_write_mutex); 361 362 new_buf = make_stringbuf (len); 363 memcpy (STRINGBUF_CHARS (new_buf), 364 STRINGBUF_CHARS (buf) + STRING_START (str), len); 365 366 scm_i_thread_put_to_sleep (); 367 SET_STRING_STRINGBUF (str, new_buf); 368 start -= STRING_START (str); 369 SET_STRING_START (str, 0); 370 scm_i_thread_wake_up (); 371 372 buf = new_buf; 373 374 scm_i_pthread_mutex_lock (&stringbuf_write_mutex); 375 } 376 377 return STRINGBUF_CHARS (buf) + start; 378 } Блокировка (lock/unlock) отрабатывает нормально. Однако сон (sleep) одолевает, видимо, все процессы, включая текущий, что из логики кода вроде бы не следует. 366 scm_i_thread_put_to_sleep (); Вот прямо тут и висим. Вообще про логику кода я немного поспешил: для начала её понять нужно. Лично меня вводит в ступор эдакая блокировка наизнанку, когда всё заканчивается lock. Обычно ведь блокировка кратковременна.
А в свежей guile 1.8.8 изменений тут нет?
(В ответ на комментарий №14) > А в свежей guile 1.8.8 изменений тут нет? Сейчас посмотрим. Но вряд ли дело в том, что этот кусок безусловно кривой. Скорее, некоторое внешнее по отношению к guileПотому что: 1. она давно (по крайней мере с 5.1) уже не обновлялась и всё работало; 2. после dist-upgrade cert6 → Sisyphus всё продолжает работать (у меня). Т.е. мы имеем дело с чем-то, что делает работу guile нестабильной. Что это за обстоятельства — непонятно.
(В ответ на комментарий №14) > А в свежей guile 1.8.8 изменений тут нет? Сейчас посмотрим. Но вряд ли дело в том, что этот кусок безусловно кривой. Скорее, некоторое внешнее по отношению к guile обстоятельство делает её работу нестабильной. Потому что: 1. она давно (по крайней мере с 5.1) уже не обновлялась и всё работало; 2. после dist-upgrade cert6 → Sisyphus всё продолжает работать (у меня); 3. при запуске из консоли всё работает; 4. с демонизацией через start-stop-daemon всё работает. Что это за обстоятельство? В том-то и вопрос…
(В ответ на комментарий №14) > А в свежей guile 1.8.8 изменений тут нет? Оказалось, что string.c сильно переработан. И sleep вообще нет. Так что новая сборка guile может помочь. Вот только получится ли?
(В ответ на комментарий №17) > (В ответ на комментарий №14) > > А в свежей guile 1.8.8 изменений тут нет? > > Оказалось, что string.c сильно переработан. И sleep вообще нет. Так что новая > сборка guile может помочь. Вот только получится ли? Только это оказалась не 1.8.8, а самая свежая версия.
Подумал было, что при локальном запуске вот этот кусок 352 if (STRINGBUF_SHARED (buf)) { ... } просто не выполняется. Ан нет: выполняется. И scm_i_thread_put_to_sleep тоже. Просто не виснет.
Вообще, как мне кажется, основополагающей следует считать проблему воспроизведения данной ошибки. У меня не получается вручную сделать систему, на которой она бы воспроизводилась: 1. после dist-upgrade проблемы не наблюдается (Сизиф); 2. после update-kernel -t std-def проблемы не наблюдается (3.5.7-std-def-alt1); 3. после установки всех модулей alterator-*, установленных на проблемной машине, проблема по прежнему не наблюдается. Ещё идеи?
(В ответ на комментарий №20) > Вообще, как мне кажется, основополагающей следует считать проблему > воспроизведения данной ошибки. У меня не получается вручную сделать систему, на > которой она бы воспроизводилась: У меня на машине не воспроизводится и не воспроизводилось и ранее (Сизиф). Воспроизводится в KVM на сборке дистрибутива на Сизифе конца сентября. Могу сделать там dist-upgrade до текущего Сизифа и проверить еще раз.
> У меня на машине не воспроизводится и не воспроизводилось и ранее (Сизиф). > Воспроизводится в KVM на сборке дистрибутива на Сизифе конца сентября. Могу > сделать там dist-upgrade до текущего Сизифа и проверить еще раз. У меня воспроизводится 100% при установке образов свежего кентавра в kvm.
(В ответ на комментарий №22) > У меня воспроизводится 100% при установке образов свежего кентавра в kvm. А кто-нибудь вообще видел этот баг не в kvm?
Баг проявился после установки systemd! Внимание вопрос: можем ли мы убрать из кода демонизацию, когда стартуем из-под systemd на готовом сокете? Тогда всё работает.
(In reply to comment #24) > Баг проявился после установки systemd! > > Внимание вопрос: можем ли мы убрать из кода демонизацию, когда стартуем из-под > systemd на готовом сокете? Тогда всё работает. При запуске средствами systemd вам не нужна демонизация.
(В ответ на комментарий №23) > А кто-нибудь вообще видел этот баг не в kvm? В Virtualbox новый Кентавр вообще не работает.
(В ответ на комментарий №24) > Баг проявился после установки systemd! У меня воспроизводится и без systemd (в kvm). > Внимание вопрос: можем ли мы убрать из кода демонизацию, когда стартуем из-под > systemd на готовом сокете? Тогда всё работает. Это, конечно, здорово, но у нас еще предполагается выпуск дистрибутивов без systemd. Так что разбираться все равно надо. (В ответ на комментарий №26) > > А кто-нибудь вообще видел этот баг не в kvm? > В Virtualbox новый Кентавр вообще не работает. Я в первую очередь имел в виду на реальном железе.
Прошу проверить отдельно на дистрибутиве с systemd и без оного: http://git.altlinux.org/tasks/84795
(В ответ на комментарий №28) > Прошу проверить отдельно на дистрибутиве с systemd и без оного: > > http://git.altlinux.org/tasks/84795 без systemd: [root@c212 ~]# service ahttpd start Starting ahttpd service: ERROR: no code for module (alterator systemd) [FAILED] [root@c212 ~]# ЖЖесть :D
А, точно, зависимость на новый alterator нужна. Спасибо. :)
(В ответ на комментарий №29) > (В ответ на комментарий №28) > > Прошу проверить отдельно на дистрибутиве с systemd и без оного: > > > > http://git.altlinux.org/tasks/84795 Надо добавить в alterator-fbi версионированную зависимость на alterator. без systemd в kvm: после обновления ahhtpd не поднялся, потом, после того, как я обновил alterator, поднялся и нормально заработал. После restart опять не работает. После stop; sleep 60;start по прежнему не работает, так что, видимо, дело тут не во времени, прошедшем между остановкой и запуском... service ahttpd stop service alteratord restart service ahttpd start Да это kvm, но это очень важная для нас тестовая платформа.
После переключения назад на SysV-init у мня, по прежнему, не воспроизводится. Предлагаю обменяться виртуалками.
alterator-fbi-5.28-alt1 -> sisyphus: * Thu Nov 22 2012 Paul Wolneykien <manowar@altlinux> 5.28-alt1 - Do not daemonize in socket-activation mode (closes: 27865). - Add the systemd unit files. - Start the server on the given socket if any (closes: 27987).
Спасибо!
Я не вижу чтобы что-то изменилось.
А я не могу воспроизвести при загрузке без systemd. В том же контейнере.
(В ответ на комментарий №32) > После переключения назад на SysV-init у мня, по прежнему, не воспроизводится. > Предлагаю обменяться виртуалками. c212 в офиссной сети.
Залёз ещё глубже. Как в общем-то и предполагалось, повисаем в ожидании семафора (некий heap_mutex). 1626 scm_i_pthread_mutex_lock (&t->heap_mutex); … pthread_mutex_lock (mutex=mutex@entry=0x7fb260000940) at forward.c:192 Полагаю, есть два реалистичных варианта решения: 1. попытаться разобраться в танцах с семафорами и, если это deadlock, придумать патч, его устраняющий; 2. детектить kvm и, если работаем под kvm и без systemd, использовать «костыль для убогих» — демонизацию в start-stop-daemon. Только в этом случае. В остальных же случаях всё и так работает (я прав?).
(In reply to comment #38) > Залёз ещё глубже. Как в общем-то и предполагалось, повисаем в ожидании > семафора (некий heap_mutex). > > 1626 scm_i_pthread_mutex_lock (&t->heap_mutex); > … > pthread_mutex_lock (mutex=mutex@entry=0x7fb260000940) at forward.c:192 > > Полагаю, есть два реалистичных варианта решения: > > 1. попытаться разобраться в танцах с семафорами и, если это deadlock, > придумать патч, его устраняющий; > > 2. детектить kvm и, если работаем под kvm и без systemd, использовать > «костыль для убогих» — демонизацию в start-stop-daemon. Только в этом случае. В > остальных же случаях всё и так работает (я прав?). Так как причин, почему такое происходит именно с kvm (да и только ли с kvm?) мы не нашли, то, полагаю, остается первый вариант. 2boyarsh: что думаете?
> Так как причин, почему такое происходит именно с kvm (да и только ли с kvm?) мы > не нашли, то, полагаю, остается первый вариант. > 2boyarsh: что думаете? Я думаю, что можно всегда использовать демонизацию в start-stop-daemon, раз она работает надёжно.
Этот путь труден тем, что явной баги в коде, скорее всего нет, поскольку в большинстве случаев он же работает. А значит всё равно в результате, скорее всего, будет костыль.
Мы с тобой синхронно отписались. :) Но я имел в виду правку кода, а не start-stop-daemon.
(In reply to comment #40) > > Так как причин, почему такое происходит именно с kvm (да и только ли с kvm?) мы > > не нашли, то, полагаю, остается первый вариант. > > 2boyarsh: что думаете? > Я думаю, что можно всегда использовать демонизацию в start-stop-daemon, раз она > работает надёжно. Ok.
А я нашёл разницу в выполнении кода между первым разом и последующим (после перезагрузки). Правда эта разница уже за пределами собственно guile, в pthreads.
Если пока не вдаваться в подробности, то мы имеем, видимо deadlock: кто-то держит семафор (mutex->__data.__nusers == 1). Логично предположить, что этот кто-то — это тень отца Гамлета ^W^W предыдущего запуска ahttpd. Внимание вопрос: а нет ли какого-нибудь приёма для опускания всех pthreads-семафоров, задействованных в программе и порождённых процессах? Мы бы тогда использовали его при перезагрузке ahhtpd (где-нить в exit-handler).
Чтобы дальше разбираться с этой багой, нужно понять одну принципиальную вещь: после остановки служб процесс guile18 в явном виде отсутствует (ps auxww | grep 'guile18' не находит ни одного экземпляра), как же тогда mutex->__data.__nusers == 1 ? Мне казалось, что раз mutex — это всё-таки переменная, то она должна исчезать вместе с освобождением памяти при завершении процесса. Это не так? Второй вариант, кончено, может быть таким, что при повторном запуске данный семафор явно устанавливается, но совсем из другого участка кода, а не из того, который я отлаживаю. Это я ещё не проверял.
(В ответ на комментарий №46) > Мне казалось, что раз mutex — это всё-таки переменная, то она должна > исчезать вместе с освобождением памяти при завершении процесса. Это не так? Теоретически mutex может быть размещён в разделяемой памяти, тогда в случае правильного использования pthread_mutexattr_setpshared() он может совместно использоваться несколькими процессами. Если же mutex размещается в обычной памяти, блокировать его некому, кроме потоков того процесса, в памяти которого находится mutex.
Спасибо за комментарий, Сергей. А что вы скажете на это? # service ahttpd restart # ps auxww | grep 'guile18' _ahttpd 8534 0.0 1.1 148932 6012 ? ts 18:03 0:00 /usr/bin/guile18 -s /usr/sbin/ahttpd # gdb /usr/bin/guile18 8534 … … (gdb) p t->heap_mutex $1 = {__data = {__lock = 1, __count = 0, __owner = 8533, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000U!\000\000\001", '\000' <repeats 26 times>, __align = 1} После перезагрузки ahttpd, heap_mutex уже оказывается занят. Но что особо интересно, занят он процессом с ID ровно на 1 меньшим, чем ahttpd. Я делаю вывод, что это — родительский процесс. Не предыдущий экземпляр ahttpd, а именно родитель, порождающий демона (как страшно звучит, однако…). Видимо этот родитель успевает зажать mutex, и не отпускает его. Почему этого не происходит при первичном запуске службы остаётся загадкой.
Собственно, workaround найден: # diff /usr/sbin/ahttpd{~,} 250c250,252 < (daemonize (config-ref *config* "server-pidfile"))) --- > (begin > (sleep 5) > (daemonize (config-ref *config* "server-pidfile")))) Т.е. если немного обождать перед отпачковыванием, то в порождаемом процессе mutex не будет занят, но будет свободен. Что это, в теории, значит?
Полагаю, что демонизация в нашей libvhttpd реализована криво, несовместимым с guile способом. Но у меня не хватает теоретических знаний, чтобы обосновать этот вывод и предложить качественное решение. Прошу помощи зала системного программирования. :)
(В ответ на комментарий №48) > # ps auxww | grep 'guile18' > _ahttpd 8534 0.0 1.1 148932 6012 ? ts 18:03 0:00 > /usr/bin/guile18 -s /usr/sbin/ahttpd Проверьте ещё на всякий случай вывод такой команды: ps axH -Olwp | grep 'guile18' (без опции H ps показывает только одну строку для процесса независимо от количества потоков в этом процессе). > После перезагрузки ahttpd, heap_mutex уже оказывается занят. Но что особо > интересно, занят он процессом с ID ровно на 1 меньшим, чем ahttpd. Я делаю > вывод, что это — родительский процесс. Не предыдущий экземпляр ahttpd, а именно > родитель, порождающий демона (как страшно звучит, однако…). Видимо этот > родитель успевает зажать mutex, и не отпускает его. Почему этого не происходит > при первичном запуске службы остаётся загадкой. Значит, демонизация реализована неправильно (выполняется fork() при захваченном mutex, в результате потомок не может освободить этот mutex, поскольку у потомка уже другой идентификатор). Вообще pthread и fork() очень плохо совмещаются в одном процессе (единственный относительно надёжно работающий вариант — если после fork() в порождённом процессе как можно быстрее делается execve() или _exit(); теоретически возможен объезд через pthread_atfork(), но реализовать его без ошибок очень сложно).
я смутно помню, что с демонизацией внутри guile были проблемы ещё несколько лет назад, выражались в пропаже локализации (кажется) на одной из x86 (i586 или x86_64), тогда же был найден ровно этот же workaround -- использовать s-s-d. Удивительно по прошествии нескольких лет видеть что-то подобное снова.
Похоже, демонизация из процесса, использующего guile, действительно не должна работать: http://lists.gnu.org/archive/html/guile-devel/2012-02/msg00062.html Если невозможность обнаружить ошибку инициализации при демонизации через start-stop-daemon настолько критична, можно сделать отдельную программу запуска на C, которая будет выполнять pipe(), fork()/exec*() и получать от основного процесса результат его инициализации через pipe; при этом в процессе сервера по-прежнему могут выполняться все действия по созданию pid-файла, переназначению stdin/out/err после инициализации и т.д., кроме fork().
Резюмирую: - демонизация средствами guile, собранным с поддержкой threads, нормально работать не будет, скорее всего, никогда; - в systemd демонизация не нужна в принципе, имеющийся ahttpd.service реализует service type simple; - в sysvinit остается применить костыль для убогих от s-s-d (start_daemon --make-pidfile, который вызывает start-stop-daemon --background --make-pidfile).
Дал права на пакет manowar@
alterator-fbi-5.28-alt3 -> sisyphus: * Wed Nov 28 2012 Paul Wolneykien <manowar@altlinux> 5.28-alt3 - Use "a wretched-man's crutch" daemonization: start-stop-daemon for SysV-init (closes: 27865).
