Оповещение для клиентов сервера ntp о необходимости синхронизации

Никак. С чего это клиентам должно быть необходимо синхронизироваться по желанию сервера? Отклонения хода клиентских часов и необходимость переуточнения текущего времени - дело исключительно клиента. Сервер (точнее, много севреров по всему миру) только предосталяет по запросу клиента информацию.

Выше все правильно написали. И дополню вопросом: Что в вашем понимании есть «клиентам необходимо синхронизироваться с ним?».

И так, есть локальная сеть, на одном устройстве крутиться ПО и сервер ntp, есть еще ряд устройств которые как клиенты синхронизируются с серваком и взаимодействую с ПО. У ПО есть алгоритм в котором используются данные этих самых устройств в частности метка времени, если метки времени будут отличатся на несколько секунд или еще хуже минут, то результат алгоритма будет не правильным, что приведет к критическим проблемам. А теперь ситуация: на серваке меняют метку времени, а затем приступают к выполнению алгоритма, результатом будет как я выше сказал ошибка, для этого и нужно просигналить клиентам о том, что нужна синхронизация.

поставь в локалке свой сервер ntp и синхронизируйся с ним хоть по несколько раз в минуту, это твой сервер.
вариант2: с сервера через ssh запустить синхронизацию на клиентах апосля смены метки времени. и прочие варианты с методом посылки команды в клиентов.

Если начну синхронизацию с такой частотой, то некоторые клиенты могут «задохнутся» от этого и банально отвалятся, не у всех клиентов есть ssh поэтому не получится запустить у них синхронизацию

Изучите как работает ntp. Разовые синхронизации, приводящие к скачкам локального времени в будущее или, не дай Джа, в прошлое, это не основной режим работы. В штатном режиме клиент и сервер обеспечивают «плавную» синхронизацию путём вычисления дельты между таймерами и управления течением времени на клиенте для сведения этой дельты к нулю, путём замедления или ускорения «хода» локальных часов.

ssh тут вообще не причём, на клиенте исполняется демон ntpd который общается с сервером времени по протоколу ntp. Просто изучите уже матчасть.

PS. Чо реально уже никто не понимает как ntp работает? Почему тут уже столько постов на тему велосипедостроения? Или большинству просто лень этот локальный тупнячок на путь истинный наставить?

тогда выставь ту частоту, которой тебе хватит и клиенты не отвалятся.
такто нтп не столько жрущий протокол чтобы заддосить сервер или клиента. но тебе решать.

как вариант подзаковыряться, можно промониторить уплывание времени на клиентах и выставить частоту синхронизации на каждом так, чтобы она точно не уплывала больше чем на необходимые доли секунд и клиент не напрягался. если клиенты живут в стабильных условиях окружающей среды температура влажность, то дрейф частоты будет стабилен.

Я все это прочитал, только это знание ни как не решает возникшей проблемы

Если бы все было так просто, видишь ли внешние устройства производятся отдельно от ПО в разных компаниях и доступа к их «внутренностям» нету, поэтому я и хотел узнать есть ли возможность заставить клиентов ntp сервера синхронизироваться по сигналу.

Напиши клиент-серверное приложение. Сервер по бродкасту будет рассылать сигналы, а клиенты будут эти сигналы ловить и синхронизироваться по ntp

Я правильно понял что корень проблем в

на серваке меняют метку времени, а затем приступают

и избежать скачков времени на серваке никак нельзя? То бишь у вас на самом сервере времени время течёт не равномерно, а с прыжками в будущее?

Верно, время могут поменять в любой момент и в любую сторону как в будущее так и в прошлое.

Протокол ntp совершенно не рассчитан на прыгающее на сервере время. Обеспечь сервер более качественным таймером, который не будет прыгать. Например, можно запустить на нём ntp-клиент к ru.pool.ntp.org.

Ну если бы у ntp были пакеты которые бы сигналили о необходимости синхронизации то я бы так и сделал. А если делать отдельное приложение то проблема в том, что его нельзя будет поставить на некоторые клиенты.

Зачем меняют?

Боюсь что ntp не рассчитан на работу во Вселенной с такой странной физикой, лол. Видимо тут придётся самостоятельно изобретать сигнальный протокол. Хотя если у вас «клиенты» закрыты для модификаций это тоже не поможет, «штатный» ntp так не умеет совсем.

Выхода в интернет нету, только закрытая локальная сеть, так что к сожалению не получится.

Смена часово пояса например, когда забыли поменять сразу, замена устройства на котором крутиться ПО, банальное уточнение, имеет место быть даже причина «просто, потому что могу»

Так эти «скачки» это фича такая, или особенность сервера, от которой хотелось бы избавиться? Так то демон ntp умеет вполне себе без интернета синхронизироваться с часами спутников gps (и ЕМНИП базами сотовой связи) через любой умеюющий в gps\gsm usb свисток. Организовать свой собственный изолированный от инета «сервер точного времени» несложно...

Что ж этого ответа я боялся больше всего, до конца надеялся что я чего не увидел в доках или что не до конца понял, жаль.

Требование к ПО такое, и в устройство не получится вставить что то не штатное, а штатного usb-разъема в нем нету.

Часовой пояс на метку времени не влияет. Он учитывается только при конвертации метки в человеко-удобный вид с датой и часами минутами секундами.

Замена устройства - ну, надо обеспечить чтобы время правильное стояло и до и после замены. «Уточнение» надо делать плавно, например подгоняя по 1 секунде за час. «Просто так» - ну это вредительство, проблема не техническая уже, таких деятелей надо наказывать.

Ну к сожалению не всегда соблюдаются все требования, отсюда и возникла задача именно в таком формате. А насчет часового пояса то меняется он изменением самого времени так как на устройстве есть доступ только к ПО, там и клавиатуры то нету как таковой, только цифры и пару функциональных клавиш.

Смена часово пояса например, когда забыли поменять сразу, замена устройства на котором крутиться ПО, банальное уточнение, имеет место быть даже причина «просто, потому что могу»

Судя по этой цитате скачки во времени на сервере это не какая то нужная в производственном процессе фича, а следствие некоего организационного бардака. Такое исправляется мерами административными, не техническими.

По вопросам техническим, раз уж сервер тоже являет собой нечто закрытое и без usb портов, можно же поднять в локалке ещё один сервер, «сервер точного времени», на самой дешёвой железке, так как максимум что от него потребуется это иметь в usb свисток и держать запущенным демон ntpd. Он будет получать через свисток точное время со станций сотовой связи или спутников GPS и раздавать его по сети. А сам «рабочий» сервер и железячных клиентов уже с ним синхронизировать штатным способом, так как на «сервере точного времени» ничего прыгать не будет. И на «рабочем» сервере тоже не будет, он будет клиентом «сервера точного времени», таким же как железки, и всё станет синхронизированно.

Конечно от «просто, потому что могу» программно не защититься, но может сделать так чтобы за это стучали по рукам? Или физически железку изолировать так чтобы «просто потому что могу» превратилось в «не могу, заперто». Потому что выше правильно писали, такое поведение называется «саботаж».

Если бы можно было просто объяснить, те кто выдвигают такие требования далеки от процессов разработки, да и что то добавить в имеющуюся систему так же получится, короче тупики со всех сторон. Буду пытаться изобрести какую нибудь инвалидную коляску хоть как то работающую. Спасибо всем за помощь!

если костылить костыли то имхо привязывать данные к UTC как универсальное средство. и gps и сотовая система дает время «UTC +TimeZone»

Что значит «задохнутся»? Если у вас их там не десятки тысяч, то на клиентах while [ 1 ]; do ntpdate -b $SrvIP; sleep 30; done.

Поставьте gps приемник с него и берите время. Ну или атомные часики заведите.

Ну и причем тут смена часового пояса?

Только с gsm нэнадо, косяк у опсоса и «чудесные» последствия разгребать ещё долго будете, а косяки у опсосов случаются.

Скорей всего ты обшибся. Заказчик говоря бродкаст имел ввиду синхронизацию времени клиентов в локальной сети, а не сигналы через бродкаст

Заказчик без понятия что такое broadcast. Он сказал вот тут должна быть кнопка и все должно работать.

Значит это ты нафантазировал себе это

Только с gsm нэнадо, косяк у опсоса и «чудесные» последствия разгребать ещё долго будете, а косяки у опсосов случаются.

Ну я gsm как возможный вариант упомянул, вдруг они в подвале без окон и спутники не ловятся. А сотовая сеть ловится. «Атомные часы» это тоже хорошо, но я думаю найти железку труднее и стоить она будет дороже чем gsm-свисток в usb.

Сам то я на базе GPS приёмника cделал в тот единственный раз когда мне это понадобилось. А «атомные часы» даже не гуглил.

Ну если можно воткнуть gsm, то тогда и жопорез можно воткнуть, говоришь, что синкешь через gsm, а сам пользуешь жопорез :)

Тогда пусть клиент перед началом использования алгоритма сервера и запроса к нему проверяет время сервера и корректирует своё. То есть когда надо тогда и всё и приводится к единому знаменателю. ИМХО конечно.