LINUX.ORG.RU
Форум — Admin  

named-chroot - молча умирает, не пишет в логи

 , , ,


0

1

Имеется RHEL 7.9. На нём bind9. Да не простой, а chroot-ный, в /var/named/chroot запертый.
Работал он-работал, и тут его 1 юный падаван (не я) решил restart-нуть. И он сдох. В логи не пишет, на откат конфига не реагирует. Бэккапы у службы РК оказались аж за март.
Я такими извращениями (chroot) ранее не страдал. Поэтому немного растерялся. Потом посмотрел пакет, там всё логично. Список файлов и папка /var/named указаны для монтирования.
Однако, этого самого монтирования при запуске systemctl start named-chroot видимо не происходит.
Пробовал переименовать папку chroot, создать новую, выставить права, запустить systemctl start named-chroot-setup.
Он создает набор папок, и named.ca из /var/named. Папки masters и другие с зонами не монтирует.
Если смонтировать вручную командой
mount --bind /var/named /var/named/chroot/var/named
и запустить bind так:
named -u named -t /var/named/chroot -g -d 1
то он работает, видно, как отвечает на запросы.
Вопрос: что случилось и что делать? Где находится логика, которая делает mount –bind? В самом bind-e? Почему она не отрабатывает из unit-a systemd? И как пофиксить? Unit: https://pastecode.io/s/xamn7cop

★

Последнее исправление: c0unt0 (всего исправлений: 1)
← мучения с аппаратным Watchdog
Скрипт для удаленного выключения linux систем из под Windows →

Насколько я помню, в systemd, named-chroot.service

Попробуй начать копать оттуда

upd. After=named-chroot-setup.service

т.е. смотри /usr/lib/systemd/system/named-chroot-setup.service

а там ExecStart=/usr/libexec/setup-named-chroot.sh /var/named/chroot on /etc/named-chroot.files

router ★★★★★
()
Ответ на: комментарий от router

Нашли косяк, виндовое окончание файла в 1 из зон. Копировали из Jira в mcedit видимо, т.к. vim бы крякозябру подсветил.
А bind не как все нормальные сервисы - пишет ошибки в конце, а в процессе подгрузки зон. И в середине огромного списка эта строчка затерялась. Пока весь не просмотрел - не заметил.
В логи он не пишет, т.к. они в chroot-e, а после косяка chroot отмонтируется.

c0unt0 ★
() автор топика
Последнее исправление: c0unt0 (всего исправлений: 1)
Ответ на: комментарий от c0unt0

В логи он не пишет, т.к. они в chroot-e, а после косяка chroot отмонтируется.

Вот тут ещё не докопал :) chroot не теряет данные, т.к. это просто mount - bind. Но т.к. named ещё не взлетел, то возможно он не открыл свой лог, а нажаловался в консоль (а в нашем страшном будущем консоль будет в journald)

router ★★★★★
()
Ответ на: комментарий от router

Ага, а зон - много страниц. Нет бы как все программы - стопорился на том, что мешает. Ан нет, все пробежал.
Я через journalctl и смотрел.

c0unt0 ★
() автор топика
Последнее исправление: c0unt0 (всего исправлений: 3)
Ответ на: комментарий от c0unt0

Он сам проверяет перед запуском, проверку проходил.

Спасибо, кэп. Но если там ошибка, он не взлетит

Поэтому проверять нужно конфиг перед деплоем (читай - перед рестартом named)

router ★★★★★
()
← мучения с аппаратным Watchdog
Admin
Скрипт для удаленного выключения linux систем из под Windows →