FB 1.5 CS под Linux.
Подскажите, как классик реагирует на его убийство сигналом TERM?
т.е. можно ли делать так: kill <fb-pid> или killall fb_inet_server?
Корректно ли завершать клиентский процесс таким образом? Не может ли это вызвать повреждения базы?
спасибо.
можно ли убивать сервер, и как это делвать правильно...
Модераторы: kdv, Alexey Kovyazin
имел ввиду процесс сервера, обслуживающий конкретный клиентский коннект.Насколько я знаю, обычно приложения в юникс совершенно нормально относятся к их завершению сигналом 15 (TERM). При этом большинство из них завершают работу абсолютно корректно (в отличие например от убиства 9-м сигналом). Т.е. TERM обычно воспринимается как: "доделать недоделанное и завершить работу". Так что и FB может к примеру дособирать мусор (если действительно этот процесс нельзя останавливать посередине) и завершиться...kdv писал(а):в общем случае - нет. клиентский процесс, а тем более супер, может в это время заниматься записью данных на диск, а еще хуже - сборкой мусора.
Чаще всего можно найти (в тех же man) как приложение реагирует на тот или иной сигнал.
В доке firebird ничего не нашел по этому поводу, так что остаётся только догадываться
С FB на боевой базе даже не пытаюсь, на девелоперских проблем пока не было, но там и нагрузка и замусоренность близка к нулю. А вот с IB4 имел из-за этого повреждения базы в среднем раз в 8 месяцев. Под этим антиквариатом у меня бакапы были нересторабельны и ночной крон вырубал забывших запущенную задачу пользователей и осуществлял файловое копирование.jake писал(а): Насколько я знаю, обычно приложения в юникс совершенно нормально относятся к их завершению сигналом 15 (TERM).
Спасибо. понятно.dimitr писал(а):Сервер не содержит обработчика SIGTERM, поэтому случиться может все, что угодно.
Как тогда правильно остановить все процессы классика? Ведь остановка xinetd (/etc/init.d/xinetd stop) не завершает уже запущенные fb_inet_server...
/opt/firebird/bin/gfix -shut -force 0 <my_db>
так правильно?
что произойдет в случае такого шатдауна с процессом, занятым сборкой мусора?
Мне просто нужно корректно и без вопросов остановить классик.
Не считаете ли вы, что такой обработчик необходим?dimitr писал(а):Сервер не содержит обработчика SIGTERM, поэтому случиться может все, что угодно.
Допустим я завершаю работу сервера (init 0, poweroff, как угодно). Получается так, что работающие процессы классика никто корректно не остановит, и они будут именно убиты и, "случиться может всё, что угодно".
Вот что я нашел в скриптах своей системы (/etc/init.d/halt):
Код: Выделить всё
action "Sending all processes the TERM signal..." /sbin/killall5 -15
sleep 5
action "Sending all processes the KILL signal..." /sbin/killall5 -9
Т.е. даже в случае корректного завершения работы системы, база может оказаться поврежденной
Я так понимаю, либо надо обработчик этот в самом сервере , либо в классике тоже делать скрипт /etc/init.d/firebird, который по stop будет делать что-то вроде gfix -shut ? либо и то и другое вместе?
спасибо.
Да. Полный шатдаун и после его завершения отстрел всех процессов классика. Сборка мусора будет остановлена шатдауном.jake писал(а):Как тогда правильно остановить все процессы классика? Ведь остановка xinetd (/etc/init.d/xinetd stop) не завершает уже запущенные fb_inet_server...
/opt/firebird/bin/gfix -shut -force 0 <my_db>
так правильно?
Считаю, что необходим. Но больше для порядка/удобства, чем для целостности базы. Ибо она никогда не должна портиться при убитии сервера. То, что сейчас изредка наблюдается, я считаю багом, который рано или поздно будет изничтожен.jake писал(а):Не считаете ли вы, что такой обработчик необходим?
Допустим я завершаю работу сервера (init 0, poweroff, как угодно). Получается так, что работающие процессы классика никто корректно не остановит, и они будут именно убиты и, "случиться может всё, что угодно".