Когда кто-то говорит:

да кому вообще нужен ваш линукс

Чтобы не было вопросов, нужно на каждой системе, где он юзается писать "Powered by linux"

LinuxCamp | #memes

fsck и счётчик монтирований: как управлять лимитом проверок

Что за лимит монтирований

В ext4 есть счётчик монтирований. Когда он достигает Maximum mount count, при следующей загрузке запускается fsck. Проверка текущих значений:

sudo tune2fs -l /dev/sda1 | grep -E "Mount count|Maximum mount count"

Почему fsck может мешать

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

Как увеличить лимит

Если нужно реже запускать проверку, лимит можно поднять:

sudo tune2fs -c 500 /dev/sda1

Это значит, что fsck сработает только после 500 монтирований. При необходимости можно сбросить текущий счётчик:

sudo tune2fs -C 0 /dev/sda1

Важное про безопасность

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

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

Вывод

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

LinuxCamp | #utils

atime, relatime, noatime: зачем это вообще нужно

Что такое atime

atime - это время последнего доступа к файлу. Каждое чтение файла обновляет метаданные. Даже обычный cat, grep или ls может вызвать запись на диск. Проверить режим монтирования можно так:

mount | grep atime

Почему atime это проблема

Обновление atime - дополнительная запись. Исторически atime был включён всегда, и это реально било по производительности.

Компромисс - relatime

relatime обновляет atime не всегда, а только если atime старше mtime или ctime, или прошло больше 24 часов Это дефолт почти во всех современных дистрибутивах. Пример:

UUID=... / ext4 defaults,relatime 0 1

В большинстве случаев это лучший баланс между корректностью и производительностью.

noatime - максимум производительности

noatime полностью отключает обновление atime. Используется для: /var, /data, базы данных, кэшей, логов

UUID=... /data ext4 defaults,noatime 0 2

Когда atime все-таки нужен

Некоторые утилиты и сценарии зависят от atime: почтовые системы, старые бэкапы, системы очистки неиспользуемых файлов. С noatime такая логика ломается.

Вывод

atime - это не архаизм, а механизм, который нужно контролировать. relatime подходит почти всегда. noatime - осознанная оптимизация для data-разделов. Менять режим стоит только понимая, что именно ты ускоряешь и чем жертвуешь.

LinuxCamp | #utils

Релиз 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

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

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

Действительно, как же не хватает в ОС рекламы и напоминаний о таких знаковых днях, как "Национальный день пиццы")

Как бы вы отнеслись к тому, что Linux дистры начали бы пушить рекламу? Как быстро бы снесли образ либо перешли на cli?

LinuxCamp | #memes

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

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

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