29.03.2013 00:48, Eugene Berdnikov пишет: > On Thu, Mar 28, 2013 at 09:40:41PM +0400, "Артём Н." wrote: >> 26.03.2013 18:42, Andrey Melnikoff пишет: >>> "Артём Н." <artio...@yandex.ru> wrote: >>>> 19.03.2013 21:09, Andrey Melnikoff пишет: >>> >>> [skipp] >>> >>>> Но насчёт Zabbix, не соглашусь. Его 1998-го года пилят. И, вроде, далеко не >>>> самая плохая система. >>> Ага, его обмазывают затычками. После "скандалы-интриги-расследования" >>> (http://blog.zabbix.com/mysterious-zabbix-problems-how-we-debug-them/1023/) >>> тем кто в теме становиться совсем смешно. >> "You could say: localtime() is not a reentrant function. Right. But why does >> it >> hang ? >> Let???s look into libc source code. On our Debian GNU/Linux 6.0 machine the >> interesting part is in eglibc-2.11.3/time/localtime.c" >> >> И что тут смешного? Со всеми бывает. >> Насколько я понял, вызванный в обработчике сигнала localtime(), ожидает >> снятия >> блокировки прерванного localtime(). >> Типичный deadlock, связанный с устаревшей архитектурой libc, которая не была >> рассчитана на многопоточность, а разработчики предпочитали отделываться >> добавлением костылей. >> >> Да, конечно тут есть и ошибка разработчиков Zabbix. Но что смешного, >> объясните? >> Я не в теме. > > Да, совершенно не в теме. :) Вы даже не прочли внимательно этот триллер, > а ведь его авторы, хоть и чайники в сигналах, всё-таки отличают проблемы > многопоточности и синхронизации от проблем обработки прерываний. Oни там > пишут, что замена localtime() на localtime_r() не поможет, и это верно: > в обработчике сигнала бесполезно ждать снятия блокировки, если блокировка > наложена вне контекста прерывания. В тот контекст можно лишь вернуться, > дождаться же невозможно. Sorry. Перечитал. "But Zabbix on UNIX/Linux is not multithreaded. It is multi-process. The process hang occurs when a process execution flow is interrupted by it’s own signal handler and the localtime() is used in both at the same time. So, replacing localtime() with localtime_r() will not solve the problem."
> Что предлагают авторы в качестве лечения -- кому смешно, а кому грустно... > Они героически придумывают как уменьшить вероятность дедлока, вместо того, > чтобы устранить его вообще. Но... У них же есть "The right solution". :-) Только, "Unfortunately, the list of asynchronous-signal-safe functions does not include many popular functions, even printf() is not safe. Obviously, localtime() is not in the list either." > Похоже, их не посетила мысль, что в обработчике > недопустимо что-либо логгировать и приступать к сворачиванию работы -- ведь > какая-то операция была прервана, сперва нужно её завершить. Иначе нет > гарантии, что не будут повреждены какие-то недописанные данные. Попытка > позвать логгер из обработчика может разнести всё к чёртовой матери, а может > вызвать повисание... например, из-за неявного вызова того же localtime(). Но они пишут про то, что обработчик большой и переписывать долго... К тому же, что делать, если *надо* логгировать? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51581080.7080...@yandex.ru