LinuxCamp | DevOps

bottom (btm): мониторинг системы с гибкой визуализацией bottom, сокращённо btm, это TUI-утилита для мониторинга состояния системы. По задачам она пересекается с top и htop: загрузка CPU, использование памяти, диск, сеть, процессы. Отличие в том, что btm сразу ориентирован на графическое представление данных в терминале и гибкую компоновку экрана. Установка

sudo apt install bottom

После установки утилита запускается командой btm. Как работает При запуске btm открывает интерактивный интерфейс с несколькими блоками: CPU, память, swap, диск, сеть, список процессов. Блоки можно скрывать, менять их порядок и переключать режимы отображения с клавиатуры, без редактирования конфигов.

btm

Для серверов и Docker-хостов полезен режим с упором на процессы и нагрузку, где видно PID, пользователя, потребление CPU и памяти в реальном времени.

btm -b

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

hyperfine: замер времени выполнения команд hyperfine - это утилита для бенчмаркинга команд в Linux. Она запускает одну или несколько команд много раз и измеряет время выполнения. В отличие от time, здесь сразу считаются среднее значение, минимальное и максимальное время, стандартное отклонение. Учитываются прогрев и шум системы. Установка В Ubuntu утилита доступна в официальных репозиториях.

sudo apt install hyperfine

После установки команда hyperfine доступна без дополнительной настройки. Базовое использование Простейший случай это замер одной команды. hyperfine сам выполнит несколько прогонов и выведет агрегированную статистику.

hyperfine "ls -R /usr/share >/dev/null"

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

hyperfine "grep -R foo ." "rg foo ."

В этом режиме вывод сразу показывает разницу по времени и разброс значений, что удобно для принятия технических решений. Вывод hyperfine предназначен для воспроизводимых замеров производительности команд. Подходит для сравнения CLI-утилит, флагов запуска, скриптов и небольших изменений в пайплайнах, где важно видеть реальные цифры, а не разовый запуск через time. LinuxCamp | #utils

Новый удобный df: duf duf - это консольная утилита для просмотра использования файловых систем в Linux. По назначению она повторяет df, но выводит информацию в структурированном виде, поддерживается цветовая индикация. Установка на Ubuntu В Ubuntu duf доступен в официальном репозитории. Установка стандартная, без сторонних источников и сборки из исходников.

sudo apt install duf

После установки команда duf становится доступна глобально. Основные режимы работы Запуск без параметров показывает все примонтированные файловые системы, включая tmpfs, loop-устройства, overlay и сетевые маунты. Это удобно для анализа систем с контейнерами и снапами.

duf

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

duf --only local

Дополнительно duf умеет сортировать вывод, скрывать псевдо-файловые системы и работать одинаково в интерактивных и скриптовых сценариях. Вывод duf - это современная замена df с тем же назначением и расширенным форматом вывода. Подходит для рабочих станций и серверов, особенно в окружениях с большим количеством примонтированных файловых систем. LinuxCamp | #utils

Все в Linux должно быть как Windows В GNOME решили отключить вставку по среднему клику мыши. И чем дальше, тем страннее становятся их аргументы. Во-первых, основная причина — это «X11ism». То есть, функция им не нравится, потому что она родом из X11, а к X11 у них политические претензии. Но потом они попытались найти более «техническое» обоснование. И, кажется, пришли к выводу, что Linux должен работать в точности как Windows.

«У Linux-десктопа 4% рыночной доли» «А значит, оставшиеся 96% пользователей привыкли к средам, где… вставки по среднему клику не существует». — один из участников команды.

Вообще, мысли на счет того, что нужно быть похожими на винду - верные. Но, как по мне, это имеет вес на более глобальном функционале, а не на способе вставки текста... LinuxCamp | #news

ExecStartPre / ExecStartPost: хуки для systemd Что это такое ExecStartPre и ExecStartPost - это команды, которые systemd выполняет до и после запуска сервиса.

ExecStartPre=
ExecStart=
ExecStartPost=

Важно: если ExecStartPre вернёт non-zero, то сервис не запустится вообще. Самая частая ловушка Pre-хук выглядит безопасным, но падает:

ExecStartPre=/usr/bin/curl http://127.0.0.1:9000/health

Если сервис на 9000 ещё не поднят, curl вернёт код ошибки, systemd считает, что сервис сломан, и даже не дойдёт до ExecStart. Pre-хук выполняется каждый раз при старте, включая рестарты. Любая временная проблема: сеть, DNS, файл, env превращается в стоппер сервиса. В логах:

journalctl -u myservice

ExecStartPre failed with exit code 7

Типичные ошибки:

ExecStartPre=/bin/mkdir /var/run/app
ExecStartPre=/usr/bin/test -f /config/app.yml
ExecStartPre=/usr/bin/psql -c "select 1"

Для post-хуков помни, если ExecStartPost падает, значит сервис уже запущен, но unit помечается как failed. Практическое правило ExecStartPre - только для быстрых, гарантированных операций (создать каталог, выставить права, подготовить env). Все, что зависит от сети, БД, других сервисов лучше выносить в код сервиса. Вывод ExecStartPre - это точка отказа, если одна команда упала, то сервис не стартует. Если хук может упасть либо гаси ошибку, либо убирай его совсем. LinuxCamp | #utils

🖥 На Stepik вышел курс, который учит работать с Docker на реальных проектах. Владение Docker - навык, который отличает новичка от профи, Сегодня почти всё разворачивается в контейнерах. Если ты не умеешь работать с Docker, ты медленнее, зависим от чужих настроек и постоянно ловишь баги «у меня локально работает». • как упаковывать проекты в контейнеры • как поднимать целые системы за минуты • как избегать типичных ошибок в продакшене • как делать стабильные и повторяемые окружения •в нем разобраны все возможные ошибки Только практика и реальные кейсы от авторов Docker Академии- с нуля до уверенного уровня. 🎁 Скидка 40 процентов действует 48 часов 👉 Записывайся и сделай Docker своим настоящим рабочим инструментом.

TCP TIME_WAIT: нормально ли это Что это и зачем TIME_WAIT - состояние TCP, в котором сокет некоторое время живёт после закрытия соединения. Это нужно, чтобы гарантировать доставку финальных пакетов и не допустить повторного использования старых sequence numbers. Как посмотреть и когда это важно Количество сокетов в TIME_WAIT видно так:

ss -tan | grep TIME-WAIT | wc -l

Проблемой это становится только тогда, когда новые соединения перестают создаваться. Обычно происходит, когда закончились ephemeral ports. Это временные клиентские порты, которые ядро автоматически выделяет для исходящих соединений. Их диапазон можно посмотреть здесь:

cat /proc/sys/net/ipv4/ip_local_port_range

Если диапазон узкий и соединения короткие, порты быстро оказываются заняты TIME_WAIT. Почему их становится много Короткие HTTP-соединения, отсутствие keep-alive, прокси, балансировщики, высокая RPS, микросервисы, healthchecks - все это создает тысячи короткоживущих TCP-сессий. В этом сценарии большое количество TIME_WAIT признак нагрузки, а не поломки. Что делать безопасно Обычно ничего. Если упираешься в лимиты, расширяют диапазон ephemeral ports и разрешают повторное использование TIME_WAIT для клиентов:

sysctl -w net.ipv4.ip_local_port_range="10240 65535"
sysctl -w net.ipv4.tcp_tw_reuse=1

Главное решение все равно на уровне приложения: keep-alive, connection pool, HTTP/2. Вывод TIME_WAIT - это нормальное состояние TCP. Пока есть свободные ephemeral ports, система работает корректно. Если они заканчиваются, то масштабируй диапазон портов и соединения, а не пытайся лечить TCP. LinuxCamp | #utils

Как продебажить сеть в контейнере если в нём не хватает утилит? Иногда слышу вопросы от коллег типа: "Как выполнить какой-нибудь запрос из контейнера, если в нём нет curl?". Или: "Как снять дамп из контейнера, если в нём нет tcpdump?". Есть один очень простой способ, как выполнить любую команду внутри сети контейнера. Единственное, что вам понадобится, это доступ с root-правами к хосту. 1. Находим PID процесса контейнера. Обычно для этого достаточно выполнить ps aux | grep "команда запуска вашего контейнера", но если контейнеров запущенной одной и той же командой на хосте много, то лучше воспользоваться CLI вашего рантайма (типа crictl) для опредленя PID'а нужного контейнера. 2. Заходим в сетевой неймспейс этого процесса через команду nsenter -n -t $PID, где -n значит network. Всё. Можете проверить, что вы там, где нужно, введя команду ip a. Это очень полезный метод, когда вам либо самим нужно что-то проверить, либо когда нужно доказательство клиенту, что с трафиком из контейнера 100% всё порядке. Между инцидентами Реклама. Давыдов И.А. ИНН 775108336633. erid: 2W5zFGaTMax

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/+bvm7z2T8sPlkMDAy

zombie и orphan процессы: кто их чистит и когда это проблема Что такое 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

slab и slub: куда уходит память ядра slab и slub - это аллокатор памяти ядра. Он кэширует структуры ядра, чтобы не выделять и не освобождать память постоянно. Из-за этого память может выглядеть занятой, хотя пользовательские процессы её не используют. Быстрая диагностика Смотрим общее потребление slab:

grep Slab /proc/meminfo

Детализация по кэшам:

slabtop

Здесь видно, какие структуры ядра занимают память: dentry, inode, kmalloc-*, sock, buffer_head и т.д. Почему появляется соблазн чистить кэш При высокой файловой активности slab растёт и визуально съедает RAM. В free кажется, что памяти почти нет, хотя это нормальное поведение. В такие моменты часто вспоминают про drop_caches. Почистить кеш можно командой:

sync
echo 2 | sudo tee /proc/sys/vm/drop_caches

sync принудительно сбрасывает грязные данные на диск, после чего ядро освобождает dentry, inode и другие slab-структуры. Память освобождается сразу. Зачем это используют на практике Команду применяют для диагностики, чтобы понять, кэш это или утечка. Если после очистки slab резко уменьшается - это нормальный кэш. Если он быстро возвращается без нагрузки, значит возможна проблема в ядре, драйвере или модуле. Какие проблемы будут после выполнения После очистки кэша первые файловые операции становятся медленнее, увеличивается latency, возрастает нагрузка на диск, сервисы с активным I/O могут кратковременно тормозить. На проде это может быть заметно пользователям. Вывод drop_caches - это диагностический инструмент, а не оптимизация. Использовать его стоит осознанно, с sync перед выполнением и пониманием того, что система после команды станет временно медленнее. LinuxCamp | #utils

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

Релиз Kali Linux 2025.4 Ключевое изменение - произошел полный переход графической среды GNOME на Wayland. Сеансы X11 теперь работают только через XWayland. Что нового: — Дистрибутив обновлён до ядра Linux 6.16 и GNOME 49 — Добавлены новые утилиты: bpf-linker для работы с BPF, evil-winrm-py для удалённого управления Windows и hexstrike-ai (MCP-сервер для ИИ-агентов) — Улучшена поддержка гостевых утилит для VirtualBox, VMware и QEMU под Wayland Из-за возросшего размера образа Live (более 5 ГБ) разработчики отказались от его прямой HTTP-загрузки. Теперь полный образ доступен только через BitTorrent, что уже практиковалось для 15-гигабайтного варианта «Everything». LinuxCamp | #news