“Too many open files”: куда утекают дескрипторы

Сервисы начинают сыпать ошибками:

EMFILE: Too many open files

Но ulimit -n вроде нормальный. Что происходит?

⏺Причина:

Открытые файлы — это не только обычные файлы, но и сокеты, пайпы, устройства.

У каждого процесса есть лимит на количество открытых дескрипторов (nofile). При его превышении начинаются ошибки.

Проверка лимитов

ulimit -n                # лимит текущей сессии
cat /proc/$$/limits      # все лимиты текущего процесса

⏺Поиск виновника
Показываем процессы с наибольшим числом открытых файлов:

for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  count=$(ls /proc/$pid/fd 2>/dev/null | wc -l)
  echo "$count $pid"
done | sort -nr | head

Смотрим, что именно открыто у подозреваемого:

ls -l /proc/<PID>/fd

⏺Что делать?

Если утекают дескрипторы — проверьте код, особенно вызовы open() и close().

Если активно растёт число сетевых соединений — проверьте, не остаются ли открытые сокеты:

netstat -anp | grep <PID>

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

# Временно
ulimit -n 65535

# Постоянно — /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535

Для systemd-сервисов:

[Service]
LimitNOFILE=65535

Когда sshd пускает всех: настройка ограничения доступа по IP и ключам

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

Как быстро проверить и настроить безопасный доступ?

1️⃣Проверяем текущие подключения и логи SSH

ss -tnpa | grep sshd
journalctl -u sshd -e

Смотрим, кто подключается и есть ли ошибки аутентификации.

2️⃣Ограничиваем доступ по IP в sshd_config

Добавьте в /etc/ssh/sshd_config:

AllowUsers [email protected].*
DenyUsers user2@*

Или используйте AllowGroups с похожим синтаксисом.

3️⃣ Разрешаем доступ только по ключам, отключаем пароль

PasswordAuthentication no
PubkeyAuthentication yes

4️⃣ Проверяем разрешённые ключи в ~/.ssh/authorized_keys

Убедитесь, что ключи корректные и права на папку и файл строго выставлены:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

5️⃣ Перезапускаем sshd

systemctl restart sshd

6️⃣ Тестируем подключение с нужных IP и с ключами

Если не работает — запускайте ssh с повышенной детализацией:

ssh -vvv user@server

7️⃣ При подозрениях — включаем дополнительный лог в sshd_config:

LogLevel VERBOSE

Это поможет понять, почему соединение не проходит.

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает oom-killer в Linux и как с ним работать, чтобы минимизировать негативные последствия?

✅Ответ: oom-killer (Out-Of-Memory Killer) — это механизм ядра Linux, который срабатывает, когда системе не хватает оперативной памяти, и она не может выделить память ни одному из процессов. В такой ситуации oom-killer выбирает и завершает “наименее ценную” с точки зрения ядра задачу, чтобы освободить ресурсы.

Как с ним работать:

— Поведение можно контролировать с помощью параметра oom_score_adj. Чем выше значение (макс. 1000), тем выше вероятность, что процесс будет убит.
— Можно настроить cgroups и ограничить память для отдельных групп процессов, чтобы сбои не затрагивали всю систему.
— Желательно использовать swap-файл/раздел, чтобы отложить момент срабатывания OOM, но не полагаться на это как на основную защиту.

Релиз Rust Coreutils 0.1.0

24 мая 2025 вышла версия 0.1.0 проекта Rust Coreutils (uutils) — кроссплатформенной альтернативы GNU Coreutils, написанной на Rust.

В набор входят популярные утилиты: ls, cp, cat, chmod, date и другие.

Цель — создать производительную и безопасную замену Coreutils, которая будет работать на Linux, Windows, Redox и Fuchsia. 

Rust Coreutils уже будет использоваться по умолчанию в Ubuntu 25.10.

Основные улучшения версии 0.1.0:
⏺Поддержка SELinux в ключевых утилитах (cp, ls, mkdir, stat и др.).
⏺Оптимизации производительности: uutils в ряде случаев быстрее GNU.
⏺Улучшена совместимость с тестами GNU Coreutils (522 успешных теста).
⏺Расширены функции и добавлены опции во многие утилиты.

Проект распространяется под MIT-лицензией — более либеральной, чем GPL у GNU Coreutils.

Bonding интерфейсов в Linux: простая настройка для отказоустойчивости и скорости

Bonding - это объединение нескольких физических сетевых интерфейсов в один логический, чтобы увеличить пропускную способность или обеспечить резервирование.

Зачем нужно?

• Если один кабель или интерфейс упадёт, сеть не потеряется.
• Можно повысить скорость, суммируя каналы.

Как проверить, поддерживается ли bonding?

modprobe bonding
lsmod | grep bonding

Простой пример конфигурации (mode=1 — active-backup):

⏺Создаём файл /etc/sysconfig/network-scripts/ifcfg-bond0 (для RHEL/CentOS):

DEVICE=bond0
TYPE=Bond
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
BONDING_OPTS="mode=1 miimon=100"

⏺Настраиваем интерфейсы, которые в bonding, например /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes

Аналогично для eth1.

⏺Перезапускаем сеть:

ifdown eth0 eth1
ifup bond0

Что важно знать:

1️⃣Режим bonding влияет на логику работы: active-backup — резервирование, balance-rr — агрегация с балансировкой нагрузки, другие — для продвинутых сценариев.

2️⃣На коммутаторе тоже нужно настроить LACP или соответствующий режим.

Автопробуждение по Wake-on-LAN

Иногда сервер должен спать — например, ночью или в выходные.

Но нужно, чтобы он включался сам: для бэкапа, обновлений, задач по cron. Wake-on-LAN (WOL) решает это, если правильно настроить.

1️⃣Включаем WOL в BIOS/UEFI

Ищем опции вроде Wake on LAN, Power On By PCI-E, Resume by LAN. Иногда нужно разрешить включение от сетевой карты.

2️⃣Настраиваем интерфейс в системе

Проверяем, поддерживает ли интерфейс WOL:

ethtool eth0

В выводе ищем:

Wake-on: d

d — выключено. Включаем:

ethtool -s eth0 wol g

Тип g — классический “magic packet”.

Чтобы сохранялось после перезагрузки — добавьте в rc.local или systemd unit.

3️⃣Отправляем magic packet с другого хоста

Узнаём MAC-адрес сервера:

ip link show eth0

Отправляем:

wakeonlan 00:11:22:33:44:55

или

etherwake -i eth0 00:11:22:33:44:55

WOL работает только в одной подсети (обычно UDP broadcast).

4️⃣Автоматический запуск по расписанию

Пример cron-задачи на другом хосте:

0 3 * * * /usr/bin/wakeonlan 00:11:22:33:44:55

Или запускаем вручную скриптом, когда хотим включить сервер под задачу.

Проверим: включается ли сервер?

• Сервер должен быть выключен (но не полностью обесточен).
• Сетевая карта должна гореть (светодиоды).
• Wake-on-LAN должен быть разрешён и в BIOS, и в ОС.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое Transparent Huge Pages (THP) в Linux и как они влияют на производительность?

✅Ответ: Transparent Huge Pages (THP) — это механизм Linux, автоматически объединяющий обычные страницы памяти (обычно по 4 KB) в более крупные страницы (обычно по 2 MB), чтобы сократить накладные расходы на управление памятью и ускорить доступ.

Проверить текущее состояние THP можно командой:

cat /sys/kernel/mm/transparent_hugepage/enabled

Отключить, если они мешают:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Бэкапы без rsync: моментальные снапшоты с Btrfs

Если у вас раздел на Btrfs — можно делать моментальные резервные копии за секунду, без копирования данных.

1️⃣Создаём снапшот

btrfs subvolume snapshot /home /btrfs-backups/home-$(date +%F)

Мгновенно создаётся снимок текущего состояния. Это не копия файлов — это ссылка на те же блоки.

2️⃣Откат к снапшоту

mv /home /home-old
btrfs subvolume snapshot /btrfs-backups/home-2025-05-28 /home

Можно быстро откатиться без rsync и без восстановления из архива.

3️⃣Монтируем снапшот отдельно

mount -o ro,subvol=home-2025-05-28 /dev/sdX /mnt/snapshot

Открываем снапшот как read-only и вытаскиваем нужные файлы.

4️⃣Удаление старых снапшотов

btrfs subvolume delete /btrfs-backups/home-2025-04-01

Удаляется мгновенно, освобождая место.

5️⃣Автоматизация через cron

Добавьте в crontab -e:

0 2 * * * btrfs subvolume snapshot /home /btrfs-backups/home-$(date +\%F)

Снапшоты будут создаваться каждый день в 2:00.

Sudo под контролем: аудит и ограничения для продакшена

Иногда sudo — это дыра в безопасности. Особенно, если все команды идут в лог просто как sudo bash.

Вот как сделать использование sudo прозрачным и контролируемым.

⏺Включаем логирование команд с точностью до аргументов

Добавьте в /etc/sudoers:

Defaults log_input, log_output
Defaults logfile="/var/log/sudo.log"

Теперь всё, что делает пользователь с sudo, пишется в лог.

⏺Ограничиваем команды

Разрешаем user1 только перезапуск nginx и просмотр логов:

user1 ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx, /bin/journalctl -u nginx

Никаких sudo bash — только строго определённые команды.

⏺Проверяем логи sudo

cat /var/log/sudo.log | less
ausearch -k sudo

Анализируем, кто запускал sudo, когда, и что именно делал.

⏺Используем sudoreplay

Для продвинутого аудита:

sudo sudoreplay <ID>

Показывает ввод и вывод команды из лога log_input, log_output.

⏺Пример защиты от “sudo su”

В sudoers:

Cmnd_Alias BLOCKED = /bin/su, /bin/bash
user1 ALL=(ALL) !BLOCKED

Теперь нельзя поднять shell с sudo, только конкретные команды.

Оптимизируем операции через tmpfs

tmpfs — это не просто «/tmp в RAM». Это инструмент для сокращения I/O, минимизации wear-out на SSD и ускорения CI, кэширования и даже временного хранения IPC-артефактов.

Но при неправильной настройке — источник OOM и нестабильной производительности.

Зачем использовать tmpfs?

• Изоляция чувствительных к IOPS операций (например, /var/cache, /run, компиляции, unit-тестов).
• Уменьшение latency в пайплайнах CI/CD и dev-окружениях.
• Кратковременное хранение промежуточных артефактов без обращения к диску.

Настройка через systemd mount units

Вместо /etc/fstab можно использовать systemd для более гибкой логики:

# /etc/systemd/system/tmp-build.mount
[Unit]
Description=Build cache in RAM
Before=local-fs.target

[Mount]
What=tmpfs
Where=/mnt/buildcache
Type=tmpfs
Options=mode=1777,size=2G,noatime

[Install]
WantedBy=multi-user.target

Активируем:

systemctl enable --now tmp-build.mount

Учет ограничения RAM: tmpfs в cgroups

Если tmpfs монтируется внутри systemd-сервиса, лучше ограничить память через MemoryMax, иначе может съесть всю RAM:

[Service]
MemoryMax=3G
TemporaryFileSystem=/tmp:rw,size=1G

Продвинутые use-case’ы

1️⃣/tmpfs + overlayfs = изолированная среда
Подменяем часть rootfs без записи на диск, например, для временных hotfix-тестов:

mount -t tmpfs tmpfs /mnt/tmpfs
cp -a /etc /mnt/tmpfs/etc
mount -t overlay overlay -o lowerdir=/etc,upperdir=/mnt/tmpfs/etc,workdir=/mnt/tmpfs/work /etc

2️⃣Сборка пакетов в RAM в CI
Ускоряет сборку deb/rpm, кэш и распаковка исходников не используют диск.
3️⃣Безопасный IPC
Храним сокеты и FIFO в tmpfs — данные исчезают при ребуте, не остаётся следов на диске.

Вышла SQLite 3.50

Состоялся релиз легковесной СУБД SQLite 3.50. Проект написан на C, распространяется без лицензий и бесплатно.

Поддержку разработчикам оказывает отдельный консорциум.

Основные изменения:
⏺Новая функция sqlite3_setlk_timeout() для управления блокировками.
⏺Ослаблены ограничения на SQL-комментарии.
⏺Добавлены SQL-функции unistr() и unistr_quote().
⏺Улучшена работа printf(), .dump, .schema --indent.
⏺Оптимизация JSON-функций и улучшение sqlite3_rsync.
⏺Поддержка сборки под Cygwin, MinGW, Termux.
⏺Исправления и улучшения производительности.
⏺WASM/JavaScript: важное обновление VFS OPFS SAHPool — новые базы несовместимы со старыми VFS, но обратно совместимость сохранена.

Используем iptables hashlimit + recent вместо fail2ban

Когда fail2ban уже не справляется или слишком медленный, пора перейти на уровень ниже — к iptables.

Сочетание --hashlimit и --recent даёт мощный инструмент контроля попыток подключения к SSH без необходимости читать логи и запускать демоны.

Защитить порт 22 от перебора и сканеров

Входящие подключения должны:
⏺быть не чаще X раз в минуту с одного IP (аналог hashlimit),
⏺блокироваться при агрессивной активности (аналог recent),
⏺не мешать своим или автоматическим задачам (допускаем trusted IP или подсети).

1️⃣Разрешаем trusted-подсеть без лимитов

iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT

2️⃣Ограничение по частоте с hashlimit

Допускаем не более 3 подключений в минуту с одного IP:

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m hashlimit --hashlimit 3/min \
  --hashlimit-burst 5 \
  --hashlimit-mode srcip \
  --hashlimit-name sshlimit \
  -j ACCEPT

Это не требует ни журналов, ни доп. сервисов — чисто на уровне netfilter.

3️⃣Ловим и блокируем агрессивных через recent

Если IP попытался открыть соединение >5 раз за 60 секунд — баним на 5 минут:

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m recent --name SSH --set

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m recent --name SSH --update \
  --seconds 60 --hitcount 5 -j DROP

4️⃣Остальные соединения — по умолчанию DROP или REJECT

iptables -A INPUT -p tcp --dport 22 -j DROP

Тестирование

Подключитесь к серверу с другого IP и сделайте 10 попыток:

for i in {1..10}; do nc -zv your.server.ip 22; sleep 2; done

После 5–6 попыток пакет начнёт дропаться.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: В чем разница между процессами и потоками (threads) в Linux?

✅Ответ:

Процессы — это независимые единицы выполнения, каждая из которых имеет собственное адресное пространство. Это означает, что процессы изолированы друг от друга, и данные одного процесса недоступны другому без использования механизмов межпроцессного взаимодействия (IPC).

Потоки, в отличие от процессов, выполняются внутри одного адресного пространства. Это позволяет потокам одного процесса совместно использовать память и ресурсы, что делает их легче и быстрее в создании по сравнению с процессами. Для создания потоков используются библиотеки, такие как POSIX Threads (pthread).