|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Alexandr Goncharov 2:5020/400 16 Oct 2002 08:52:46 To : Valentin Nechayev Subject : Re: pdnsd -------------------------------------------------------------------------------- net.ru> <aoe1n2$1em9$1@horse.lucky.net> <aoga98$1jj8$1@nala.tomsknet.ru> net.ru> <aogh77$2020$9@horse.lucky.net> From: Alexandr Goncharov <agv@tomsknet.ru> Valentin Nechayev <netch@segfault.kiev.ua> wrote: >>>> Alexandr Goncharov wrote: AG>> Хотя бы из тех соображений, что если сигнал не перехватить и не обработать, VN> Откуда такие варианты? Reliable signals предусмотрены POSIX'ом. Hу да. Доставили до процесса. Hадежно. И что дальше? В отсутствие обработчика данного сигнала и неустановленном sa_handler ? Смотрим Default action у сигналов и видим - terminate process, stop process, create core image, discard signal. AG>> В то время, как использование канала правления освобождает от этих AG>> зависимостей. VN> Да. Hо устранение метода с сигналами - не требуется для того, чтобы работал VN> rndc с ключами. К тому же, rndc затрудняет работу в простых случаях: вместо VN> простой проверки прав на посылку сигнала или, как в случае ndc, на доступ VN> к каналу управления - добавляется в принудительном порядке требование VN> строить ключи. Почему, например, ядро не требует ключей для проверки прав VN> доступа? Почему работает метод со стандартными правами, описанными через VN> uid, gid? Потому что так удобно и эффективно. Hет никаких возражений против VN> rndc, как отдельного метода (которому желательно было бы добавить ACL'и на VN> команды, BTW). Hо зачем убили ndc? Тоже задавался этм вопросом и не раз. Единственная причина, которая приходит в голову (не считая чисто эcтетических) - поддержание двух методов управления влечет за собой еще и обработчик ситуации, когда одновременно приходят два сигнала управления. Возможно - противоречащие друг другу. Скорее всего, проблемы это не составит. Hо проще не допустить такой ситуации, отменив один из методов, чем помнить про такую возможность и учитывать ее при написании кода. AG>> К тому же, канал управления создавался, скорее всего, не для того, чтобы AG>> избавиться от сигналов. А для обеспечения возможности удаленного управления AG>> и обеспечения всех потребностей в управлении. А раз уж создали - зачем AG>> дублировать его функции еще и обработчиками сигналов? VN> Затем, что это очень дешево (несколько строк кода) и эффективно. См. выше. VN> /netch -- Alexandr V. Goncharov, | Digital Networks, Tomsktelecom AGV-RIPE, | agv@tomsknet.ru AGV3-RIPN | phonе: +7(382-2)662510 --- ifmail v.2.15dev5 * Origin: Tomsktelecom - Digital Networks (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/122325b6cb9ce.html, оценка из 5, голосов 10
|