Created 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 (а он жив?) или все-таки сюда? (Если что, английский - не проблема.)
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 дискового пространства.
(В ответ на комментарий №4) > Сколько же лет этой проблеме... Актуально и для p8. Тогда, видимо, и для сизифа (openntpd-3.9p1-alt12 одинаков) -- перевешиваю. Кто-то ещё удивлялся, почему мы не перешли на chrony -- Миш, не ты ли?
