LinuxCamp | DevOps

conntrack table: невидимый лимит Linux Что такое conntrack conntrack - это таблица отслеживания сетевых соединений в netfilter. Каждое TCP/UDP соединение, NAT, kube-proxy, Docker, firewall проходит через нее. Если таблица переполнена, сеть начинает ломаться без ошибок в приложениях. Симптомы переполнения Соединения не устанавливаются, random timeouts, сервисы живы, но клиенты не могут подключиться, CPU норм, сеть есть, но ничего не работает. В логах ядра:

    
        
dmesg | grep conntrack

типичный вывод:
nf_conntrack: table full, dropping packet{}
    

Проверяем текущее состояние

    
        
# сколько соединений сейчас
cat /proc/sys/net/netfilter/nf_conntrack_count

# максимальный лимит
cat /proc/sys/net/netfilter/nf_conntrack_max{}
    

Если count ≈ max, то ты уже в зоне риска. Временное решение Увеличить лимит на лету:

    
        
sysctl -w net.netfilter.nf_conntrack_max=262144{}
    

Постоянная настройка В /etc/sysctl.conf или /etc/sysctl.d/conntrack.conf:

    
        
net.netfilter.nf_conntrack_max=262144
net.netfilter.nf_conntrack_tcp_timeout_established=600{}
    

И применить:

    
        
sysctl -p{}
    

Вывод Переполненный conntrack выглядит как непонятная поломка сети. Проверка занимает 10 секунд, но лучше заранее заняться настройкой правильного лимита. LinuxCamp | #utils

Restart=always: зло или нет Что делает Restart=always systemd перезапускает сервис при любом завершении, даже если он упал из-за бага или был остановлен вручную.

    
        
[Service]
Restart=always{}
    

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

    
        
Restart=always
RestartSec=1{}
    

В итоге:

    
        
start → crash → restart → crash → restart{}
    

CPU жрётся, логи летят, система шумит, а причина падения маскируется. Посмотреть это легко:

    
        
systemctl status myservice
journalctl -u myservice{}
    

Когда Restart=always реально зло Если сервис падает из-за: ошибки конфигурации, отсутствия зависимостей, недоступной сети, битых env-переменных. В этих случаях рестарт ничего не чинит, а только мешает диагностике. Более безопасная альтернатива Для большинства сервисов лучше:

    
        
Restart=on-failure
RestartSec=5{}
    

systemd перезапустит сервис при краше, но не будет вечно крутить его при нормальном выходе. Контроль перезапусков Чтобы не получить restart loop:

    
        
StartLimitIntervalSec=60
StartLimitBurst=5{}
    

После 5 падений за минуту systemd остановит сервис. Когда Restart=always оправдан Очень простые демоны, воркеры без состояния, sidecar-сервисы, сервисы, где падение = всегда ошибка. Даже там обычно добавляют лимиты. Вывод Restart=always - не защита, а автоповтор ошибки. Если сервис может падать из-за конфигурации или окружения используй on-failure и лимиты. Автоперезапуск должен помогать системе, а не скрывать проблемы. LinuxCamp | #utils

ChatGPT всегда говорит, что ты прав 😂 А потом на деле оказываешься по локоть в логах и дебажишь то, что по словам gpt должно было работать идеально 😄 💋 Нейросети обучены льстить И им сложно НЕ соглашаться со всем подряд. ⚡️В NeuroNinja рабочие техники от инженера СберТехнологий. Честные заметки о том, как эффективно использовать LLM и реальные кейсы для твоих проектов. 👉 Подписаться: https://t.me/+L2ZSxV0JhHRiMDYy

systemd watchdog: перезапуск зависших сервисов Что это вообще такое Watchdog в systemd - это механизм, который перезапускает сервис, если он завис, даже если процесс формально жив. Не по exit-коду, а по факту отсутствия уведомления. Минимальная настройка В юните сервиса:

    
        
[Service]
Type=notify
WatchdogSec=30{}
    

Это значит, что сервис обязан раз в 30 секунд подтверждать, что он работает. Сервис пингует systemd через sd_notify. Простейший пример (bash):

    
        
while true; do
  systemd-notify WATCHDOG=1
  sleep 10
done{}
    

Если systemd-notify перестаёт вызываться watchdog срабатывает. При зависании, даже если процесс жив, но зациклился, завис на I/O, ушёл в deadlock, перестал обрабатывать события systemd считает сервис мёртвым и делает:

    
        
Watchdog timeout, restarting service{}
    

Проверка, что watchdog активен

    
        
systemctl show myservice | grep Watchdog{}
    

И в логах:

    
        
journalctl -u myservice | grep watchdog{}
    

Частая ошибка

    
        
Type=simple
WatchdogSec=30{}
    

Не сработает. Watchdog требует Type=notify, иначе systemd не ждёт сигналов. Вывод systemd watchdog можно использовать как защита от зависаний, а не падений. Если сервис может застыть, но не упасть, то watchdog лучше включить watchdog. LinuxCamp | #utils

Сеньор за полгода? 📈 Эта девушка получила оффер в IT-компанию, хотя весь её опыт — пара курсов с ютуба 😱 Она воспользовалась ИИ-помощником и легко скрыла все свои пробелы в знаниях. Теперь впереди: ⤵️ удалёнка, стартовое обучение и ставка 55$ в час. Проходи собеседования вместе с Interview Ninja 🥷 Проверь успех на себе — есть 100 бесплатных запросов на день. 👉 @interview_ninja

Действительно, как же не хватает в ОС рекламы и напоминаний о таких знаковых днях, как "Национальный день пиццы") Как бы вы отнеслись к тому, что Linux дистры начали бы пушить рекламу? Как быстро бы снесли образ либо перешли на cli? LinuxCamp | #memes

Блог админа этого канала Оч рекомендую вам свой блог, в котором я рассказываю про AI, жизнь программиста и разработку SaaS-ов. Уже как год погружен в нейронки и внедряю их где только можно. Также 6 месяцев пишу свой проект Postish.me для тг админов и креаторов. На канале показываю свой путь и делюсь опытом. Кому хочется писать код быстрее с AI и создавать свои IT продукты, велком. Мне есть, чем с тобой поделиться: https://t.me/+lv_KviobmVc5YTVi

zombie процессы: кто их чистит и когда это проблема Что такое zombie Zombie-процесс - это процесс, который уже завершился, но его родитель ещё не прочитал код завершения. Он не потребляет CPU и память, но занимает запись в таблице процессов. В ps выглядит так:

    
        
ps aux | grep Z
# или
ps -eo pid,ppid,stat,cmd | grep Z{}
    

Статус Z или Z+. Откуда они берутся Процесс завершился, родитель не вызвал wait() или waitpid(). Часто это баги в демонах, скриптах, самописных сервисах, иногда кривые fork-циклы. Кто чистит зомби Зомби может удалить только родительский процесс. Если родитель умер, зомби автоматически переподвешивается к init / systemd, и он его корректно дочищает. То есть сам зомби убить нельзя, у него уже нет кода выполнения. Как диагностировать причину Смотрим родителя зомби:

    
        
ps -eo pid,ppid,stat,cmd | grep Z{}
    

Если PPID не 1, значит родитель жив и неправильно обрабатывает завершение детей. Что с этим делать Убивать нужно родителя, а не зомби. После перезапуска или фикса родительского процесса зомби исчезнут автоматически. Вывод Zombie - это не утечка памяти, а утечка внимания со стороны родителя. Если зомби накапливаются - это всегда баг в коде или в управлении процессами, а не проблема ядра. LinuxCamp | #utils

📘 На Stepik вышел курс — «SRE-инженер: От основ до продакшена»Хотите строить системы, которые не падают, управлять инцидентами без хаоса и внедрять культуру надёжности? Этот курс — полный путь SRE-инженера.• SRE-фундамент: философия SRE, error budgets, toil reduction, blameless culture• SLI/SLO/SLA: метрики надёжности, договорённости с бизнесом• Observability: Prometheus, Grafana, ELK Stack, Jaeger, OpenTelemetry• Алертинг: эффективные алерты, runbooks, on-call ротации• Incident Management: классификация, эскалация, координация• Post-mortem: root cause analysis, предотвращение повторений• Отказоустойчивость: graceful degradation, circuit breakers, failover• Chaos Engineering: Chaos Monkey, Litmus, Game Days• Продакшен: High Availability, Disaster Recovery, RTO/RPO🎓 Сертификат — добавьте в резюме или LinkedIn🚀 Скидка 25%, действует 48 часов👉 Пройти курс на Stepik

Аппаратные брейкпойнты в Linux, или зачем ломать GDB В чем смысл аппаратных триггеров с точки зрения отладчика? Они делают возможной реализацию на аппаратном уровне таких компонентов, как вотчпойнты и брейкпойнты. Есть у такой реализации свои прелести, недоступные софту — и в новой статье YADRO на Хабре эти преимущества раскрыты в подробностях.ㅤㅤ Помимо глубокого погружения в аппаратную реализацию и поломки GDB, читателей ждет рецепт приготовления аппаратных брейкпойнтов с помощью Perf Events — фреймворка для профилирования и трассировки в ядре Linux. Прочитать →