KDE отказывается от X11

Команда KDE Plasma объявила о начале новой эры в развитии рабочего стола: в релизе Plasma 6.8 будет полностью прекращена поддержка сессии X11, и рабочее окружение станет эксклюзивно работать на Wayland.

Поддержка приложений X11 будет осуществляться через совместимый слой Xwayland, а сама сессия Plasma X11 будет исключена из дистрибутивов.

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

По статистике 73% юзеров Plasma 6 используют Wayland, а не X11, такие дела... Рано или поздно X11 вымрут окончательно.

LinuxCamp | #news

Как cgroups v2 реально ограничивает CPU, память и IO

Что такое cgroups v2

cgroups v2 - это механизм ядра, который делит ресурсы системы между группами процессов. Для каждой группы ядро считает и ограничивает CPU, память, дисковый и сетевой IO. Всё управляется через файловую систему /sys/fs/cgroup.

Проверить, используется ли v2:

mount | grep cgroup2
cat /sys/fs/cgroup/cgroup.controllers

Иерархия и контроллеры

Все группы - это директории внутри /sys/fs/cgroup. В каждой можно включить контроллеры и настроить лимиты. Процесс "попадает" в cgroup, когда его PID записывают в файл cgroup.procs.

Пример создания отдельной группы вручную:

cd /sys/fs/cgroup
mkdir test.slice
echo "+cpu +memory +io" > cgroup.subtree_control
cd test.slice
echo $$ > cgroup.procs    # добавить текущий shell

Ограничение CPU

CPU в v2 настраивается через квоту и период. Так ядро решает, какую долю от одного ядра может использовать группа. Пример: не более 50% одного CPU:

echo "100000" > cpu.max    # период 100 мс
echo "50000"  >> cpu.max   # квота 50 мс

Для полного запрета ограничения (no throttle):

echo "max" > cpu.max

Ограничение памяти

Ядро отслеживает все страницы памяти группы и сравнивает их с лимитом. При превышении включается reclaim, а в крайнем случае OOM внутри cgroup. Пример жёсткого лимита 512 МБ:

echo $((512 * 1024 * 1024)) > memory.max

Текущие значения и пики:

cat memory.current
cat memory.events

Ограничение дискового IO

Контроллер io задаёт лимиты на чтение и запись для конкретных устройств. Ядро контролирует количество операций и суммарную пропускную способность. Пример: ограничить чтение до 10 МБ/с для /dev/sda:

echo "8:0 rbps=10485760" > io.max

Узнать номера устройств:

lsblk --output NAME,MAJ:MIN

Вывод

cgroups v2 - это единая иерархия, где для каждой директории можно включить контроллеры CPU, памяти и IO, добавить процессы и задать жёсткие лимиты. Всё управление сводится к записи чисел и параметров в файлы внутри /sys/fs/cgroup, а дальше ядро само выполняет политику.

LinuxCamp | #overview

Почему показатели нагрузки кажутся странными и чем помогает htop

CPU% и несколько ядер

Показатель %CPU у процесса это доля одного логического ядра, а не всей системы. На машине с 8 ядрами суммарный %CPU может быть больше 100%, это нормально. Сначала смотрим, сколько вообще ядер:

nproc
lscpu | grep '^CPU(s):'

Затем открываем htop и включаем отображение по ядрам, чтобы понимать распределение нагрузки.

htop

load average не процент загрузки

load average показывает среднее количество процессов, которые либо выполняются, либо ждут CPU или I/O. Это не процент и не "нагрузка процессора". Значение 4.0 на 4 ядрах означает, что в среднем одновременно 4 задачи хотят работать.

uptime
cat /proc/loadavg

Если load примерно равен числу ядер система работает в нормальном режиме. Если намного выше, значит есть очередь на CPU или на диск.

Steal time и работа в виртуалках

В htop есть поле st в строке CPU. Это время, когда ваша виртуальная машина хотела получить CPU, но гипервизор отдал его другим. Если st заметно выше нуля, а сама нагрузка небольшая, узкое место не в вашем приложении, а в окружении.

IOWait и зависания из-за диска

Поле wa (iowait) показывает, сколько времени CPU простаивает в ожидании диска или сети. Высокий wa при невысоком %CPU и большом load average означает, что проблема в I/O. Для проверки дисков удобно использовать iostat:

iostat -x 1

Как смотреть нагрузку

Корректный минимум: понять число ядер и текущий load, затем посмотреть разбиение CPU по user/system/iowait/steal и проверить диск.

nproc
uptime
htop
iostat -x 1

Если эти команды анализировать вместе, показания htop перестают выглядеть странными и становится ясно, где именно упирается система: в CPU, диск, память или виртуализацию.

LinuxCamp | #utils

dmesg: что реально можно увидеть в логах ядра

Зачем нужен dmesg

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

Использование

Показать последние события ядра:

dmesg | tail -n 30

С фильтром по ошибкам:

dmesg -T | grep -i error

Живой вывод, как tail -f:

dmesg -w

Пример реальной проблемы

Сервер начал подвисать и рандомно отключать сетевой интерфейс. Система молчит, journalctl не даёт понятных подсказок. Смотрим dmesg:

dmesg -T | grep -i eth0

И видим:

[Mon Dec  1 10:15:12 2025] e1000e 0000:00:19.0 eth0: EEPROM corrupted
[Mon Dec  1 10:15:13 2025] eth0: link down
[Mon Dec  1 10:15:14 2025] eth0: link up

Причина - умирающий сетевой адаптер или битый firmware/EEPROM. Без dmesg найти такое почти невозможно: приложение думает, что сеть просто пропадает.

Ещё один пример: проблемы с диском

dmesg -T | grep -i "read error"

Вывод:

blk_update_request: I/O error, dev sda, sector 1587840

Ядро сообщает, что диск не может прочитать сектор,это верный признак начала деградации.

Вывод

dmesg - это прямой канал общения с ядром. Если проблема связана с железом, драйверами, памятью, сетевыми интерфейсами или файловой системой, то почти всегда подсказка лежит именно здесь.

LinuxCamp | #utils

fdisk: базовый инструмент разметки дисков в Linux

Зачем нужен fdisk

fdisk управляет таблицей разделов на диске: показывает структуру, создаёт и удаляет разделы, меняет типы и метки. Работает с MBR и GPT-таблицами. Это утилита низкого уровня без файловых систем и монтирования.

Просмотр структуры диска

Показать все устройства:

fdisk -l

Информация по конкретному диску:

sudo fdisk -l /dev/sda

Вывод покажет размер, таблицу разделов, типы, смещения и флаги.

Работа в интерактивном режиме

Для изменения разметки диска:

sudo fdisk /dev/sdb

(важно: быть аккуратным и убедиться, что выбран правильный диск) Команды внутри fdisk:

p  — показать текущие разделы
n  — создать новый раздел
d  — удалить раздел
t  — изменить тип
w  — записать изменения и выйти
q  — выйти без сохранения

Пример использования

Создаём новый раздел на дополнительном диске /dev/sdb:

sudo fdisk /dev/sdb
# внутри:
n        # новый раздел
p        # primary
1        # номер
<enter>  # старт по умолчанию
<enter>  # конец по умолчанию
w        # записать (осторожно!)

Форматируем:

sudo mkfs.ext4 /dev/sdb1

Монтируем:

sudo mount /dev/sdb1 /var/log2

Вывод

fdisk - это точный и простой инструмент для управления таблицей разделов. Работает надёжно, но требует аккуратности: изменения сразу затрагивают структуру диска, поэтому перед записью (w) всегда проверяй, что работаешь именно с нужным устройством.

LinuxCamp | #utils

iperf3: как понять, тормозит канал или сервер

Что делает iperf3

iperf3 даёт реальную пропускную способность сети между двумя машинами. Измеряет не "скорость интернета", а скорость между конкретными хостами. Это лучший способ понять, где bottleneck: у провайдера, в маршруте или в самом сервере.

Быстрый старт

На сервере поднимаем слушатель:

iperf3 -s

На клиенте запускаем тест:

iperf3 -c <SERVER_IP>

Вывод покажет фактический throughput, передачу по секундам и retransmits.

TCP или UDP

TCP-тест:

iperf3 -c <IP> -t 10

Показывает реальную пропускную способность как для обычных приложений: учитывает RTO, congestion control и потери.

UDP-тест:

iperf3 -c <IP> -u -b 1G

Используем, когда нужно понять максимальную теоретическую пропускную способность и jitter. Вывод:

UDP Jitter: 1.23 ms
Loss: 2%

Высокий jitter и потери → проблемы маршрута или перегруз канала.

Пример реальной диагностики

Пользователь жалуется, что сервис долго отвечает. На сервере всё нормально, CPU не загружен. Проверяем TCP:

iperf3 -c <SERVER_IP>

Видим:

[  5]   0.00-10.00  sec   42.0 MBytes  35.2 Mbits/sec  120 retransmits

120 повторных отправок это много. Проблема не в приложении, а в канале: пакетная потеря, слабый Wi-Fi, либо провайдер режет TCP-окна. Проверяем UDP:

iperf3 -c <SERVER_IP> -u -b 300M

Loss: 15%   Jitter: 5 ms

Подтверждение: канал нестабилен.

Вывод

iperf3 - это честная проверка сети. TCP-тест показывает реальное поведение приложений, UDP-тест раскрывает проблемы: jitter, потери, нестабильность. Когда непонятно, сервер тормозит или канал начинаем именно с iperf3.

LinuxCamp | #utils

Opensource в каждый офис

Германская земля Шлезвиг-Гольштейн приняла решение отказаться от Microsoft Office 365 в пользу LibreOffice и другого открытого ПО, что приведёт к значительной экономии бюджета и повышению суверенитета данных.

Такой переход позволит экономить более 15 млн евро ежегодно. Сейчас выполнена миграция 80% рабочих мест.

Кроме того, запланирован инвестиционный вклад в размере 9 млн евро, который направлен на завершение миграции и развитие открытых решений.

LinuxCamp | #news

Сетевые неймспейсы: изолируем сетевой стек в три команды

Что такое netns

Сетевой namespace - это отдельный сетевой стек: свои интерфейсы, маршруты, iptables, локальные порты.

Создаём изолированный сетевой стек

Создаём namespace:

sudo ip netns add testns

Проверяем:

ip netns list

Пустой стек без интерфейсов, кроме lo.

Добавляем виртуальный линк

Соединяем основной namespace и testns:

sudo ip link add veth0 type veth peer name veth1
sudo ip link set veth1 netns testns

Назначаем адреса:

sudo ip addr add 10.10.0.1/24 dev veth0
sudo ip netns exec testns ip addr add 10.10.0.2/24 dev veth1

Включаем интерфейсы:

sudo ip link set veth0 up
sudo ip netns exec testns ip link set veth1 up
sudo ip netns exec testns ip link set lo up

Проверяем связь

Из основного пространства:

ping -c 3 10.10.0.2

Из изолированного:

sudo ip netns exec testns ping -c 3 10.10.0.1

Для чего это в реальности

Тестирование сетевых конфигов, iptables, VPN-клиентов, сервисов, бинарей, маршрутизации без ломания системы. Поднимаешь неймспейс, гоняешь сервис внутри:

sudo ip netns exec testns curl http://10.10.0.1:8080

И не трогаешь основной стек.

Вывод

Сетевые неймспейсы дают чистую сетевую песочницу. Три команды и у вас отдельная "мини-сеть" для экспериментов, тестов и отладки, без виртуалок и контейнеров.

LinuxCamp | #utils

tune2fs: куда пропало место и почему это нормально

Что показывает Reserved block count

Reserved block count - это блоки ext4, зарезервированные под root. По умолчанию около 5% диска. На больших RAID это десятки гигабайт, и это ожидаемо. Посмотреть сколько зарезервировано:

sudo tune2fs -l /dev/md2 | grep "Reserved block count"

Зачем нужен резерв

Резерв позволяет системе работать, даже если диск заполнен: писать логи, логиниться под root, корректно завершать сервисы. Убирая его полностью, ты сознательно снижаешь устойчивость системы к авариям.

Когда можно уменьшать

На разделах с данными (/var, /data, /srv) резерв обычно не критичен. На системном разделе (/) его лучше оставить хотя бы минимальным. Уменьшение до 1%:

sudo tune2fs -m 1 /dev/md2

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

К чему может привести неправильная настройка

Нулевой резерв на системном диске может привести к ситуации, когда система не сможет писать логи или корректно стартовать сервисы при заполнении диска. Это не поломка сразу, а потеря запаса прочности.

Вывод

tune2fs безопасен при осознанном использовании. Менять параметры ext4 можно и нужно, но только понимая, что ты жертвуешь отказоустойчивостью ради дополнительного места.

LinuxCamp | #utils

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

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

Чтобы не было вопросов, нужно на каждой системе, где он юзается писать "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