Зависание Bind9 + ubuntu 10.04(РЕШЕНО)

[Nesmit]

9Раз в сутки или чаще, бинд перестает отвечать на запросы. Причем с теми же конфигами в 8.04-9.10 все работало.
В логах пусто, только каждую минуту бинд откуда-то получает команду реконфигурировать.

19-May-2010 17:24:25.433 general: received control channel command 'reconfig'

и таких сообщений много.
[/s]
все оказалось просто.  у меня настроен ppptp server и при запуске каждого тоннеля рестартился bind9

[AnrDaemon]

В логах пусто, только каждую минуту бинд откуда-то получает команду реконфигурировать.

19-May-2010 17:24:25.433 general: received control channel command 'reconfig'

и таких сообщений много.

Ну а посмотреть, откуда он МОЖЕТ получать такую команду?

[Nesmit]

например как ?
на 9.10 никаких команд не получал.

[AnrDaemon]

Например, в конфигах... откуда разрешено управление?

[Nesmit]

127.0.0.1
я немного соврал, когда сказал что копия конфигов. Копия, но с не значительными изменениями.
Жду теперь когда отвалится
Пользователь решил продолжить мысль 20 Мая 2010, 12:45:44:только что отвалился вновь

[xeon_greg]

ищи  в syslog и daemon.log  в чем затык. возможно у тебя что-то по крону выполняется и вообще не мешало бы  глянуть на named.conf

[Nesmit]

поправил.
похоже все из за маленького серийника в локальной зоне.
Пользователь решил продолжить мысль 24 Мая 2010, 19:58:49:фига 2

cat /etc/bind/named.conf.options
acl "corpnets" { 10.0.0.0/8; 192.168.161.0/24; 127.0.0.1; };

options {
        version "Saaa...";
        statistics-file "/var/log/named/dns-stats.log";
        directory "/var/cache/bind";

        allow-query {
                "corpnets";
                    };

        auth-nxdomain yes;    # conform to RFC1035
        listen-on-v6 { none; };
        listen-on { 127.0.0.1; 10.168.2.2; 192.168.160.1; };
        max-cache-size 100M;
};


logging {
 channel default_log {
   file "/var/log/named/default.log" versions 3 size 10M;
   severity info;
   print-category yes;
   print-severity yes;
   print-time yes;
 };

 channel notify_log {
   file "/var/log/named/notify.log" versions 3 size 10M;
   severity info;
   print-category yes;
   print-severity yes;
   print-time yes;
 };

 channel update_log {
   file "/var/log/named/update.log" versions 3 size 10M;
   severity info;
   print-category yes;
   print-severity yes;
   print-time yes;
 };

 channel query_log {
   file "/var/log/named/query.log" versions 3 size 10M;
   severity info;
   print-category yes;
   print-severity yes;
   print-time yes;
 };

 category default      { default_log; };
 category notify       { notify_log; };
 category update       { update_log; };
 category queries      { query_log; };
};

cat /etc/bind/db.homer.lan
;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                        2008092102              ; Serial
                        604800          ; Refresh
                        86400           ; Retry
                        2419200         ; Expire
                        604800 )        ; Negative Cache TTL
;
                IN      NS      ns1.homer.lan.
homer.lan.    MX      10      ns1.homer.lan.

loopback         IN     A       127.0.0.1  ; loopback (lo0) name/address
localhost        IN     CNAME   loopback
gateway   IN A     10.168.2.254
ns1       IN A     10.168.2.254
www       IN A     10.168.2.254
ftp       IN A     10.168.2.254
vpn       IN A     10.168.2.2
@       IN A    10.168.2.254

cat /etc/bind/named.conf.local

zone "homer.lan" {
    type master;
    file "/etc/bind/db.homer.lan";           
};

[roga_i_kopita]

фига 2

Уважаемый, так решили Вы эту проблему или нет? Если да, то как?

У меня та же ситуация. Отваливается BIND9 ежедневно. При том остальные сервисы продолжают работать.
В логе bind9 только received control channel command 'stop -p'
Перерыл все файлы в /etc/cron.d (cron.daily, cron.hourly, cron.monthly, cron.weekly, crontab).
Ничего там выключающего BIND9 не нашёл.
В syslog только записи о том, что он стартует (когда я его вручную запускаю). Выключающих его событий нету.

Есть ежедневные записи об остановке и запуске ведения логов.
localhost kernel: Kernel logging (proc) stopped.
localhost kernel: imklog 3.18.6, log source = /proc/kmsg started.

Сразу после этого запись о перезапуске rsyslogd
localhost rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="1090" x-info="http://www.rsyslog.com"] restart
Помимо этого записи о синхронизации времени ntp, записи CRON о сборе статистики и lifetime php5.
Ну плюс smtpd, anvil, postfix. И всё.

Подскажите, пожалуйста, что и где ещё изменить / посмотреть надо?

[Nesmit]

похоже "нормальных" админов на Ubuntu нет (
Нужно самим разобраться и описать тут.

[roga_i_kopita]

Ну значит надо самому стать "нормальным" админом.  

В общем сделал детальное ведение логов BIND9. Попробую всё-таки отследить, что его выключает.
Если не получится, может быть имеет смысл перенести BIND в chroot, хотя, не уверен, что это поможет.
Попробую также его просто обновить до последней версии.
Ну и самое простое, на мой взгляд, добавить в CRON задание, чтоб перезапускал сервис после его остановки. Только время выключения отследить из лога надо.

И ещё... Пока всё это расписывал, пришла идея глянуть сервис logrotate.d.
В /etc/logrotate.d/bind9 следующее содержимое:

Код: [Выделить]

/var/log/bind/*.log {
        daily
        missingok
        rotate 2
        notifempty
        create 640 bind adm
        sharedscripts
        postrotate
                [ ! -f /var/run/bind/run/named.pid ] || kill -USR1 `cat /var/run/bind/run/named.pid`
        endscript
}
Вот смущает скрипт в последних трёх строчках. Видимо как раз он сразу после ротации логов и останавливает BIND.
Сам пока не программист, зачем этот скрипт вообще нужен не понимаю.

Если кто-то понимает, подскажите, пожалуйста, для чего это нужно и как бы так всё обыграть, чтоб и скрипт выполнялся (если он действительно важен) и BIND9 ежесуточно не умирал.

P.S.: странно, /etc/logrotate.d/nginx также имеет этот скрипт, только с ним проблем нет. Почему-то NGINX нормально работает, а BIND9 отключается.

[Nesmit]

мой бинд ложился гораздо чаще.
но, если поставить чистый бинд без зон, то все нормально работает и не падает.

[roga_i_kopita]

По моей проблеме вроде что-то проясняется...
Строка

Код: [Выделить]

[ ! -f /var/run/bind/run/named.pid ] || kill -USR1 `cat /var/run/bind/run/named.pid`убивает процесс named путём удаления файла named.pid и запускает его снова путём создания named.pid в том же каталоге.
Из вывода видно,

Код: [Выделить]

localhost:~# ls -al /var/run/bind/run/
итого 12
drwxrwxr-x 2 root bind 4096 Авг 24 11:38 .
drwxr-xr-x 3 root root 4096 Июн 19 17:15 ..
-rw-r--r-- 1 bind bind    5 Авг 24 11:38 named.pidчто каталог, в котором находится файл named.pid имеет атрибуты
"чтение", "запись", "изменение" для пользователя root
"чтение", "запись", "изменение" для группы bind
"изменение" для остальных пользователей и групп.
Я не знаю, от имени какого пользователя эта процедура выполняется демоном logrotate.d.
По этому ПРЕДПОЛАГАЮ, что удалить файл named.pid демон logrotate.d может, а вот создать новый - прав не хватает.
Если ошибаюсь, прошу опытных людей меня поправить.

Решил изменить процедуру перезапуска и скрипт

Код: [Выделить]

[ ! -f /var/run/bind/run/named.pid ] || kill -USR1 `cat /var/run/bind/run/named.pid`заменил на

Код: [Выделить]

if [ ! -f /var/run/bind/run/named.pid ]; then
/etc/init.d/bind9 restart > dev null
fi
Посмотрю, что из этого получится.

[Mam(O)n]

Строка

Код: [Выделить]

[ ! -f /var/run/bind/run/named.pid ] || kill -USR1 `cat /var/run/bind/run/named.pid`убивает процесс named путём удаления файла named.pid и запускает его снова путём создания named.pid в том же каталоге.

Толкование в корне не верно. Переводя команду на русский, то если есть файл .pid то посылается сигнал SIGUSR1 процессу с pid, записанному в том файле. НО!

SIGNALS
       In routine operation, signals should not be used to control the nameserver; rndc should be used instead.

       SIGHUP
           Force a reload of the server.

       SIGINT, SIGTERM
           Shut down the server.

       The result of sending any other signals to the server is undefined.

Проще говоря, в мане не говорится про данный сигнал и сказано про то что результат не определён при отсылке иных сигналов. Также говорится, что сигналы не должны использоваться для контролирования процесса, а должен исользоваться rndc, который с успехом используется в init скрипте, т.е. invoke-rc.d bind9 reload сделает перезагрузку конфигов (в отличии от restart, когда будет перезагружен сервер полностью)

И главное, этого сконфига в logrotate.d нет при чистой установке bind. Это верно что то из самопала или от старых версий... Логи вообще у тебя туда пишутся? Может убрать этот конфиг logrotate к чертям?

Пользователь решил продолжить мысль 24 Августа 2010, 16:02:55:

скрипт

Код: [Выделить]

[ ! -f /var/run/bind/run/named.pid ] || kill -USR1 `cat /var/run/bind/run/named.pid`заменил на

Код: [Выделить]

if [ ! -f /var/run/bind/run/named.pid ]; then
/etc/init.d/bind9 restart > dev null
fi
Посмотрю, что из этого получится.

Так должно быть правильно:
[ -f /var/run/bind/run/named.pid ] && invoke-rc.d bind9 reload

[roga_i_kopita]

Mam(O)n!!!! Душевно Вас благодарю за то, что помогли разобраться, поделились опытом и сэкономили моё время.
Да, действительно, это мой самопал.
Купил виртуальный сервер с готовым пресетом и доустановил туда bind9.
Мне показалось мало возможности настроить ведение логов средствами самого bind9 и потому я добавил этот конфиг в logrotate.d.
Логи писАлись и ротировались успешно.
Но я не разобрался с назначением выполняемого скрипта, а при создании в logrotate.d конфига для bind9 просто скопировал этот скрипт из конфига от другого сервиса. В итоге, как и указано в man named, имел проблемы из-за применения сигнала SIGUSR1 к процессу named.
По незнанию и из-за невнимательного изучения манов сам себе создал проблему и героически боролся с ней.  
Решил последовать Вашему совету - убрал этот конфиг из logrotate.d.

[Mam(O)n]

убрал этот конфиг из logrotate.d.

Ну если там ротировать нечего, то можно спокойно убирать. НО! Я копнул выше по треду и заметил следующий конфиг:
из которого следует, что логи всё таки ведутся, но совсем в другой директории... Там наверное всётаки ротирование и не помешало бы....Тля. Сразу не заметил, что пост не твой.

Вкратце объясню проблему, зачем нужно дёргать демона после ротации. В рядовой программе, после старта программы и чтения конфигов, открывается файл для логгирования и программа в течении своей работы работает с этим файловым дескриптором. Мы в процессе ротации открытый файл лога переименовываем, но программа держится за открытый дескриптор файла, а не за имя, и получается, что запись продолжается в уже переименованный файл... Даже если мы удалим файл, но не закроем дескриптор, мы будем продолжать в него писать. Физически файл удалится только тогда, когда все программы от него отстанут (закроют его файловые дескрипторы) Поэтому, после ротации, нужно както сказать программе, чтобы она заново открыла файл и получила новый файловый дескриптор для нового файла. Для этого многие демоны слушают разного рода сигналы. Большинство демонов ожидают сигнала SIGHUP чтобы перечитать свои конфиги и заново открыть логи. Но так бывает не всегда, т.к. единого стандарта вовсе нет и SIGHUP в первую очередь предназначен совсем для другой сигнализации, просто его юзают из за того, что его изначальное предназначение бессмысленно для демонов, а свободных и универсальных (которые присутствуют во всех системах) очень мало. В общем, для каждого демона читайте маны, там в конце обычно описываются реакции на разного рода сигналы.

Так что дёргайте бинда после ротации с помощью invoke-rc.d bind9 reload