Лимиты systemd: что произойдёт, если запустить 20k сервисов одновременно

Запустить 20 000 systemd-юнитов — звучит безумно, но на самом деле это вполне достижимо на современной машине. Вопрос в другом: где начнёт всё сыпаться?

Мы сгенерировали 20k простых сервисов с шаблоном ExecStart=/bin/sleep infinity, и попытались запустить их разом через systemctl start test@{1..20000}.

На что упёрлись:

1️⃣PID limits:
Первое, что кончилось — лимит процессов. Даже при ulimit -u unlimited, ядро имеет предельный pid_max. Проверить можно:

cat /proc/sys/kernel/pid_max

2️⃣File descriptors:
Каждый сервис тянет за собой файловые дескрипторы: сокеты, логирование через journald, pipe’ы.
Мониторить:

lsof | wc -l  
cat /proc/sys/fs/file-nr

3️⃣Cgroups:
systemd создаёт по cgroup на каждый юнит. При большом количестве можно уткнуться в лимит вложенности или число control group’ов.
Проверка:

systemctl status test@19999
cat /proc/self/cgroup

4️⃣journal:
Если сервисы пишут в журнал, journald начинает лагать или просто отваливается. Особенно, если RateLimitInterval не сконфигурирован.
Проверить, сколько записей в секунду:

journalctl -o short-precise -f

5️⃣CPU scheduler:
Если юниты зависают или выходят с ошибкой, systemd тратит кучу ресурсов на перезапуск. И даже при Restart=no огромный пул сервисов может повлиять на responsiveness системы.

Как наблюдать:
⏺systemd-analyze dump | grep 'Service State'
⏺systemctl list-units | grep test@ | wc -l
⏺top, iotop, pidstat, journalctl — всё идёт в бой.

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

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

❓Вопрос: Как работает Linux Security Module (LSM) и зачем он нужен?

✅Ответ: LSM — это подсистема ядра Linux, обеспечивающая инфраструктуру для реализации различных политик безопасности. Она предоставляет интерфейсы для внедрения ограничений на уровне ядра, не меняя сам код ядра напрямую.

LSM реализует механизм hook-based security, в котором в ключевые точки ядра встроены хуки. Эти хуки вызываются перед выполнением чувствительных операций (например, доступ к файлу, сетевой сокет или выполнение бинарника), и LSM-расширение решает — разрешить или запретить операцию.

Как найти самый медленный диск в RAID без iostat: только dd и strace

Когда RAID-массив уходит в degraded, и чтение с него начинает тормозить, первым делом хочется открыть iostat или dstat — но что делать, если этих утилит нет, или нужно быстро сориентироваться на минимальной системе?

RAID5 на mdadm, одно устройство помечено как degraded. Хотим понять, какой из оставшихся дисков тормозит, не прибегая к утилитам верхнего уровня.

1️⃣dd по /dev/mdX с отслеживанием времени

dd if=/dev/md0 of=/dev/null bs=4M status=progress

Смотрим, залипает ли на конкретных участках. Если чтение “пульсирует” — скорее всего, где-то один из дисков тормозит при чтении блоков.

2️⃣ strace на dd — трекинг задержек в syscalls

strace -T -e read dd if=/dev/md0 of=/dev/null bs=4M

Параметр -T покажет время, затраченное на каждый системный вызов read(). Если большинство идут быстро (<0.01s), а иногда появляются задержки в 0.2-0.5 секунды — именно в эти моменты диск фризит.

3️⃣ mdadm + cat /sys/block на live-данных
Можно сверить статистику по mdstat, а потом пойти глубже:

cat /proc/mdstat

Затем для каждого устройства в массиве:

for d in sd{a,b,c}; do echo "$d: $(cat /sys/block/$d/stat)"; done

Здесь можно отследить рост времени обработки I/O по полям в /sys/block/*/stat. Если у одного устройства счётчики существенно выше — это он и есть.

smartctl на подозреваемом диске
После того, как нашли “виновника”, имеет смысл проверить его S.M.A.R.T.:

smartctl -a /dev/sdX

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

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

❓Вопрос: Как работать с Terraform State на практике?

✅Ответ: Terraform State используется для хранения текущего состояния инфраструктуры и управления изменениями.

Примеры работы:

1️⃣Просмотр состояния:

terraform show  

Выводит текущее состояние инфраструктуры из файла terraform.tfstate.

2️⃣Обновление состояния вручную: Если ресурс изменился вне Terraform, обновите state:

terraform refresh  

3️⃣Удаление ресурса из state: Если нужно удалить ресурс без фактического удаления из инфраструктуры:

terraform state rm <resource_name>

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

1️⃣ Uptime Kuma: OpenSource, полный контроль, уведомлений (Telegram, Discord и много других), нужно разворачивать и обслуживать сервер.

2️⃣ Kuma Cloud: Та же Uptime Kuma, только в облаке, работает из коробки за 30 секунд, ни каких заморочек, поддержка и авто-обновления.

3️⃣ UpTimeRobot: Бесплатный тариф - 50 мониторов, мало гибкости в настройках, ограниченные уведомления, сильно дороже предыдущих.

4️⃣ Overseer - Простота и минимализм, мало функций, нет детальной аналитики, дёшево.

✅ Почему Kuma Cloud - наш выбор?
- Быстрее, чем разворачивать самому
- Мощнее, чем UptimeRobot и Overseer
- Тесная интеграция с Telegram

Профили пользователя Bash: как всё устроено и зачем это знать

Bash — самая распространённая командная оболочка в Linux. 

Она запускается каждый раз, когда вы логинитесь в систему или открываете терминал. Поведение Bash при этом регулируется специальными профилями — системными и пользовательскими.

Разберём, как они работают и что с ними можно делать на практике.

Что происходит при запуске Bash?

Bash может работать в двух режимах: login shell (при входе в систему) и interactive non-login shell (обычное открытие терминала). В зависимости от сценария запуска, загружаются разные файлы:

При входе в систему (login shell):
⏺/etc/profile — глобальный скрипт инициализации;
⏺/etc/profile.d/*.sh — дополнительные скрипты, подключаемые через profile;
⏺один из: ~/.bash_profile, ~/.bash_login, ~/.profile (в Ubuntu чаще всего это ~/.profile, ссылающийся на ~/.bashrc).

При запуске терминала (non-login shell):
• /etc/bash.bashrc или /etc/bashrc;
• ~/.bashrc.

Также есть ~/.bash_logout, который выполняется при выходе из сессии.

Как это использовать на практике?

1. Настройка переменных окружения
В ~/.bashrc или ~/.profile удобно добавлять переменные окружения:

export EDITOR=nano
export PATH="$PATH:$HOME/scripts"

2. Часто используемые команды — в функции
Если вы часто запускаете цепочки команд, создайте функцию:

function logs() {
  cd /var/log && ls -lt | head
}

3. Инициализация новых пользователей
Все, что лежит в /etc/skel/, будет копироваться в домашнюю папку новых пользователей:

/etc/skel/.bashrc
/etc/skel/.profile

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

4. Настройка путей и alias’ов
В ~/.bashrc можно настраивать alias:

alias ll='ls -lah'
alias gs='git status'

Проверка работы профилей

Чтобы отладить поведение при запуске оболочки, можно добавить временные echo:

echo "Loaded ~/.bashrc" >> ~/bash_debug.log

Почему netstat лжёт: как ss показывает реальную картину с сокетами

В современном Linux часто применяются инструменты для мониторинга сетевых соединений.

Несмотря на свою популярность, утилита netstat уже не всегда предоставляет точную информацию о состоянии сокетов.

Неточное отображение состояний с netstat

Netstat долгое время был основным инструментом для вывода информации о сетевых соединениях, но его алгоритмы и подходы к сбору статистики имеют ограничения:

⏺Netstat опирается на данные из /proc, которые могут не отражать динамическое изменение состояния сокетов. В результате он часто показывает устаревшую информацию, например, “мертвые” или заброшенные сокеты, которые уже не участвуют в активной передаче.

⏺При анализе состояний, таких как FIN_WAIT2, netstat может некорректно интерпретировать “зависшие” соединения. Это может ввести администратора в заблуждение относительно истинной загрузки и стабильности системы.

Преимущества ss: точные и детальные данные

Современный инструмент ss (socket statistics) из пакета iproute2 разработан для замены netstat и предоставляет гораздо более подробную и актуальную информацию о сетевых сокетах.

Он способен отсеивать “мертвые” соединения, корректно отображать переходные состояния и использовать расширенные опции для фильтрации и диагностики.

Например, чтобы увидеть информацию о TCP-сокетах, можно воспользоваться командой:

ss -tan

Здесь ключи означают:
• -t – вывести только TCP-соединения,
• -a – показать все (слушающие и установленные),
• -n – вывод номеров портов в числовом виде.

Если вам нужно проверить, какие сокеты находятся в “FIN_WAIT2” состоянии, команда ss покажет их корректно, благодаря более точной сборке данных из ядра:

ss -tan state fin-wait-2

Особенно полезна опция -K. Этот параметр позволяет отправлять запросы к ядру для получения более глубокого анализа по каждому сокету – например, чтобы определить, какие “зависшие” сокеты реально не используются.

Это даёт возможность отфильтровать ложные сигналы и сконцентрироваться на проблемных соединениях. Пример использования:

ss -K state established

Эта команда попытается “убить” (удалить) неактивные или ошибочные соединения, предоставляя отчёт о том, какие сокеты останутся в системе после вмешательства. Такой уровень контроля невозможен с netstat.

Как узнать причину перезагрузки Linux

Неожиданная перезагрузка Linux-сервера — это всегда тревожный звоночек. Иногда виноват админ, иногда — ядро, а иногда — железо. Разберём, как правильно искать первопричину, чтобы не гадать на кофейной гуще.

1️⃣Кто и когда перезагружал?

Команды:

who -b     # Показывает последнее время загрузки
last reboot # Список всех событий перезагрузки

Это даст базовую точку отсчёта: когда именно сервер перезапустился.

2️⃣ Логи — наше всё

Сравниваем время перезагрузки с системными журналами:
• RHEL/CentOS: /var/log/messages
• Ubuntu/Debian: /var/log/syslog

Ищем фрагменты про shutdown, poweroff, reboot. Можно фильтровать, чтобы убрать шум:

sudo grep -iE 'recover|power|shutdown|rsyslogd|ups' /var/log/{messages,syslog}

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

3️⃣ auditd: ищем системные события

Если стоит auditd, смотрим аккуратные записи про загрузку и остановку:

sudo ausearch -i -m system_boot,system_shutdown | tail -4

Если видим две подряд строки SYSTEM_BOOT — значит, скорее всего, была авария или падение питания.

4️⃣

journalctl: работа с историей загрузок

Если настроено сохранение логов в /var/log/journal, можно получить историю перезагрузок:

journalctl --list-boots
journalctl -b -1     # Смотрим предыдущую загрузку

Так можно увидеть, были ли перед перезагрузкой ошибки типа OOM, kernel panic или странные systemd-события.

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

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl kill -s SIGUSR1 systemd-journald

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

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

❓Вопрос: Как работает механизм KSM (Kernel SamePage Merging) и для чего он используется в Linux?

✅Ответ: KSM (Kernel SamePage Merging) — это механизм в ядре Linux, который позволяет сливать идентичные страницы памяти, используемые разными процессами, с целью экономии оперативной памяти. Этот процесс особенно полезен в виртуализированных средах, где виртуальные машины могут использовать одинаковые данные.