Created attachment 8099 [details] трейсы При тестировании регулярок было обнаружено, что в регулярках с lxde и lsqt время синхронизируется, а в регулярках с mate и xfce нет. Дополнительный симптом проблемы - При завершении работы systemd останавливал NTP примерно 1.5 мин. В регулярках стоит один NTP клиент - chrony-3.4-alt1 При исследовании с помощью strace обнаружено, что при наличии проблемы используется библиотека /lib/libnss_mdns4_minimal.so.2, а при отсутствии - /lib/libnss_dns-2.27.so После удаления из системы пакета libnss-mdns проблема пропала. В файлах strace-out-chronyd.3259, strace-out-chronyd.3260 трейс при отсутствии проблемы. В файлах strace-out-chronyd.3576 strace-out-chronyd.3577 трейс при наличии проблемы.
Вытягивается пакет libnss-mdns через список domain client цели /use/domain/client. На i586 и x86_64 такого не наблюдаю, хотя библиотека есть. А вот на armh и aarch64 иногда наблюдается долгое выключение mate и xfce. Полторы минуты завершается сессия по сообщению на экране. Проблемы с синхронизацией времени при этом нет. Так что может и другая проблема.
Уточнение: данный баг описывает проявление проблемы на BFK3.1. Дальнейшее тестирование показало, что после удаления libnss-mdns проблема не проявляется (как указано в описании) только при ручном запуске chronyd. После перезагрузки проблема проявляется снова, для ее обхода нужно перезапустить chronyd командой systemctl restart chronyd.
(В ответ на комментарий №2) > Уточнение: данный баг описывает проявление проблемы на BFK3.1. > Дальнейшее тестирование показало, что после удаления libnss-mdns проблема не > проявляется (как указано в описании) только при ручном запуске chronyd. > После перезагрузки проблема проявляется снова, для ее обхода нужно > перезапустить chronyd командой systemctl restart chronyd. А на Таволге нормально? На BFK3 несколько сетевых, может дело в этом? Что если воткнуть сеть в первую сетевую?
это только на мипсе ?
(В ответ на комментарий №4) > это только на мипсе ? Пока да.
(В ответ на комментарий №2) > перезапустить chronyd командой systemctl restart chronyd. Кстати, не помогает ли отключение/подключение сетевого соединения в NetworkManager?
(В ответ на комментарий №3) > А на Таволге нормально?... На Таволге подобная проблема тоже есть, но проявляется по-другому: если на BFK3 chronyd зависает, то на Таволге аварийно завершается с сообщением: Fatal error : adjtimex(0x4002) failed : Invalid argument Диагностика верная - поля структуры timex неправильно заполняются перед системным вызовом adjtimex. Почему - непонятно.
(В ответ на комментарий №3) > ... На BFK3 несколько сетевых, может дело в этом? Что если > воткнуть сеть в первую сетевую? До этого тестировал на eth1. Протестировал снова на eth2. Все проявления проблемы те же. Проблема не зависит от того, в какой порт включена сеть.
(В ответ на комментарий №6) > Кстати, не помогает ли отключение/подключение сетевого соединения в > NetworkManager? Попробовал отключить и подключить соединение в NetworkManager и просто вынуть и вставить сетевой кабель. Не помогает - chronyd как висел так и висит.
Итого: что-то mipsel специфичное. Я сегодня ещё раз проверял на i586, x86_64, armh, aarch64, ничего подобного не наблюдается.
Выяснено, что на BFK3.1 chronyd повисает на системном вызове prctl(PR_SET_FP_MODE, 0) Сама необходимость этого вызова обусловлена тем, что библиотека libnss_mdns4_minimal.so.2, (и libnss_fallback.so.2 используемая после удаления libnss-mdns) собраны с иным FP ABI, нежели chronyd: FP ABI: Аппаратная плавающая запятая (32-битный ЦП, любой FPU) у chronyd FP ABI: Аппаратная плавающая запятая (двойная точность) у библиотек. После пересборки библиотек их FP ABI стало как у chronyd и проблема пропала. Проблема на Таволге исправлена патчем ядра: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29183a70b0b828500816bd794b3fe192fce89f73
Проблема с libnss-mdns была решена пересборкой (стало правильное ABI). Проблема с prctl(PR_SET_FP_MODE, 0) была решена в kernel-image-bfk3-def 2:4.4.100-alt8
