Вопросы на собеседовании по Linux для DevOps: 15 ситуаций с ответами

Сначала смотрю состояние: ps -o pid,ppid,stat,cmd -p 1234. Вариантов два.

Состояние D — непрерываемый сон, обычно ожидание ввода-вывода: зависший NFS, умирающий диск. Процесс в ядре, и сигнал, даже SIGKILL, как правило, сработает только когда операция вернётся. Лечится причина: диск, сетевое хранилище, иногда только перезагрузка.

Состояние Z — зомби. По man ps это уже завершившийся процесс, запись о котором осталась, потому что родитель не забрал код завершения. Убивать зомби бессмысленно, он уже мёртв. Нужно чинить или перезапускать родителя (ppid в выводе): когда родитель завершится, зомби заберёт init.

И база: SIGTERM процесс может перехватить и корректно завершиться, а SIGKILL и SIGSTOP, по man 7 signal, нельзя ни перехватить, ни заблокировать, ни проигнорировать.

Удобный порядок — чек-лист команды Netflix из статьи «Linux Performance Analysis in 60,000 Milliseconds» 2015 года:

uptime                  # load average за 1, 5 и 15 минут: растёт или падает
dmesg | tail            # ошибки ядра: OOM killer, диски, сеть
vmstat 1                # очередь на CPU (r), ждущие I/O (b), swap, iowait
mpstat -P ALL 1         # загрузка по ядрам: одно ядро на 100% — однопоточное узкое место
pidstat 1               # кто именно ест CPU
iostat -xz 1            # задержки и загрузка дисков
free -m                 # память и кэш
sar -n DEV 1            # трафик по интерфейсам
sar -n TCP,ETCP 1       # новые соединения и повторные передачи
top                     # общая картина напоследок

Смысл — по очереди проверить CPU, память, диски и сеть и найти, где насыщение или ошибки. Дальше копать туда, куда указали цифры.

Если приложение ничего не успело записать, его, скорее всего, убило ядро. Проверяю journalctl -k -b | grep -i -E 'out of memory|killed process' или dmesg -T | grep -i oom. OOM killer срабатывает, когда память кончается на всей машине или в cgroup с лимитом: у сервиса systemd с MemoryMax=, у контейнера. Жертву ядро выбирает по oom_score (видно в /proc/<pid>/oom_score), а повлиять на выбор можно через oom_score_adj. Но главное — понять, почему кончилась память: утечка, пик нагрузки, лишний процесс. После — лимиты памяти для сервисов и алерт на память.

Чаще всего место держат удалённые файлы, которые ещё открыты процессом: имя из каталога исчезло, поэтому du их не видит, а данные на диске остаются, пока процесс держит дескриптор. Классика — лог удалили через rm, а сервис продолжает в него писать. Ищу так:

lsof +L1                        # открытые файлы без ссылок в каталогах, то есть удалённые
ls -l /proc/1234/fd | grep deleted

Освободить место — перезапустить процесс или заставить его переоткрыть лог. Если перезапуск недопустим, файл можно обрезать через дескриптор: : > /proc/1234/fd/7. Профилактика — правильная ротация: create с командой переоткрытия лога или copytruncate для программ, которые не умеют переоткрывать файл. man logrotate честно предупреждает, что при copytruncate можно потерять несколько строк. Подробнее — закончилось место на диске.

df -i покажет, что кончились inode: у каждого файла есть inode, и на ext4 их число задаётся при создании файловой системы. Съедают их миллионы мелких файлов: сессии, кэш, очередь почты, временные файлы. Искать удобно через du --inodes -x /var | sort -n | tail — какие каталоги содержат больше всего файлов. Лечение — удалить лишнее и настроить очистку. Если мелких файлов много по задаче, файловую систему пересоздают с другим соотношением inode или выбирают XFS, где inode выделяются динамически.

Увеличить нужно три уровня по очереди: диск (уже сделано в облаке), раздел и файловую систему. lsblk покажет, что диск больше раздела. Дальше:

growpart /dev/sda 1          # расширить раздел 1 до конца диска
resize2fs /dev/sda1          # ext4: указывается устройство
xfs_growfs /                 # XFS: указывается точка монтирования
# с LVM:
pvresize /dev/sda2
lvextend -r -l +100%FREE /dev/vg0/root   # -r сразу расширит и файловую систему

Обе файловые системы умеют расти на смонтированном разделе. Уменьшить XFS нельзя вообще, поэтому раздувать её «с запасом» не стоит.

Права файла — не всё. Проверяю по порядку:

• namei -l /opt/app/run.sh покажет права каждого каталога в пути: без x на каталоге в него нельзя войти, даже если сам файл открыт всем;
• findmnt -T /opt/app -o TARGET,OPTIONS — нет ли noexec у раздела; тогда bash run.sh сработает, а ./run.sh нет;
• getfacl run.sh — ACL могут переопределять обычные права;
• ls -Z и журнал аудита — SELinux или AppArmor могут запрещать доступ при правильных правах.

Отдельно помню похожую ошибку: если в первой строке скрипта указан несуществующий интерпретатор или файл сохранён с переводами строк Windows, будет «bad interpreter» — это уже не права.

Отдельный файл в /etc/sudoers.d/, который редактируют только через visudo -f /etc/sudoers.d/app-deploy, — он проверит синтаксис перед сохранением:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart app.service, /usr/bin/systemctl status app.service

Команда указывается полностью, с аргументами. Нельзя разрешать шаблоны вроде systemctl *, редакторы, less и интерпретаторы: из них можно выйти в shell с правами root. Проверить результат — sudo -l -U deploy. Для systemd есть и альтернатива без sudo — правила polkit.

Три инструмента, обычно вместе:

chgrp team /srv/shared
chmod 2775 /srv/shared                     # setgid: новые файлы наследуют группу каталога
setfacl -d -m g:team:rwX /srv/shared       # ACL по умолчанию: группе rw для новых файлов

Setgid на каталоге решает вопрос группы, ACL по умолчанию — права для новых файлов независимо от umask автора. Без ACL придётся настраивать umask 002 у всех пользователей. Если нельзя, чтобы коллеги удаляли чужие файлы, добавляют sticky bit, как у /tmp.

systemctl is-enabled app — включён ли сервис вообще: start запускает один раз, автозапуск даёт enable и секция [Install] с WantedBy=multi-user.target. journalctl -u app -b — что было именно при этой загрузке. Частая причина — порядок: сервис стартует раньше сети или базы. Тогда нужны Wants=network-online.target и After=network-online.target или повторные попытки. Если юнит правили, нужен systemctl daemon-reload. systemctl cat app покажет итоговый юнит с дополнениями, systemd-analyze verify найдёт ошибки в нём. Подробнее — systemd-сервис не запускается.

По man systemd.service по умолчанию Restart=no: упавший сервис никто не поднимет. Нужен Restart=on-failure или always. Вторая ловушка — ограничение частоты. RestartSec по умолчанию 100 мс, а по man systemd-system.conf действует лимит: не больше 5 запусков за 10 секунд. Быстро падающий сервис упирается в лимит, и systemd перестаёт его перезапускать.

[Unit]
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=5

systemctl reset-failed app сбрасывает счётчик. Но перезапуск — страховка, а не лечение: причину падения ищу в journalctl -u app.

ss -ltnp покажет, на каком адресе слушает процесс. 127.0.0.1:8080 доступен только с самой машины — приложение нужно перенастроить на 0.0.0.0 или конкретный внешний адрес. Если адрес правильный, дело в фильтрации: nft list ruleset или iptables -S, а также ufw status или firewall-cmd --list-all — смотря что стоит на сервере. В облаке — группы безопасности. С другой машины проверяю nc -vz host 8080: «refused» — порт никто не слушает, таймаут — пакеты режет фаервол. Если порт занят другим процессом — см. порт занят в Linux.

dig ходит в DNS напрямую, а приложения разрешают имена через библиотеку и NSS: порядок источников задаёт /etc/nsswitch.conf, там же участвует /etc/hosts. Проверять надо так же, как приложение: getent hosts db.internal. Дальше /etc/resolv.conf: какой сервер, какие search-домены и ndots. При systemd-resolved там будет 127.0.0.53, а настоящие серверы покажет resolvectl status. По man resolv.conf таймаут ожидания ответа по умолчанию — 5 секунд, поэтому один мёртвый резолвер в списке даёт характерные пятисекундные задержки. Подробнее — DNS не резолвит в Linux.

Ошибка «ещё не действителен» при нормальном сертификате почти всегда означает, что часы сервера ушли назад. Проверяю timedatectl: строки System clock synchronized и NTP service. При chrony — chronyc tracking и chronyc sources -v: есть ли доступные источники времени. Частые причины: выключенная служба синхронизации, закрытый исходящий UDP 123, виртуальная машина после паузы или восстановления из снапшота. Исправить — включить синхронизацию и, если расхождение большое, выровнять часы сразу: chronyc makestep. От часов зависят TLS, токены, подписи и порядок событий в логах. Если же сертификат действительно истёк — см. истёк SSL-сертификат.

По man proc_loadavg три числа — среднее за 1, 5 и 15 минут количества задач в очереди на выполнение (состояние R) или в ожидании дискового ввода-вывода (состояние D). Сравнивать нужно с числом ядер (nproc): 16 на четырёх ядрах — очередь в четыре задачи на ядро. Но плохо это или нет, зависит от того, кто в очереди. vmstat 1: большой столбец r при загруженном CPU — нехватка процессора, большой b при высоком wa — задачи ждут диск или NFS, и добавление CPU не поможет. Смотрю и динамику: если минутное значение ниже 15-минутного, нагрузка уже спадает. Подробнее — load average в Linux.