Переопределить недостатки в обработке сигналов - PullRequest
1 голос
/ 30 мая 2009

Речь идет о проектном решении и понимании преимуществ и недостатков для принятия другой услуги. Таким образом, у нас есть две службы с двумя несвязанными серверами, один из которых прослушивает порт 10000, а другой - сервер xinetd, отвечающий на 3 разных запроса через 3 разных порта (его клиент использует nc-сервер port1 | port2 | port3 для получения данных).

Однажды из-за проблемы безопасности сервер xinetd должен остановиться, и только потому, что первый сервер сохраняет те же данные, мы решили использовать сервер xinetd, отправив сигналы USR1 первому серверу и предоставив ему доступ к тому же общедоступному серверу. данные. Следовательно, необходимо добавить логику, чтобы переопределить обработку сигналов на первом сервере. Мы планируем использовать USR1 (10, 16 и 30). Например, на сервере xinetd kill -10 first_server позволит первому серверу выдавать те же данные, которые использовался старым сервером для передачи, и по-прежнему выполнять дамп на первый порт. , Аргумент в том, что это плохой дизайн, потому что он злоупотребляет использованием сигналов Unix и, конечно, переопределяет предопределенное поведение 10, 16 и 30 сигналов POXIS и Linux. Это действительно плохо технически? Какой вред нанесет системе?

1 Ответ

1 голос
/ 30 мая 2009

10 - это SIGBUS, ошибка шины - вы, вероятно, не должны касаться этого. 30 и 31 - SIGUSR1 и SIGUSR2, которые определяются пользователем и не зарезервированы для какой-либо конкретной цели. 16 - это SIGURG, срочные данные в сокете, которые вам могут не понадобиться, но было бы лучше использовать сигналы в реальном времени выше 31.

...