#keepalive — Public Fediverse posts

nginx -s reload может не применить конфиг

Пока идёт бинарный апгрейд nginx, systemctl reload nginx не применяет конфиг так, как вы думаете: в лучшем случае к половине процессов сервера, в худшем — вообще никуда. Код возврата ноль в обоих случаях, в error.log пусто. Что именно у вас — решает одна строчка в юните: -s reload бьёт по pid-файлу, а он после USR2 принадлежит новому мастеру; kill -s HUP $MAINPID бьёт по старому, а тот конфиг вообще не перечитывает, и это описано в документации nginx — в разделе про обновление исполняемого файла, куда по другому поводу не заходят. Это первая из пяти проверок. Я взял пять ходовых утверждений про reload в nginx, померил каждое на стенде — и получил результаты по обе стороны: три подтвердились, два развалились. Развалившиеся оказались интереснее. Не работают ровно те страшилки, что про слушающий сокет: listen ... reuseport бесшовность не ломает (inode’ы сокетов до и после reload одни и те же — их держит мастер, а не воркер), паузы в accept при reload не существует вовсе (msleep(100) стоит ПЕРЕД QUIT), а значит и арифметика про переполнение backlog на reload — про нагрузку, а не про reload. Зато подтвердилось то, о чём почти не пишут. keepalive_min_timeout оставляет уходящего воркера в живых, и тот обслуживает запросы, которых в момент reload ещё не существовало — по старому конфигу. А ngx_close_idle_connections не различает направление соединения, поэтому каждый reload сбрасывает пул keepalive к бэкендам — и с 1.29.7 это касается всех, у кого есть блок upstream : пул там включён по умолчанию, 32 соединения на воркер. Правило из первой части — «соединение, открытое до reload, нового конфига не увидит» — приходится переформулировать: держится старого конфига не соединение, а процесс. В конце — Traefik, у которого reload’а нет вовсе, и который умеет не применить конфиг своим способом: кольцевой буфер на одно сообщение и двухсекундный дроссель. nginx release-1.31.3, traefik v3.7.10, все опыты в репозитории, запуск одной командой.

https://habr.com/ru/articles/1068364/

#nginx #reload #nginx_s_reload #systemd #бинарный_апгрейд #keepalive #upstream #reuseport #backlog #traefik

nginx не умеет reload. Он умеет fork

Деплой делает nginx -s reload . Команда возвращает ноль, nginx -T показывает новый конфиг, в error.log ровно одна строка — reconfiguring. А keep-alive соединение, открытое секундой раньше, в этот момент закрывается. Само по себе это не ошибка: сервер вправе закрыть простаивающий keep-alive когда угодно. Ошибку даёт гонка — FIN уходит в тот момент, когда клиент уже записал в сокет следующий запрос. Идемпотентный он повторит, POST — нет. Разбор по исходникам на фиксированных тегах: nginx release-1.31.3, httpd 2.4.68, traefik v3.7.10, плюс замер всех четырёх (с HAProxy) на одном стенде в одном прогоне. Выясняется, что мастер nginx конфиг не перечитывает вообще: он строит новый цикл целиком и форкает новых воркеров, а старым остаётся ровно то, что у них было. Apache приходит к тому же контракту через счётчик поколений, HAProxy — через замену процесса. А у одного из четырёх второй запрос в том же самом сокете возвращает уже новый конфиг — и причина не та, о которой вы подумали. Внутри: почему документация nginx сама создаёт половину недоразумения; почему WebSocket и SSE не попадают под ngx_close_idle_connections и держат старого воркера сколько угодно долго, а HTTP/2 попадает всегда и получает GOAWAY; как сигнал родителя у Apache доезжает до конкретного соединения через пять звеньев; и таблица из двенадцати клеток, в которой четыре реализации расходятся ровно в одной. Со стендом (один docker build, один docker run), полными выводами ps и тремя claims-*.tsv, где каждое утверждение о коде проверяется скриптом.

https://habr.com/ru/articles/1067686/

#nginx #traefik #apache_httpd #haproxy #reload #graceful_restart #keepalive #исходный_код #worker_process #обратный_прокси

Отказоустойчивый запуск WSGI приложения. Обзор архитектуры Gunicorn

Gunicorn кажется простым, пока не сталкиваешься с эксплуатацией: внезапные ошибки 502, зависшие воркеры и странное поведение при перезапусках. За этими симптомами стоят вполне конкретные причины — от медленных клиентов и отсутствия буферизации до особенностей реализации GThread и механики Graceful Shutdown. В этой статье разберём реальные сценарии отказов, посмотрим, как менялась архитектура GThread в разных версиях Gunicorn, и соберём практичную конфигурацию с Nginx, Docker и Kubernetes, которая ведёт себя предсказуемо под нагрузкой.

https://habr.com/ru/companies/domclick/articles/882042/

#python #gunicorn #wsgi #prefork #gthread #graceful_shutdown #keepalive #nginx #docker

#kaniko fork call for new maintainers :)

If you are interested checkout https://github.com/osscontainertools/kaniko/discussions/304

#golang #cicd #foss #opensource #maintenance #fork #keepalive

Vielleicht ist das etwas für deine älteren Mitmenschen - vielleicht sogar auch für dich?

Keep Alive sendet eine benutzerdefinierte Nachricht per SMS an eine oder mehrere Personen, wenn Sie Ihr Gerät innerhalb eines bestimmten Zeitraums nicht benutzt haben. Diese Funktion ist als Ausfallsicherung für Alleinlebende im Falle eines Unfalls oder eines anderen Notfalls gedacht.

https://f-droid.org/de/packages/io.keepalive.android/

#keepalive #android #fdroid

Estaba cotilleando #FDroid y me he topado con #KeepAlive 🤯. Básicamente: si no has dado señales de vida (no has usado el móvil) en un período de tiempo seleccionado, manda automáticamente un mensaje a un contacto de emergencia o le realiza una llamada.

Bastante bien, ¿no? 💖

https://f-droid.org/packages/io.keepalive.android

Edit: encima puedes contactar a varias personas a la vez y mandar info de ubicación.

Keep-Alive: Prevent Your Computer from Sleeping on Linux, macOS and Windows #Keepalive #Linux #Macos #Windows #Golang #Opensource
https://ostechnix.com/keep-your-linux-system-awake-with-keep-alive/

@wanderinghermit

"Silently die" is commonly caused on Linux by the system OOM killer if the program allocates enough memory to drive the system into an out-of-memory state. Turning off overcommit on the system can be used to confirm this, as it will generally result in the Python program running until a MemoryError exception is thrown, and it will exit with a stacktrace rather than be killed before it can do so. Offhand I don't know what the behaviour on other OSes would be.

The print-prevents-dying thing I have seen before, but only when running programs on a remote machine. If there is no I/O at all happening, a network connection can end up getting reset for various reasons, causing the exit-to-shell behaviour. Adding print statements that happen to get called often enough to prevent this papers over the problem.

If this is the problem, and you're running over SSH, there are SSH options to make the session not die like this - keepalives.

#SSH #network #timeout #NAT #KeepAlive #die

Остаться в живых (keepalive) feat. HTTP/2, Go & gRPC-Go

Привет, Хабр!) Меня зовут Ильяс. В этой статье мы разберём известную идею — keepalive в межсервисном взаимодействии, которая спасла уже не одну компанию в трудное время :). Но чтобы добавить интереса, мы разберём, какие проблемы в keepalive принесли современные технологии (ведь что может пойти не так с этой простой идеей?). Поэтому в статье мы рассмотрим механизмы, которые позволяют проверять стабильность соединения между клиентом и сервером в случае, когда обычные TCP keepalive из-за сложности архитектуры не могут определить состояние сервера. Остаться в живых

https://habr.com/ru/companies/ozontech/articles/810427/

#keepalive #golang #http/2 #ozon #ozon_tech #grpc #go