SystemD и ожидание DNS
... Есть всякие нерадивые программисты, которые в процессе разработки почему-то наивно уверены в том, что сетевая связность между различными компонентами / приложениями / микросервисами незыблема, она типа есть / будет всегда. Поэтому после неудачной попытки подключения к чему-нибудь-там они даже и мысли не допускают о том, чтобы предпринять ещё ( Read more... )
Comments 26
я когда пытался втянуться во что-то типа девопсовности, столкнулся с непониманием одной программистки того, что у tcp-сессий и разных протоколов есть такая фигня, как таймаут.
и при этом она писала всякие хренотени для интернет-магазина и была "заведующей" jenkins'ом (ну в смысле не рядовой программист, а облеченный доверием ))
собственно, и узнал я это по ее претензии, что "у меня через ~10 минут перестают отсылаться письма".
пардон, а ты сессию поддерживаешь? или переоткрываешь? - загадочное молчание в ответ.
потом уже через общение с начальником осознал глубину своего вопроса ))
то есть чел пишет (до сих пор пишет, вчера только ее видел) сетевые приложения и вообще был не в курсе, как работает сеть в целом и smtp в частности.
а по сути поста - vi /etc/hosts не вариант? )) или оно очень динамично меняющееся, и прибивать гвоздями нельзя?
Reply
Немудрено. Я только недавно узнал, что в Linux TCP keepalive не включен по умолчанию для нового сокета, и его нужно отдельно заказывать через setsockopt(). Это не то знание, которое ожидается от высокоуровнего программера, у которого о таких вещах обычно уже заботятся те абстракции, которыми он пользуется. Просто кто-то что-то в одной из библиотек забыл.
Reply
А оно не то чтобы прям супернужно. Если у всех честные ip и/или все обитают в одной сети, то и без keepalive вполне норм.
Reply
> у tcp-сессий и разных протоколов есть такая фигня, как таймаут
позвольте, но как же она работал в очистке?
Reply
Я тоже извращался с пингами, пока не прочитал в man systemd.special:
nss-lookup.target
A target that should be used as synchronization point for all host/network name service lookups. Note that this is independent of UNIX user/group name lookups for which nss-user-lookup.target should be used. All services for which the availability of full host/network name resolution is essential should be ordered after this target, but not pull it in. systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the "$named" facility.
Поставил везде After=network.target nss-lookup.target, прошёл где-то год, полёт нормальный.
Уж не знаю, действительно ли оно делает тестовый резолвинг.
Reply
Если у тебя локальная кеширующая прослойка, это не сработает. Ресолвер-то поднимется, а вот кешируюший DNS -- нет.
Reply
Вообще, если я использую systemd-resolved, то я ожидаю, что nss-lookup.target учитывает необходимость убедиться, что systemd-resolved работает, разве нет? Я попытался понять, как же эта target определена, но не смог. Что-то в кишочках systemd, беглый взгляд на сырцы не принёс понимания.
Reply
Он подтверждает, что resolver готов к работе. Но systemd-resolved - это не ресолвер, несмотря на своё название. Это кеширующий DNS-сервер по своей сути.
Systemd может убедиться, что он стартовал. Но ничего не знает о том, готов ли resolved обслуживать запросы или нет.
Reply
Leave a comment