Bug 27592
| Summary: | ntpd отваливается на отсутствующем IPv6 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Dmitry Chistikov <dd1email> | ||||||||
| Component: | openntpd | Assignee: | placeholder <placeholder> | ||||||||
| Status: | NEW --- | QA Contact: | qa-sisyphus | ||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | cas, glebfm, ldv, mike, placeholder, real.altlinux.org, sem, sin | ||||||||
| Version: | unstable | ||||||||||
| Hardware: | all | ||||||||||
| OS: | Linux | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 5525 [details]
dig responses
(In reply to comment #0) > Сразу вопрос: с этим багом лучше в upstream (а он жив?) или все-таки сюда? > (Если что, английский - не проблема.) Насколько я понимаю, апстрим этот проект несколько подзабросил, так что все-таки сюда. Created attachment 5529 [details]
hackaround
Поразбирался немного в коде и убедил себя в корректности такого вот hackaround'а (см. вложение). Теперь EAFNOSUPPORT - не проблема; у меня исправленный вариант работает; можно тестировать.
Тем не менее, хорошим это решение мне не кажется (см. пояснительную записку в патче). Гораздо лучше "плохой" адрес вовсе выкидывать; вроде смысл имеющегося списка с соседним указателем я понял, попробую на днях исправить более правильным образом.
Сколько же лет этой проблеме... Актуально и для p8. Вообще, chrony по множеству параметров превосходит openntpd. https://chrony.tuxfamily.org/comparison.html При этом имеется жестка привязка к alterator-datetime: [root@client tmp]# apt-get install chrony-2.2-alt1.1.x86_64.rpm libsqlite3-3.15.2-alt1.x86_64.rpm libnss-3.28.1-alt0.M80P.1.x86_64.rpm Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Выбрано chrony для 'chrony-2.2-alt1.1.x86_64.rpm' Выбрано libsqlite3 для 'libsqlite3-3.15.2-alt1.x86_64.rpm' Выбрано libnss для 'libnss-3.28.1-alt0.M80P.1.x86_64.rpm' Следующие пакеты будут УДАЛЕНЫ: alterator-datetime openntpd Следующие НОВЫЕ пакеты будут установлены: chrony libnss libsqlite3 0 будет обновлено, 3 новых установлено, 2 пакетов будет удалено и 0 не будет обновлено. Необходимо получить 0B/1782kB архивов. После распаковки потребуется дополнительно 5204kB дискового пространства. Продолжить? [Y/n] n Прервано. Хотя в сизифной сборке всё уже решено: [root@client tmp]# apt-get install chrony-2.2-alt2.M80P.1.x86_64.rpm libsqlite3-3.15.2-alt1.x86_64.rpm libnss-3.28.1-alt0.M80P.1.x86_64.rpm Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Выбрано chrony для 'chrony-2.2-alt2.M80P.1.x86_64.rpm' Выбрано libsqlite3 для 'libsqlite3-3.15.2-alt1.x86_64.rpm' Выбрано libnss для 'libnss-3.28.1-alt0.M80P.1.x86_64.rpm' Следующие пакеты будут УДАЛЕНЫ: openntpd Следующие НОВЫЕ пакеты будут установлены: chrony libnss libsqlite3 0 будет обновлено, 3 новых установлено, 1 пакетов будет удалено и 0 не будет обновлено. Необходимо получить 0B/1788kB архивов. После распаковки потребуется дополнительно 5230kB дискового пространства. |
Description
Dmitry Chistikov 2012-08-02 14:51:09 MSKCreated attachment 5524 [details] strace log ntpd запускается и работает, но затем (вероятно, в некотором смысле из-за не очень хорошего Интернет-соединения - однако см. далее) неожиданно завершает работу. В журнале: "dispatch_imsg in main: pipe closed". Если не давать уходить в фон, то перед этим докладывает: "fatal: client_query socket: Address family not supported by protocol" (это EAFNOSUPPORT на socket(2)). Попытка выяснить, что происходит, c помощью strace -e socket,close (см. вложение) показывает, что дочерний процесс пытается выполнить socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP), на что и получает -1 с EAFNOSUPPORT, после чего завершает работу. Никакого IPv6 на машине и в помине нет: $ lsmod | grep ipv6 $ ls /proc/sys/net/ | grep ip ipv4 $ uname -r 3.2.10-un-def-alt0.M60P.1 Я очень слабо разобрался во внутренних механизмах openntpd, однако причины завершать работу не вижу: например, из приведенного вывода (см. то же вложение) следует, что перед exit у дочернего процесса по-прежнему открыты два сокета (3 и 5); да и в случае, когда не остается ни одного, все равно можно продолжать (что обычно и происходит) работу. В терминах исходного кода: я не вижу причины, по которой в 133-й строке в client.c стоит fatal("..."). Можно забить и пропустить соответствующий элемент структуры, можно (например, в случае -1 EAFNOSUPPORT) пытаться "вычеркивать" этот элемент окончательно, но зачем опускать руки? На всякий случай: $ cat /etc/ntpd.conf | egrep -v '^(#|$)' server ntp.progtech.ru servers pool.ntp.org Ответ dig -t any на эти FQDN в отдельном вложении. Сразу вопрос: с этим багом лучше в upstream (а он жив?) или все-таки сюда? (Если что, английский - не проблема.)