Re: Виртуализация
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 пишет:
>>> "Артём Н." <artiom14@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().
Но они пишут про то, что обработчик большой и переписывать долго...
К тому же, что делать, если *надо* логгировать?
Reply to: