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

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

❓Вопрос: Что такое systemd-nspawn и как он используется?

✅Ответ: systemd-nspawn — это легковесный инструмент контейнеризации, встроенный в systemd. Он позволяет запускать изолированные окружения, похожие на контейнеры, используя chroot и namespaces.

Ключевые особенности:
— Изоляция через PID, mount, user и network namespaces.
— Интеграция с systemd: контейнер можно управлять как обычным сервисом.
— Поддержка journald и машинного журнала логов.

MTU + TSO/GSO/UDP: когда jumbo frame ломает overlay-сеть

VxLAN, GENEVE и прочие overlay-технологии давно стали стандартом — но часто ломаются на ровном месте.

Один из таких кейсов — «всё работает, кроме какого-то странного трафика, который висит/рвётся/отваливается без объяснения». Виновник — неправильное сочетание MTU, jumbo-фреймов и offload’ов.

Что происходит

При использовании VxLAN поверх обычной сети каждый пакет получает дополнительный заголовок (VxLAN + UDP + IP), что увеличивает размер.

Если интерфейсы или туннельная прослойка не умеют в fragment/reassembly или MTU меньше ожидаемого, пакеты просто начинают теряться.

Особенно часто это бьёт по TCP SYN-ACK и UDP VoIP/QUIC.

Где это проявляется
• SSH зависает после ввода пароля
• веб-приложения внезапно «грузятся вечно»
• мониторинг теряет метрики
• nginx падает в 502 на старте TLS
• kubelet не подключается к apiserver через туннель

Как диагностировать
1️⃣Проверить MTU на всех интерфейсах в цепочке:

ip link show dev eth0
ip link show dev vxlan0

2️⃣ Проверить наличие offload’ов:

ethtool -k eth0 | grep -E '(tso|gso|gro)'

3️⃣ Поймать разрыв через tcpdump — будут видны обрезанные пакеты или ICMP fragmentation needed (не всегда!):

tcpdump -i vxlan0 -n -s 0 -vvv

4️⃣ Визуально ловить баги через ping -M do:

ping -s 8972 -M do <ip>

Как лечить
⏺Убедитесь, что внутренний MTU на overlay-интерфейсах (vxlan0, flannel.1 и т.п.) занижен хотя бы на 50 байт.
⏺Отключите GSO/TSO, если видите нестабильность:

ethtool -K eth0 gso off tso off

⏺Используйте sysctl для отключения Path MTU discovery в VxLAN:

sysctl -w net.ipv4.ip_no_pmtu_disc=1

⏺Проверяйте наличие проблемных маршрутов:

ip route get <destination>

TCP FIN_WAIT2 как зомби: кто на самом деле виноват

Когда сервер задыхается от тысяч FIN_WAIT2, первая реакция — «приложение не закрывает сокет». Но в реальности всё сложнее.

Это состояние — часть TCP state machine, в которой соединение уже завершено с одной стороны, но другая не закрыла свой конец. И залипнуть в нем можно надолго.

Что такое FIN_WAIT2?

После того как приложение вызывает close() на сокете, TCP-стек отправляет FIN и попадает в FIN_WAIT1. Как только получает ACK, соединение переходит в FIN_WAIT2. Ожидается, что вторая сторона тоже закроет соединение и отправит свой FIN.

Но если этого не происходит — соединение залипает. ОС ждёт. Иногда — вечно.

Где зарыта проблема?

1️⃣Клиент не закрывает соединение
Часто виновник — клиентское приложение, которое “забывает” вызывать close(), особенно если сессия рвётся без ошибок.

2️⃣ Сервер не настраивает таймауты FIN_WAIT2
Linux по умолчанию может держать FIN_WAIT2 бесконечно, если сокет уже передан в userspace.
Проверить:

sysctl net.ipv4.tcp_fin_timeout

Но это работает только для сокетов, не переданных в userspace. Если accept() уже был вызван — ядро не может удалить соединение самостоятельно.

3️⃣ Не освобождается сокет в приложении
Даже если вы вызываете close(), соединение может оставаться активным, если сокет всё ещё держится в дескрипторах. Проверить можно так:

lsof -nP | grep TCP | grep FIN_WAIT2

Как диагностировать
• Посмотреть, кто держит соединения:

ss -o state fin-wait-2 '( sport = :443 )'

• Локализовать виновника через lsof и netstat -p
• Проверить tcp_fin_timeout, tcp_keepalive_time и поведение приложения

Как лечить
⏺Явно закрывайте соединения на клиенте, особенно если используете keep-alive
⏺Включите tcp_tw_reuse и tcp_tw_recycle с осторожностью (лучше нет)
⏺На стороне сервера: оберните close() в таймер или настройте logic shutdown после inactivity
⏺Для embedded/ограниченных систем: можно использовать iptables для отсечения FIN_WAIT2 через conntrack timeout

Вместо вывода

FIN_WAIT2 — это не баг, а следствие честной реализации TCP. Но в проде оно ведёт к исчерпанию ресурсов и зомби-соединениям. Решение — всегда баланс между корректным shutdown и агрессивным таймаутом.

Лимиты 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