🛡 Linux: Как запретить системе убивать твою Базу Данных (OOM Killer)

Ситуация: На сервере кончилась память (RAM). Ядро Linux включает механизм OOM Killer (Out Of Memory Killer), который, как санитар леса, начинает убивать самые "жирные" процессы, чтобы спасти систему. Чаще всего под нож попадает MySQL, PostgreSQL или Java-приложение. И сервер падает.

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

Как это сделать: У каждого процесса есть файл /proc/[PID]/oom_score_adj. Значения в нем: от -1000 (бессмертный) до 1000 (убить первым).

Защищаем процесс (например, SSH или БД):

# Находим PID (например, 1234)
# Записываем -1000 в score_adj
echo -1000 > /proc/1234/oom_score_adj

Как сделать это вечным (через Systemd): Добавьте в unit-файл сервиса (/etc/systemd/system/mysql.service.d/override.conf):

[Service]
OOMScoreAdjust=-1000

Теперь, даже если память кончится полностью, Linux убьет Apache, агенты мониторинга, cron, но Базу Данных будет держать до последнего байта.

#linux #kernel #oom #stability #systemd #bestpractice

🧹 Linux: Укрощаем journald. Как освободить место без удаления файлов?

Если /var/log забит, но logrotate настроен правильно, скорее всего, виноват systemd-journald. Он хранит бинарные логи, которые могут копиться годами и занимать гигабайты. Просто удалять файлы в /var/log/journal/ опасно — можно повредить базу.

Используйте встроенные механизмы очистки (vacuum).

1. Проверяем, сколько места занято:

journalctl --disk-usage
# Вывод: Archived and active journals take up 4.2G in the file system.

2. Освобождаем место (безопасно): Утилита сама удалит самые старые записи, чтобы вписаться в лимит.

# Оставить только последние 500 МБ
sudo journalctl --vacuum-size=500M

# Или оставить логи только за последние 10 дней
sudo journalctl --vacuum-time=10d

3. Как сделать это автоматическим: В файле /etc/systemd/journald.conf раскомментируйте и настройте параметр: SystemMaxUse=500M Теперь systemd сам будет следить за диетой.

#linux #systemd #journalctl #cleanup #maintenance #storage

🐧 Linux: Что упало, пока мы отдыхали? (systemctl --failed)

Вы заходите на сервер.
Аптайм есть, SSH работает.
Все ок? Не факт.
Возможно, второстепенный сервис (бэкап-агент, ротация логов, обновление сертификатов) тихо умер 2 января.

Не ищите иголку в стоге сена. Спросите systemd прямо.

Команда:

systemctl --failed

Что она покажет: Только те сервисы, которые находятся в статусе failed.

Как починить:

* Смотрим логи упавшего: journalctl -u service_name -n 50

* Перезапускаем: systemctl restart service_name

Важно: Если ошибка разовая и вы её исправили, сбросьте счетчик ошибок, чтобы список стал чистым:

systemctl reset-failed

Начинайте год с чистого листа (и чистого вывода systemd).

#linux #systemd #maintenance #troubleshooting #healthcheck

🐧 Linux: Спасаем базу данных от OOM Killer

Бывало такое?
Серверу не хватило памяти, пришел OOM Killer (Out of Memory) и убил... нет, не зависший PHP-скрипт, а твой основной PostgreSQL.
💀 Почему? Потому что БД потребляет больше всего памяти, и для ядра она выглядит как самый "жирный" кандидат на расстрел.

Решение: Настроить oom_score_adj. Это число от -1000 (бессмертный) до +1000 (убить первым).

Как защитить критический процесс: Находим PID процесса (например, postgres):

pgrep -f postgres | head -1

Запрещаем OOM Killer'у трогать его (ставим -1000):

echo -1000 > /proc/[PID]/oom_score_adj

Как сделать это вечным (в systemd): Добавьте в unit-файл сервиса (systemctl edit postgresql):

[Service]
OOMScoreAdjust=-900

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

#linux #kernel #oom #postgresql #sysadmin #reliability #systemd 🛡️

🐧 Linux: systemd-run — запускаем скрипты в «песочнице» на лету 🛡️

Запускаешь тяжелый бэкап или скрипт миграции и боишься, что он съест всю память и положит прод? Не нужно писать сложные unit-файлы. В 2026 году админы используют Transient Scopes (временные скоупы).

Команда systemd-run позволяет обернуть любую команду в полноценный сервис с лимитами ресурсов прямо из консоли.

Команда дня:

# Запускаем скрипт, даем ему максимум 500Мб RAM и низкий приоритет CPU
systemd-run --scope -p MemoryMax=500M -p CPUWeight=20 ./heavy_script.sh

Что происходит: Скрипт запускается как обычно, но ядро Linux (cgroups) держит его в жестких рукавицах. Если скрипт попытается съесть 501 Мб — он будет убит (OOM), но основной сервер даже не поперхнется.

Почему это топ: Это идеальный способ тестировать лимиты для будущих сервисов или безопасно запускать "одноразовые" задачи на живом проде. 🧠

#linux #systemd #cgroups #performance #sysadmin #safety #devops

🐧 Linux: systemd-analyze security — узнай, насколько дырявые твои сервисы 🛡️

Ты поднял Nginx, базу данных и пару самописных демонов.
Они работают.
Но насколько они защищены от взлома, если в коде найдется уязвимость?
В 2026 году systemd имеет встроенный сканер безопасности, о котором многие забывают.

Он анализирует unit-файлы и выставляет оценку "опасности" от 0 (безопасно) до 10 (проходной двор).

Команда-аудитор:

systemd-analyze security

Как исправить "красные" зоны:
Выбери сервис с плохой оценкой (например, nginx.service) и посмотри детали:

systemd-analyze security nginx.service

Добавь в секцию [Service] файла юнита простые директивы изоляции:

[Service]
PrivateTmp=yes              # Свой /tmp, невидимый другим
ProtectSystem=strict        # Запрет записи в системные папки
ProtectHome=yes             # Запрет чтения /home
NoNewPrivileges=yes         # Запрет повышения прав (sudo)

Результат: Даже если сервис взломают, хакер окажется в "тюрьме" и не сможет навредить системе. Оценка упадет с 9.0 до 2.0. ✅

#linux #security #systemd #hardening #sysadmin #devops #audit

🐧 Linux: Быстрый тюнинг дескрипторов — исправляем «Too many open files» 📂

Бывает, что сервис (особенно нагруженный Nginx или БД) начинает захлебываться и сыпать ошибками `Too many open files`. Это значит, что процесс уперся в лимит открытых файловых дескрипторов. В 2026 году ручное редактирование `limits.conf` — это долго.

Как быстро проверить лимиты конкретного процесса:

# Берем PID процесса (например, 1234) и смотрим его мягкие и жесткие лимиты
cat /proc/1234/limits | grep "Max open files"

Как изменить лимит «на лету» без перезапуска всей системы (через systemd):
Если сервис управляется через systemd, создаем override-конфиг:

sudo systemctl edit nginx

Добавляем в открывшийся файл:

[Service]
LimitNOFILE=65535

Затем: `systemctl daemon-reload` и `systemctl restart nginx`.

Зачем это нужно: Современные приложения открывают сотни соединений и временных файлов.
Стандартный лимит в 1024 — это «бутылочное горлышко», которое ты теперь умеешь расширять за минуту.

#linux #systemd #performance #optimization #sysadmin #admin_future

🐧 Linux: Когда `/var/log/journal` съел диск — правильная диета для логов 🧹

Классика жанра: мониторинг орет, что на корневом разделе осталось 0 байт. Ты лезешь разбираться и видишь, что системный журнал `systemd-journald` разросся до размеров Вселенной, храня логи за последние три года.

Удалять файлы руками через `rm` — плохая примета (можно сломать целостность журнала). Делаем красиво через штатные инструменты.

Команды для очистки:

# 1. Смотрим, сколько реально занимают логи
journalctl --disk-usage

# 2. Оставляем логи только за последние 2 дня (остальное в /dev/null)
sudo journalctl --vacuum-time=2d

# 3. ИЛИ ограничиваем жестким размером (например, оставить 500 МБ)
sudo journalctl --vacuum-size=500M

Админский лайфхак: Чтобы не чистить вручную каждый раз, пропиши в `/etc/systemd/journald.conf` параметр `SystemMaxUse=1G` и перезапусти службу.

#linux #systemd #logs #maintenance #sysadmin #troubleshooting #admin_future

🐧 Linux: systemd-run — запускаем тяжелые задачи в «песочнице» без лишних конфигов

Часто бывает нужно запустить скрипт или тяжелую задачу (например, пересборку логов или парсинг), но ты боишься, что она «отъест» все ресурсы у боевого веб-сервера. Создавать полноценный .service файл лень? Используй systemd-run.

Техническая суть:
Команда создает временный (transient) юнит и позволяет лимитировать ресурсы (CPU, RAM, I/O) «на лету» прямо из командной строки.

Команда для запуска с лимитом памяти в 500МБ:

# Запускаем скрипт в отдельном слайсе с жестким лимитом по памяти
sudo systemd-run --scope -p MemoryMax=500M -p CPUWeight=50 ./heavy-script.sh
# Посмотреть статус этого временного юнита
systemctl status run-*.scope

Зачем это нужно:
Это намного надежнее, чем просто nice или ionice.
Ты гарантируешь, что скрипт не уронит сервер по OOM (Out Of Memory), даже если в коде утечка.

#linux #systemd #optimization #performance #sysadmin #admin_future

🐧 Linux: Убиваем демонов. Rootless Podman и systemd-quadlets на страже серверов

В 2026 году крутить жирного демона Docker от пользователя `root` — это не просто моветон, это красная тряпка для любого аудитора ИБ. В условиях тотального импортозамещения и перехода на защищенные отечественные ОС мы давно изолируем всё, что шевелится.

Под капотом:
Мы выкидываем Docker daemon и переходим на rootless Podman. А чтобы не страдать с docker-compose и кривыми авторестартами, отдаем управление жизненным циклом контейнеров нативному systemd через механизм Quadlets. Вы просто пишете декларативный юнит .container, а systemd сам генерирует сервис, следит за зависимостями, пробрасывает порты и пишет логи в journald. И всё это работает в пространстве обычного пользователя!

Практика:
Создаем файл /etc/containers/systemd/nginx-gost.container для запуска веб-сервера с поддержкой отечественной криптографии:

[Unit]
Description=GOST-enabled Nginx Web Server
After=network-online.target

[Container]
Image=registry.corp.local/nginx-gost:latest
PublishPort=8080:80
Environment=TLS_MODE=strict
Volume=/srv/web:/usr/share/nginx/html:ro

[Install]
WantedBy=multi-user.target

Перезагружаем демона и стартуем:

systemctl daemon-reload
systemctl start nginx-gost.service

Зачем это нужно:
Если злоумышленник и пробьет ваш веб-сервер, он окажется заперт в непривилегированном user namespace. Нулевой риск компрометации ядра, идеальная интеграция с системными логами и чистая архитектура без лишних прослоек.

#linux #podman #systemd #security #admin_future

🐧 Linux: Забываем про sudo. Встречаем run0 от systemd

Коллеги, если вы думали, что systemd уже поглотил все что мог, то вы ошибались. В современных дистрибутивах разработчики добрались до святая святых — утилиты sudo. Встречайте: run0. В 2026 году это новый стандарт повышения привилегий.

Почему sudo устарел:

Классический sudo существует десятилетиями. Его главная проблема — он опирается на SUID-биты (Set-user-ID). Это огромная кодовая база, работающая с правами root. Любая уязвимость в sudo — это моментальный взлом всей системы, что мы уже не раз наблюдали в истории кибербезопасности.

Как работает run0:

— Без SUID: run0 вообще не использует SUID-бинарники.
— Временная песочница: Он просит диспетчер служб systemd создать временный изолированный контекст (pty) и запускает процесс там.
— Интеграция с polkit: Права проверяются через штатный механизм polkit, а не через громоздкий конфигурационный файл sudoers.
— Визуальный контроль: Когда вы работаете через run0, терминал меняет цвет фона (например, на красноватый оттенок), чтобы вы физически видели, что находитесь в режиме бога и любые команды могут быть фатальны.

Как попробовать:
Если у вас дистрибутив с systemd версии 256 и выше, просто напишите в консоли:

run0 bash

Эра sudo медленно, но верно уходит. Меньше кода, меньше площадь атаки, больше интеграции с базовой системой. Привыкаем к новому синтаксису и безопасному повышению прав.

#linux #systemd #run0 #security #sysadmin #admin_future

🐧 Linux: systemd 260 убил SysV — и если у тебя ещё живёт /etc/init.d, читай срочно

Коллеги, 17 марта 2026 года вышел systemd 260 — и он сделал то, о чём предупреждали несколько лет. Наиболее разрушительное изменение: полное удаление поддержки System V init-скриптов. Компоненты systemd-sysv-generator, systemd-sysv-install и rc-local.service удалены окончательно. Никакого мягкого устаревания — мост сожжён.

Если у вас в продакшне живут legacy-сервисы со скриптами в /etc/init.d/ — они тихо перестанут запускаться после обновления. Без ошибок в журнале. Просто не стартуют.

Но в этом же релизе есть кое-что интересное: добавлен новый параметр MemoryTHP= для управления Transparent Huge Pages на уровне отдельного сервиса, а CPUSchedulingPolicy= теперь поддерживает значение ext для включения планировщика SCHED_EXT. Для высоконагруженных сервисов — это прямой рычаг тонкой настройки без правки параметров ядра глобально.

Сначала — аварийный аудит. Находим всё, что ещё на SysV:

# Ищем живые SysV-скрипты в системе
find /etc/init.d/ -type f -not -name "README" 2>/dev/null

# Проверяем, нет ли сервисов без native unit-файла
# (до обновления на systemd 260 — sysv-generator ещё конвертировал их)
systemctl list-units --type=service --state=loaded | grep -v ".service"

# Смотрим, какие сервисы СЕЙЧАС запущены через SysV-совместимость
systemctl list-units --type=service | \
  while read unit _; do
    unit_file=$(systemctl show "$unit" -p FragmentPath --value 2>/dev/null)
    [[ "$unit_file" == /etc/init.d/* ]] && echo "LEGACY SysV: $unit -> $unit_file"
  done

# Для найденного legacy-сервиса пишем нормальный unit.
# Пример: конвертируем старый /etc/init.d/myapp
cat > /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Legacy Application
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/myapp --daemon
ExecStop=/usr/local/bin/myapp --stop
PIDFile=/var/run/myapp.pid
Restart=on-failure
RestartSec=5s

# Новое в systemd 260: тонкая настройка памяти для сервиса
# Отключаем THP для Java-приложений (они его не любят)
MemoryTHP=never

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now myapp.service
systemctl status myapp.service

Зачем это нужно:
Сервисы, у которых нет native unit-файлов, после обновления на systemd 260 не запустятся тихо и без предупреждений. Самый критичный action item для всех администраторов — провести аудит и мигрировать оставшиеся SysV init-скрипты до обновления. Ubuntu 26.04 LTS выходит 23 апреля и несёт systemd 260 по умолчанию. Срок — неделя.

Итог: SysV жил с 1983 года. Хватит. Если у тебя до сих пор есть /etc/init.d/что-то — это не legacy, это пожарная опасность. Миграция на unit-файл занимает 15 минут. Объяснение инциденту на встрече с Романом — значительно дольше.

#linux #systemd #sysv #sysadmin #ubuntu #admin_future

🐧 Linux: systemd hardening — твои сервисы запущены в привилегиях которые им не нужны

Коллеги, большинство unit-файлов в продакшне выглядят так: Type=simple, ExecStart=..., Restart=on-failure — и всё. Сервис запускается с правами процесса, может писать куда угодно, видит всю файловую систему и весь сетевой стек. Это нормально для 2010 года.

В systemd 260 (Ubuntu 26.04, Fedora 44) появились дополнительные директивы изоляции и Memory THP-контроль на уровне юнита. Но главное — большинство директив безопасности были доступны давно, просто их не используют.

# Оцениваем текущий security score сервиса
systemd-analyze security nginx
# Покажет оценку от 0 (UNSAFE) до 10 (SAFE) и что именно проседает

# Добавляем hardening в override без правки оригинального юнита:
systemctl edit nginx

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
# Приватная /tmp — сервис не видит /tmp хоста
PrivateTmp=true

# Запрет на запись в домашние директории
ProtectHome=true

# /usr, /boot, /etc монтируются read-only
ProtectSystem=strict

# Разрешаем писать только в нужные директории
ReadWritePaths=/var/log/nginx /var/cache/nginx /run/nginx

# Убираем все capabilities кроме нужных
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# Запрет на новые привилегии через setuid/setgid
NoNewPrivileges=true

# Только нужные syscall-группы
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

# Изолируем сетевые namespace-ы (если сервис только слушает)
# PrivateNetwork=true  # раскомментировать для полной изоляции

# Контроль памяти (новое в systemd 260)
# Отключаем THP для сервисов где он мешает (Java, Redis)
MemoryTHP=never

# После правки:
systemctl daemon-reload && systemctl restart nginx

# Проверяем новый score
systemd-analyze security nginx
# Цель: зелёный (8+)

Зачем это нужно:
Скомпрометированный nginx с PrivateTmp и ProtectSystem=strict не доберётся до ваших SSH-ключей, конфигов баз данных или других сервисов. Изоляция на уровне юнита — это дешёвый слой defence-in-depth, который не требует контейнеров.

Итог: запусти systemd-analyze security на своих сервисах сегодня. Гарантирую — будет неприятно, но полезно.

#linux #systemd #hardening #security #sysadmin #admin_future

🐧 Linux: Хватит терпеть зависания при OOM. Включаем PSI и systemd-oomd

Коллеги, добрый понедельник. Знакомая ситуация: на сервере потекла память, своп забился, load average улетел в космос, и вы даже по SSH зайти не можете. Классический OOM Killer в ядре срабатывает слишком поздно, когда система уже фактически в коме.

В 2026 году мы решаем это изящнее. Мы используем PSI (Pressure Stall Information) вместе с systemd-oomd. Этот демон убивает прожорливые cgroups ДО того, как операционная система намертво повиснет.

Скрипт для проверки и активации:

# Проверяем, включен ли PSI в ядре (вывод не должен быть пустым):
cat /proc/pressure/memory

# Если включен, активируем службу systemd-oomd:
systemctl enable --now systemd-oomd

# Смотрим статус и кто сейчас под угрозой:
oomctl status

Зачем это нужно:
Сервер должен оставаться управляемым при любых утечках памяти. Лучше пусть упадет один проблемный контейнер или веб-сервис, чем вся нода уйдет в hard reset по питанию, утащив за собой соседние процессы.

#linux #systemd #oom #performance #sysadmin #admin_future