ISC_kill: error 2 starting gds_relay /opt/firebird//bin/gds_

[Somebody2]

Времени нет разобраться, поэтому если кому не трудно, поясните,
плиз:

FB 1.5 класик, version LI-V1.5.0.4290 Firebird 1.5, OS Linux Debian 3.0

В один момент времени в логах промелькнула запись:
ISC_kill: error 2 starting gds_relay /opt/firebird//bin/gds_relay

После этого, при попытке обращения к одной таблице базы с любого
клиента происходило зависание - (на сервер слался запрос select *
from table, а в ответ тишина, ждал до 30 минут). За пять часов до
появления указанной записи, произошел сбой питания. Помогла только
полная перезагрузка компа.

Е мое, что это было то?

[dimitr]

Если ось сливает при попытке сервера послать сигнал процессу (обычно классик), то иногда код сервера пытается использовать для этой цели процесс gds_relay, который является раритетом для старых ОС и в современных дистрибутах уже не поставляется. Результаты такого чудачества сервера предсказать не берусь, возможно и зависание.

По хорошему, надо просто возвращать системную ошибку и обрабатывать ее выше, а непохороненные останки этого раритета таки упокоить на веки вечные. В FB2 должно быть исправлено.

[Somebody2]

Если ось сливает при попытке сервера послать сигнал процессу (обычно классик), то иногда код сервера пытается использовать для этой цели процесс gds_relay, который является раритетом для старых ОС и в современных дистрибутах уже не поставляется. Результаты такого чудачества сервера предсказать не берусь, возможно и зависание.

По хорошему, надо просто возвращать системную ошибку и обрабатывать ее выше, а непохороненные останки этого раритета таки упокоить на веки вечные. В FB2 должно быть исправлено.

Спасибо за ответ. Жаль только ясности в данном вопросе по-прежнему мало

Почему доступ ко всем остальным таблицам был нормальный и только при обращении к одной происходило "зависание" клиента, почему помогла только перезагрузка всего компа. Самое прикольное, что нагрузка на эту базу в последнее время уменьшилась раз этак в 20, а до этого она работала больше года, периодически подвергаясь всяким издевательствам (первый бэкап/ресторе я сделал только после указанного инцидента ) и при этом не было ни одного сбоя.

[Somebody2]

Ситуация повторилась - опять сбой питания. В
этот раз проблема немного другая - висло при
попытке инсерта в другую таблицу. Но я обратил
внимание, что и в этот и в прошлой раз
проблемы начинались именно в тот момент, когда
через gfix делался sweep базы.

То есть ситуация: сбой питания, после загрузки
все работает внешне нормально до тех пор, пока
не запустится gfix -sweep. Проблему можно
решить, прибив этот gfix - видимо поэтому в
прошлый раз помогла перезагрузка, хотя можно
было обойтись и без нее

Кто-нибудь может прокоментировать? В принципе
есть мысли на этот счет, но хотелось бы услышать
чье-либо авторитеное мнение

[dimitr]

В логе опять есть запись про gds_relay? Решение простое - найти этот бинарник (из ранних дистрибутивов IB, например) и подсунуть в /bin серверу. В FB2 эта проблема будет устранена как класс.

[Somebody2]

В логе опять есть запись про gds_relay? Решение простое - найти этот бинарник (из ранних дистрибутивов IB, например) и подсунуть в /bin серверу. В FB2 эта проблема будет устранена как класс.

Есть такая запись
И появилась как раз в момент запуска gfix (gfix запускается через cron, поэтому известно точное время запуска)

А не можешь объяснить, почему эта запись появляется только после аварийного завершения работы сервера и почему все время разные эффекты - первый раз select, во второй раз insert, а select работал нормально, ну и еще раз повторюсь, что если прибить gfix, то все начинает работать нормально, в том числе и следующий вызов gfix

[dimitr]

Если бы знал точно - давно бы объяснил

[Somebody2]

Если бы знал точно - давно бы объяснил

Ну да и фиг с ним - примерные методы борьбы с данным злом мне уже известны

Спасибо за ответы