Bug 27592 - ntpd отваливается на отсутствующем IPv6
Summary: ntpd отваливается на отсутствующем IPv6
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: openntpd (show other bugs)
Version: unstable
Hardware: all Linux
: P3 major
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-02 14:51 MSK by Dmitry Chistikov
Modified: 2017-04-11 17:43 MSK (History)
8 users (show)

See Also:


Attachments
strace log (6.18 KB, text/plain)
2012-08-02 14:51 MSK, Dmitry Chistikov
no flags Details
dig responses (3.83 KB, text/plain)
2012-08-02 14:52 MSK, Dmitry Chistikov
no flags Details
hackaround (1.87 KB, patch)
2012-08-03 22:59 MSK, Dmitry Chistikov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Chistikov 2012-08-02 14:51:09 MSK
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 (а он жив?) или все-таки сюда? (Если что, английский - не проблема.)
Comment 1 Dmitry Chistikov 2012-08-02 14:52:22 MSK
Created attachment 5525 [details]
dig responses
Comment 2 Dmitry V. Levin 2012-08-02 16:10:08 MSK
(In reply to comment #0)
> Сразу вопрос: с этим багом лучше в upstream (а он жив?) или все-таки сюда?
> (Если что, английский - не проблема.)

Насколько я понимаю, апстрим этот проект несколько подзабросил, так что все-таки сюда.
Comment 3 Dmitry Chistikov 2012-08-03 22:59:31 MSK
Created attachment 5529 [details]
hackaround


Поразбирался немного в коде и убедил себя в корректности такого вот hackaround'а (см. вложение). Теперь EAFNOSUPPORT - не проблема; у меня исправленный вариант работает; можно тестировать.

Тем не менее, хорошим это решение мне не кажется (см. пояснительную записку в патче). Гораздо лучше "плохой" адрес вовсе выкидывать; вроде смысл имеющегося списка с соседним указателем я понял, попробую на днях исправить более правильным образом.
Comment 4 Evgeny Sinelnikov 2017-03-12 02:28:44 MSK
Сколько же лет этой проблеме... Актуально и для p8.
Comment 5 Evgeny Sinelnikov 2017-03-12 03:12:51 MSK
Вообще, 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 дискового пространства.
Comment 6 Michael Shigorin 2017-04-11 17:43:29 MSK
(В ответ на комментарий №4)
> Сколько же лет этой проблеме... Актуально и для p8.
Тогда, видимо, и для сизифа (openntpd-3.9p1-alt12 одинаков) -- перевешиваю.

Кто-то ещё удивлялся, почему мы не перешли на chrony -- Миш, не ты ли?