Что происходит при использовании команды KILL -9?

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

Немного уточнений по генерируемому сигналу. Progress ожидает, что будет послан сигнал -1, когда клиентский сеанс отправит hang-up - сигнал, таким образом будет выполнена чистка всех процессов клиентского сеанса, после чего пользователь будет корректно отключен от базы данных. Когда же мы получаем сигнал KILL -9, у нас нет возможности отследить клиентский сеанс. Получение KILL -9 во время выполнения процедуры завершения, может привести к катастрофическим последствиям. Например, в случае если клиентскому сеансу был бы отправлен этот сигнал, когда он удерживал логин-семафор. Это бы привело к смерти пользователя, но при этом семафор не был бы освобожден, а это приведет к тому, что ни кто больше не сможет зайти или выйти из базы данных. Более мрачные последствия могут возникнуть если бы пользователь был уничтожен сигналом прежде, чем процедура завершения достигла шаг 6 Отключение от разделяемой памяти. Если это произойдет, и клиентская сессия будет удерживать замок (latch) в разделяемой памяти, то база данных упадет. 

Почему же база данных падает, когда пользователь умирает удерживая замок в разделяемой памяти?

Когда пользователь соединяется с базой данных Progress в многопользовательском режиме, пользовательская таблица управления в разделяемой памяти обновляется, чтобы добавить пользователя. 

Процесс watchdog, или брокер (если watchdog не запущен), периодически выполняет проверку, что у всех пользователей, перечисленных в пользовательской таблице управления, есть соответствующие выполняемые процессы. Если watchdog или брокер решат, что у пользователя из пользовательской таблицы управления, нет активного процесса, его отключают от базы данных и в лог базы данных записывается сообщение Disconnecting dead user (2527). Если процесс пользователя был завершен неправильно, удерживая замки (latches) или блокировки (locks) в разделяемой памяти, в лог базы данных будут записаны сообщения, приведенные ниже: 

User died holding shared memory locks. (2522)

User died with buffers locked. (2523)

Если разделяемую память или буферные замки (latches) останутся в неопределенном состоянии, то брокер остановит базу данных, чтобы обеспечить целостность данных. В лог базы данных будет записано сообщение с номером (2249), которым будут сопровождаться все выходящие из системы пользователи и само завершение работы сервера. Например: 

Begin ABNORMAL shutdown code x (2249).

В настоящее врем, номер кода (code x) в сообщении зарезервирован, и не имеет никакого значения. То что работа базы завершена, не указывает на нарушение целостности данных, это необходимо чтобы предотвратить возможные искажения. После перезапуска базы данных, отработает механизм восстановления crash recovery, и база снова будет доступна для нормальной работы. 

В дополнение к вышеупомянутым сообщениям, в лог базы может быть записано сообщение System Error: redundant lwake user <n> latch <x>, это нормально, поскольку выполняется аварийное завершение работы и все пользователи выходят из системы. Эта ошибка также не указывает на искажение базы данных. 

События, которые заставляют процесс завершаться неправильно, следующие: 

1. Отправка процессу kill – сигнала, кроме сигнала SIGHUP.
2. Отключение терминала, в то время когда сеанс Progress активен. Если терминал пошлет SIGHUP когда сеанс не активен, то проблем не будет.
3. Процесс, прерывается в результате системной ошибки.

Чтобы использовать больше сигналов, их обработка в PROGRESS была улучшена^[1] . Если эти ошибки происходят неоднократно, важно определить, что заставляет пользовательский процесс умирать. 

Там, где это часто происходит, способ предотвратить аварийное завершение состоит в том, чтобы запускать пользователей как удаленных клиентов (remote clients). Такие пользователи не обращаются на прямую к разделяемой памяти. Вместо этого клиент соединяется с процессом сервера, который и обращается к ней. Этот процесс сам получит доступ к разделяемой памяти и к замкам буфера (buffer latches) для пользовательского процесса. Если пользовательский процесс будет неправильно завершен, то процесс сервера все еще будет работать и сможет очистить любые оставшиеся замки (latches). 

Примеры

Запуск сервера с сетевыми параметрами: 

proserve db-name -S <portnumber> -H <host name> 

Запуск пользовательского сеанса как локального remote-клиента на той же самой машине: 

mpro db-name -S <port number> -H <host name> 

Примечание: могут возникнуть различия в производительности между прямым подключениями к разделяемой памяти и подключением по TCP. Разделяемая память обычно быстрее, так как она не работает через протокол TCP. 

(Башкатов В.Г. 2009) 

[1] Более подробную информацию по сигналам, с которыми работает Progress, можно получить в Progress Knowledge Base (ProKB). Статья P67938: How Progress interprets and handles kill Signals

см. также Последствия использования proutil 'dbname' -C truncate bi -F