Вопросы на собеседовании: Linux и shell

После перезагрузки хоста сервис не поднялся, а systemctl показывает failed. Как будешь разбираться до первого restart?

systemctl status app.service --no-pager
journalctl -u app.service -b --no-pager
systemctl cat app.service

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

Пользователь может прочитать файл по открытому дескриптору, но не может пройти к нему по пути /srv/app/config.yml. Как читаются rwx у файла и каталога и что ты проверишь?

как ответить У обычного файла r, w, x означают чтение, изменение и исполнение. У каталога r разрешает читать список имён, w — менять записи каталога, а x — проходить через него и обращаться к известному имени. Поэтому проверяю права каждого компонента пути, владельца, группу и ACL, а не ставлю 777 на конечный файл.

Чем SIGTERM отличается от SIGKILL, что по умолчанию делает kill PID и почему kill -9 — не первый способ остановить сервис?

как ответить kill PID по умолчанию посылает SIGTERM: процесс может обработать сигнал, прекратить приём работы, закрыть ресурсы и выйти. SIGKILL нельзя перехватить, заблокировать или проигнорировать, поэтому пользовательский cleanup не выполнится; но процесс в непрерываемом ожидании ядра может исчезнуть не сразу. Обычно сначала даю приложению ограниченное время на graceful shutdown и только затем эскалирую.

Приложение получает No space left on device. Как отличишь закончившиеся блоки, inode и место, которое удерживает удалённый, но открытый файл?

как ответить Сначала определяю нужную файловую систему через df -hT и отдельно проверяю inode через df -i. Затем ищу крупные каталоги командой du в пределах этого mount point и смотрю удалённые открытые файлы через lsof +L1. df считает занятые блоки файловой системы, а du обходит доступные имена, поэтому их расхождение само по себе диагностично.

Почему некавыченная переменная в shell-скрипте может превратить один путь в несколько аргументов или неожиданно раскрыть *? Как передавать списки файлов безопасно?

path='release 2026/*.log'
printf '<%s>\n' $path
printf '<%s>\n' "$path"

как ответить После подстановки некавыченная переменная в Bash проходит word splitting и glob expansion, поэтому число аргументов зависит от пробелов и файлов в текущем каталоге. Двойные кавычки сохраняют значение одним аргументом, но список строк лучше хранить в массиве и раскрывать как "${items[@]}". Имена файлов из find передаю через NUL-разделитель, а не разбираю вывод по строкам.

Скрипт печатает deploy ok, хотя curl не скачал артефакт. Почему pipeline скрыла ошибку и как сделать проверку надёжной?

curl -fsS "$URL" | tee artifact.json >/dev/null
echo 'deploy ok'

как ответить Без pipefail статус pipeline равен статусу последней команды, поэтому успешный tee маскирует падение curl. В Bash включаю set -o pipefail и проверяю статус всей операции либо явно ветвлюсь через if. На один set -e не полагаюсь: у него есть исключения в условиях, списках и pipeline.

У хоста load average сильно выше числа CPU, но в top процессор в основном свободен. Что означает эта картина и как найдёшь узкое место?

как ответить Linux load average учитывает не только выполняемые и готовые к CPU задачи, но и задачи в непрерываемом ожидании, обычно состояния D. Поэтому высокий load при свободном CPU часто указывает на задержки I/O или зависшую внешнюю файловую систему. Сопоставляю очередь, состояния процессов, iowait и задержки устройств, а не делаю вывод по одному числу.

На Linux почти не осталось free memory. Когда это нормально, а когда похоже на утечку или memory pressure?

как ответить Низкое поле free само по себе нормально: Linux использует незанятую память под page cache и может освободить значительную часть при спросе. Смотрю MemAvailable, swap-in/swap-out, reclaim и давление, затем связываю рост с конкретными процессами по RSS/PSS. Факт OOM подтверждаю журналом ядра, а не только кодом завершения приложения.

Сервис начал получать Too many open files. Как докажешь утечку file descriptor и почему простое увеличение лимита может только отложить сбой?

как ответить Сверяю лимит процесса в /proc/<pid>/limits с количеством и типами записей в /proc/<pid>/fd, затем наблюдаю их рост во времени. Дескриптором бывает не только файл, но и сокет, pipe, eventfd или удалённый файл, поэтому группирую цели ссылок и состояния соединений. Лимит повышаю только как осознанный запас после устранения причины и проверки глобальных ограничений.

В ps накопились процессы со статусом Z, а kill -9 на них ничего не меняет. Что это за процессы и где исправлять проблему?

как ответить Zombie уже завершил выполнение и освободил рабочие ресурсы; в таблице процессов осталась запись со статусом, которую родитель должен забрать через wait. Поэтому сигнал посылать уже некому. Нахожу PPID и исправляю родительский процесс: он должен обрабатывать SIGCHLD и своевременно reaping-ить детей.

Юнит с Type=simple считается запущенным раньше, чем приложение открыло порт; зависимый сервис стартует слишком рано, а при падении получается restart loop. Как спроектируешь unit без sleep 10?

как ответить Разделяю ordering, dependency и readiness: After= задаёт только порядок, Wants= или Requires= — отношения юнитов, а готовность должен сообщить сам сервис. Если приложение поддерживает sd_notify, использую Type=notify и READY=1; иначе выбираю честный протокол активации или отдельную проверку, а не фиксированный сон. Restart ограничиваю backoff и rate limit, сохраняя различие между штатной остановкой и отказом.

На хосте бывают короткие всплески latency, хотя средние CPU, RAM и IOPS выглядят нормально. Как используешь PSI и обычные системные метрики, чтобы доказать ресурсное давление?

как ответить Утилизация показывает, сколько ресурса использовали, а PSI — сколько времени задачи не могли продвигаться из-за дефицита CPU, memory или I/O. Смотрю /proc/pressure/* и, если нужно, PSI конкретного cgroup, затем коррелирую интервалы some и full с latency сервиса, run queue, reclaim, swap и задержками устройств. PSI подтверждает stall, но причину всё равно локализую следующими метриками и профилированием.