27865 2012-10-17 11:30:16 +0400 ahttpd не работает после рестарта 2012-11-28 11:03:58 +0400 1 1 4 Development Sisyphus alterator-fbi unstable all Linux CLOSED FIXED P3 normal --- 27685 27987 1 boyarsh manowar aen cas imz ldv manowar mike nbr sbolshakov sem vsu qa-sisyphus oldest_to_newest 134005 0 boyarsh 2012-10-17 11:30:16 +0400 Работает после установки только если ещё раз перезагрузиться, до этого отдаёт ssl сертификат и перестаёт отвечать на запросы. 134118 1 boyarsh 2012-10-19 14:31:18 +0400 В реальности он не работает также если выполнить service ahttpd restart Но работает если запустить ahttp -l (то есть без демонизации) Чудеса. 134123 2 sem 2012-10-19 16:49:49 +0400 Проблема где-то в районе ф-ции message-handler. Но что там происходит, почему влияет демонизация и почему все работает до service ahttpd restart - я не понимаю :(. 134124 3 sem 2012-10-19 16:52:49 +0400 Точнее в response-handler при вызове with-ahttpd-session, похоже. 134205 4 manowar 2012-10-25 23:51:08 +0400 Будем посмотреть… 134260 5 manowar 2012-10-29 03:40:56 +0400 Посмотрел. Там всё очень неважно: на первый взгляд кажется, что дело в самом guile. Например, после `service ahttpd restart` не работает вызов string-downcase (управление оттуда не возвращается), хотя она, извините, primitive-proc. Далее, let-values обрабатывается нормально, а let*-values — подвисает, не вычисляя ни один из своих аргументов. Однако эта гипотеза, скорее всего не верна, или не совсем верна, потому как даже в 5.1 версия guile у нас всё та же — 1.8.7, отличаются только alt-релизы. Выходит, проблема ещё глубже? Самое ужасное, что на моей системе после dist-upgrade проблема не воспроизводится. 134261 6 aen 2012-10-29 04:08:49 +0400 (В ответ на комментарий №5) > Самое ужасное, что на моей системе после dist-upgrade проблема не > воспроизводится. А что обновилось? 134262 7 5612 manowar 2012-10-29 04:34:48 +0400 Created attachment 5612 Запуск ahttpd с демонизацией через start-stop-daemon 134263 8 manowar 2012-10-29 04:35:35 +0400 Точно не знаю, что обновилось, но предлагаю подойти к проблеме немного с другой стороны. Перед тем, как увидел «что же там внутри», я был уверен, что дело в каком-нибудь файле, который не удаляется при перезапуске ahttpd. Но в явном виде проблем с файлами обнаружено не было. Что же получается? При первом после перезагрузки системы запуске, программа работает как положено, а при повторном подвисает в совершенно неожиданных местах. В связи с этим, предлагаю поймать первого пробегающего мимо архитектора Linux-систем и спросить у него, где может накапливаться разница между первым и вторым запуском демона. Именно демона, т.к. повторный запуск в foreground функционирует нормально. А пока никто мимо не пробежал и на вопрос не ответил, то, как оказалось, проблему можно обойти отказавшись от штатной демонизации, и положившись на start-stop-deamon (патч прилагается). В связи с этим, кстати, можно заключить, что guile «башню сносит» именно где-то в районе deamonize, которая определена где-то в недрах libguile-vhttpd… 134264 9 ldv 2012-10-29 05:01:13 +0400 (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 не видно. 134268 10 manowar 2012-10-29 13:00:51 +0400 (В ответ на комментарий №9) > (In reply to comment #8) > Возможно, демон не убивается до конца, Процесса нет, я проверял. > или оставляет за собой файлы, влияющие на демонизацию. Вроде нет таких. > Возможно, демонизация просто кривая, и работает только один раз. Она работает, но сам демон начинает глючить. И, возвращаясь к исходному вопросу, как можно сделать «один раз» не используя файлы? Т.е. откуда она может знать, что данный раз — не первый? :) 134270 11 mike 2012-10-29 13:14:34 +0400 Припоминаются болтающиеся сегменты shm и IIRC семафоры; см. тж. http://lists.altlinux.org/pipermail/devel/2003-August/095235.html http://lists.altlinux.org/pipermail/community/2001-August/440930.html 134274 12 ldv 2012-10-29 14:47:19 +0400 (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). 134296 13 manowar 2012-10-30 01:04:53 +0400 Решил углубиться ещё дальше. 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. Обычно ведь блокировка кратковременна. 134297 14 aen 2012-10-30 01:08:16 +0400 А в свежей guile 1.8.8 изменений тут нет? 134298 15 manowar 2012-10-30 01:13:19 +0400 (В ответ на комментарий №14) > А в свежей guile 1.8.8 изменений тут нет? Сейчас посмотрим. Но вряд ли дело в том, что этот кусок безусловно кривой. Скорее, некоторое внешнее по отношению к guileПотому что: 1. она давно (по крайней мере с 5.1) уже не обновлялась и всё работало; 2. после dist-upgrade cert6 → Sisyphus всё продолжает работать (у меня). Т.е. мы имеем дело с чем-то, что делает работу guile нестабильной. Что это за обстоятельства — непонятно. 134299 16 manowar 2012-10-30 01:15:19 +0400 (В ответ на комментарий №14) > А в свежей guile 1.8.8 изменений тут нет? Сейчас посмотрим. Но вряд ли дело в том, что этот кусок безусловно кривой. Скорее, некоторое внешнее по отношению к guile обстоятельство делает её работу нестабильной. Потому что: 1. она давно (по крайней мере с 5.1) уже не обновлялась и всё работало; 2. после dist-upgrade cert6 → Sisyphus всё продолжает работать (у меня); 3. при запуске из консоли всё работает; 4. с демонизацией через start-stop-daemon всё работает. Что это за обстоятельство? В том-то и вопрос… 134300 17 manowar 2012-10-30 01:23:32 +0400 (В ответ на комментарий №14) > А в свежей guile 1.8.8 изменений тут нет? Оказалось, что string.c сильно переработан. И sleep вообще нет. Так что новая сборка guile может помочь. Вот только получится ли? 134301 18 manowar 2012-10-30 01:29:45 +0400 (В ответ на комментарий №17) > (В ответ на комментарий №14) > > А в свежей guile 1.8.8 изменений тут нет? > > Оказалось, что string.c сильно переработан. И sleep вообще нет. Так что новая > сборка guile может помочь. Вот только получится ли? Только это оказалась не 1.8.8, а самая свежая версия. 134302 19 manowar 2012-10-30 01:37:55 +0400 Подумал было, что при локальном запуске вот этот кусок 352 if (STRINGBUF_SHARED (buf)) { ... } просто не выполняется. Ан нет: выполняется. И scm_i_thread_put_to_sleep тоже. Просто не виснет. 134304 20 manowar 2012-10-30 03:39:11 +0400 Вообще, как мне кажется, основополагающей следует считать проблему воспроизведения данной ошибки. У меня не получается вручную сделать систему, на которой она бы воспроизводилась: 1. после dist-upgrade проблемы не наблюдается (Сизиф); 2. после update-kernel -t std-def проблемы не наблюдается (3.5.7-std-def-alt1); 3. после установки всех модулей alterator-*, установленных на проблемной машине, проблема по прежнему не наблюдается. Ещё идеи? 134327 21 sem 2012-10-30 21:35:05 +0400 (В ответ на комментарий №20) > Вообще, как мне кажется, основополагающей следует считать проблему > воспроизведения данной ошибки. У меня не получается вручную сделать систему, на > которой она бы воспроизводилась: У меня на машине не воспроизводится и не воспроизводилось и ранее (Сизиф). Воспроизводится в KVM на сборке дистрибутива на Сизифе конца сентября. Могу сделать там dist-upgrade до текущего Сизифа и проверить еще раз. 135106 22 boyarsh 2012-11-21 14:28:53 +0400 > У меня на машине не воспроизводится и не воспроизводилось и ранее (Сизиф). > Воспроизводится в KVM на сборке дистрибутива на Сизифе конца сентября. Могу > сделать там dist-upgrade до текущего Сизифа и проверить еще раз. У меня воспроизводится 100% при установке образов свежего кентавра в kvm. 135165 23 sem 2012-11-21 16:00:17 +0400 (В ответ на комментарий №22) > У меня воспроизводится 100% при установке образов свежего кентавра в kvm. А кто-нибудь вообще видел этот баг не в kvm? 135210 24 manowar 2012-11-21 16:24:27 +0400 Баг проявился после установки systemd! Внимание вопрос: можем ли мы убрать из кода демонизацию, когда стартуем из-под systemd на готовом сокете? Тогда всё работает. 135213 25 ldv 2012-11-21 16:26:45 +0400 (In reply to comment #24) > Баг проявился после установки systemd! > > Внимание вопрос: можем ли мы убрать из кода демонизацию, когда стартуем из-под > systemd на готовом сокете? Тогда всё работает. При запуске средствами systemd вам не нужна демонизация. 135217 26 cas 2012-11-21 16:39:08 +0400 (В ответ на комментарий №23) > А кто-нибудь вообще видел этот баг не в kvm? В Virtualbox новый Кентавр вообще не работает. 135224 27 sem 2012-11-21 17:14:07 +0400 (В ответ на комментарий №24) > Баг проявился после установки systemd! У меня воспроизводится и без systemd (в kvm). > Внимание вопрос: можем ли мы убрать из кода демонизацию, когда стартуем из-под > systemd на готовом сокете? Тогда всё работает. Это, конечно, здорово, но у нас еще предполагается выпуск дистрибутивов без systemd. Так что разбираться все равно надо. (В ответ на комментарий №26) > > А кто-нибудь вообще видел этот баг не в kvm? > В Virtualbox новый Кентавр вообще не работает. Я в первую очередь имел в виду на реальном железе. 135287 28 manowar 2012-11-22 15:43:32 +0400 Прошу проверить отдельно на дистрибутиве с systemd и без оного: http://git.altlinux.org/tasks/84795 135298 29 boyarsh 2012-11-22 16:55:55 +0400 (В ответ на комментарий №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 135299 30 manowar 2012-11-22 17:00:59 +0400 А, точно, зависимость на новый alterator нужна. Спасибо. :) 135301 31 boyarsh 2012-11-22 17:04:09 +0400 (В ответ на комментарий №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, но это очень важная для нас тестовая платформа. 135306 32 manowar 2012-11-22 17:39:48 +0400 После переключения назад на SysV-init у мня, по прежнему, не воспроизводится. Предлагаю обменяться виртуалками. 135309 33 repository-robot 2012-11-22 18:36:45 +0400 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). 135311 34 aen 2012-11-22 18:45:45 +0400 Спасибо! 135314 35 sem 2012-11-22 19:43:09 +0400 Я не вижу чтобы что-то изменилось. 135316 36 manowar 2012-11-22 19:44:30 +0400 А я не могу воспроизвести при загрузке без systemd. В том же контейнере. 135352 37 boyarsh 2012-11-23 13:54:06 +0400 (В ответ на комментарий №32) > После переключения назад на SysV-init у мня, по прежнему, не воспроизводится. > Предлагаю обменяться виртуалками. c212 в офиссной сети. 135416 38 manowar 2012-11-25 23:51:12 +0400 Залёз ещё глубже. Как в общем-то и предполагалось, повисаем в ожидании семафора (некий 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. Только в этом случае. В остальных же случаях всё и так работает (я прав?). 135417 39 aen 2012-11-26 03:12:38 +0400 (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: что думаете? 135427 40 boyarsh 2012-11-26 14:15:13 +0400 > Так как причин, почему такое происходит именно с kvm (да и только ли с kvm?) мы > не нашли, то, полагаю, остается первый вариант. > 2boyarsh: что думаете? Я думаю, что можно всегда использовать демонизацию в start-stop-daemon, раз она работает надёжно. 135428 41 manowar 2012-11-26 14:17:22 +0400 Этот путь труден тем, что явной баги в коде, скорее всего нет, поскольку в большинстве случаев он же работает. А значит всё равно в результате, скорее всего, будет костыль. 135429 42 manowar 2012-11-26 14:18:18 +0400 Мы с тобой синхронно отписались. :) Но я имел в виду правку кода, а не start-stop-daemon. 135432 43 aen 2012-11-26 14:27:08 +0400 (In reply to comment #40) > > Так как причин, почему такое происходит именно с kvm (да и только ли с kvm?) мы > > не нашли, то, полагаю, остается первый вариант. > > 2boyarsh: что думаете? > Я думаю, что можно всегда использовать демонизацию в start-stop-daemon, раз она > работает надёжно. Ok. 135437 44 manowar 2012-11-26 14:33:45 +0400 А я нашёл разницу в выполнении кода между первым разом и последующим (после перезагрузки). Правда эта разница уже за пределами собственно guile, в pthreads. 135443 45 manowar 2012-11-26 15:09:32 +0400 Если пока не вдаваться в подробности, то мы имеем, видимо deadlock: кто-то держит семафор (mutex->__data.__nusers == 1). Логично предположить, что этот кто-то — это тень отца Гамлета ^W^W предыдущего запуска ahttpd. Внимание вопрос: а нет ли какого-нибудь приёма для опускания всех pthreads-семафоров, задействованных в программе и порождённых процессах? Мы бы тогда использовали его при перезагрузке ahhtpd (где-нить в exit-handler). 135449 46 manowar 2012-11-26 15:54:02 +0400 Чтобы дальше разбираться с этой багой, нужно понять одну принципиальную вещь: после остановки служб процесс guile18 в явном виде отсутствует (ps auxww | grep 'guile18' не находит ни одного экземпляра), как же тогда mutex->__data.__nusers == 1 ? Мне казалось, что раз mutex — это всё-таки переменная, то она должна исчезать вместе с освобождением памяти при завершении процесса. Это не так? Второй вариант, кончено, может быть таким, что при повторном запуске данный семафор явно устанавливается, но совсем из другого участка кода, а не из того, который я отлаживаю. Это я ещё не проверял. 135451 47 vsu 2012-11-26 17:33:10 +0400 (В ответ на комментарий №46) > Мне казалось, что раз mutex — это всё-таки переменная, то она должна > исчезать вместе с освобождением памяти при завершении процесса. Это не так? Теоретически mutex может быть размещён в разделяемой памяти, тогда в случае правильного использования pthread_mutexattr_setpshared() он может совместно использоваться несколькими процессами. Если же mutex размещается в обычной памяти, блокировать его некому, кроме потоков того процесса, в памяти которого находится mutex. 135452 48 manowar 2012-11-26 18:19:24 +0400 Спасибо за комментарий, Сергей. А что вы скажете на это? # 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, и не отпускает его. Почему этого не происходит при первичном запуске службы остаётся загадкой. 135453 49 manowar 2012-11-26 18:55:22 +0400 Собственно, workaround найден: # diff /usr/sbin/ahttpd{~,} 250c250,252 < (daemonize (config-ref *config* "server-pidfile"))) --- > (begin > (sleep 5) > (daemonize (config-ref *config* "server-pidfile")))) Т.е. если немного обождать перед отпачковыванием, то в порождаемом процессе mutex не будет занят, но будет свободен. Что это, в теории, значит? 135454 50 manowar 2012-11-26 19:01:57 +0400 Полагаю, что демонизация в нашей libvhttpd реализована криво, несовместимым с guile способом. Но у меня не хватает теоретических знаний, чтобы обосновать этот вывод и предложить качественное решение. Прошу помощи зала системного программирования. :) 135457 51 vsu 2012-11-26 19:53:09 +0400 (В ответ на комментарий №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(), но реализовать его без ошибок очень сложно). 135461 52 sbolshakov 2012-11-26 21:06:18 +0400 я смутно помню, что с демонизацией внутри guile были проблемы ещё несколько лет назад, выражались в пропаже локализации (кажется) на одной из x86 (i586 или x86_64), тогда же был найден ровно этот же workaround -- использовать s-s-d. Удивительно по прошествии нескольких лет видеть что-то подобное снова. 135465 53 vsu 2012-11-27 00:10:39 +0400 Похоже, демонизация из процесса, использующего 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(). 135468 54 ldv 2012-11-27 03:58:00 +0400 Резюмирую: - демонизация средствами guile, собранным с поддержкой threads, нормально работать не будет, скорее всего, никогда; - в systemd демонизация не нужна в принципе, имеющийся ahttpd.service реализует service type simple; - в sysvinit остается применить костыль для убогих от s-s-d (start_daemon --make-pidfile, который вызывает start-stop-daemon --background --make-pidfile). 135520 55 boyarsh 2012-11-28 10:09:08 +0400 Дал права на пакет manowar@ 135523 56 repository-robot 2012-11-28 11:03:58 +0400 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). 5612 2012-10-29 04:34:48 +0400 2012-10-29 04:34:48 +0400 Запуск ahttpd с демонизацией через start-stop-daemon no-daemonize.patch text/plain 1135 manowar ZGlmZiAtLWdpdCBhL2FsdGVyYXRvci1mYmkvYWh0dHBkLmluaXQgYi9hbHRlcmF0b3ItZmJpL2Fo dHRwZC5pbml0CmluZGV4IGZhYjM1NzIuLjc4YzlmMTkgMTAwNzU1Ci0tLSBhL2FsdGVyYXRvci1m YmkvYWh0dHBkLmluaXQKKysrIGIvYWx0ZXJhdG9yLWZiaS9haHR0cGQuaW5pdApAQCAtMzIsNyAr MzIsNyBAQCBzdGFydCgpCiB7CiAJc3NsX2dlbmVyYXRlICJhaHR0cGQiCiAKLQlzdGFydF9kYWVt b24gLS1waWRmaWxlICIkUElERklMRSIgLS1sb2NrZmlsZSAiJExPQ0tGSUxFIiAtLWV4cGVjdC11 c2VyIF9haHR0cGQgLS1uYW1lIGFodHRwZCAtLWRpc3BsYXluYW1lIGFodHRwZCAtLSBhaHR0cGQK KwlzdGFydF9kYWVtb24gLS1iYWNrZ3JvdW5kIC0tcGlkZmlsZSAiJFBJREZJTEUiIC0tbWFrZS1w aWRmaWxlIC0tbG9ja2ZpbGUgIiRMT0NLRklMRSIgLS1leHBlY3QtdXNlciBfYWh0dHBkIC0tbmFt ZSBhaHR0cGQgLS1kaXNwbGF5bmFtZSBhaHR0cGQgLS0gYWh0dHBkCiAJUkVUVkFMPSQ/CiAKIAlb ICIkUkVUVkFMIiAhPSAiMCIgXSB8fCBwdWJsaXNoX3NlcnZpY2UgYWh0dHBkICdTeXN0ZW0gbWFu YWdlbWVudCBjZW50ZXIgYXQgJWgnICdfaHR0cHMuX3RjcCcgIiQoYWh0dHBkX3BvcnQpIgpkaWZm IC0tZ2l0IGEvYWx0ZXJhdG9yLWZiaS9zYmluL2FodHRwZCBiL2FsdGVyYXRvci1mYmkvc2Jpbi9h aHR0cGQKaW5kZXggMWM2NTE3Mi4uZTIwMTM0MSAxMDA3NTUKLS0tIGEvYWx0ZXJhdG9yLWZiaS9z YmluL2FodHRwZAorKysgYi9hbHRlcmF0b3ItZmJpL3NiaW4vYWh0dHBkCkBAIC0yMzEsNyArMjMx LDcgQEAKICAgICAoYmVnaW4gKGFsdGVyYXRvci1pbml0LWxvY2FsKQogICAgICAgICAgICAoZC1p bml0LWxvY2FsKSkKICAgICAoYmVnaW4gKGFsdGVyYXRvci1pbml0LWdsb2JhbCkKLSAgICAgICAg ICAgKGRhZW1vbml6ZSAoY29uZmlnLXJlZiAqY29uZmlnKiAic2VydmVyLXBpZGZpbGUiKSkKKzsg ICAgICAgICAgIChkYWVtb25pemUgKGNvbmZpZy1yZWYgKmNvbmZpZyogInNlcnZlci1waWRmaWxl IikpCiAJICAgKGRyb3AtcHJpdnMgKGNvbmZpZy1yZWYgKmNvbmZpZyogInNlcnZlci11c2VyIikK IAkJICAgICAgIChjb25maWctcmVmICpjb25maWcqICJzZXJ2ZXItZ3JvdXAiKSkpKQogCg==