Пара 10: Диагностика и ремонт Linux

90 минут · 3 курс, ML.

Содержание и результат

Диагностировать отказ по цепочке наблюдений и составить короткий отчёт.

План занятия

0–10: контекст и исходная задача. 10–40: устройство и механизмы. 40–55: демонстрация команд. 55–80: лабораторная работа. 80–90: разбор результата и фиксация исправлений.

Практика выполняется в своей учебной папке и на localhost. Подготовка окружения описана в lab/README.md.

Гипотеза должна предсказывать наблюдение

Команда выбирается для проверки причины.

Начните с симптома, затем формулируйте гипотезу и проверку. «Занят порт» предсказывает слушающий другой процесс в ss. «Неверный путь» предсказывает ошибку запуска и отсутствующий файл. «Неправильный URL» предсказывает исправный процесс и 404 на запрошенном пути. Случайная смена нескольких настроек одновременно лишает нас причинной связи. Перед изменением фиксируем состояние, после проверяем тот же запрос. Это учебная версия работы по инциденту, а не конкурс на количество команд. В парах один человек формулирует гипотезу, второй выполняет проверку; затем меняются ролями.

Аналогия: врач проверяет версию анализом, а не назначает все лекарства сразу.

Диагностическая лестница

Идём от адреса и процесса к журналу и конфигурации.

Сначала уточняем среду: Windows или WSL, какой путь, адрес и порт. Проверяем процесс, слушающий сокет и HTTP-ответ. Затем читаем журнал и сравниваем конфигурацию с README. Ресурсные проверки нужны, если признаки указывают на них, а не механически на каждый 404. Запишите команды и короткие результаты, не весь личный терминал. Не выводим env целиком: там могут быть секреты. Если нужен порт, читаем конкретное значение настройки. Не повышаем права без доказательства проблемы доступа.

Нет универсальной команды, которая докажет исправность всех слоёв.

Отчёт о восстановлении

Исправление должно воспроизводиться и проверяться.

Хороший мини-отчёт содержит симптом, факты, причину, изменение и проверку. Пример: curl на 8000 возвращал connection refused; служба слушала 8001; README содержал старый порт; исправили документированный URL; healthz вернул ожидаемую версию. Если доказательства причины недостаточно, пишем «гипотеза», а не «точно». На защиту выносится и предотвращение повторения: проверка конфигурации, инструкция запуска или тест. Восстановление доступности и окончательное исправление причины могут быть разными действиями, это будет важно в декабре.

Аналогия: акт ремонта нужен следующей смене, а не только тому, кто крутил гайку.

Подробный разбор: Базовый ремонт Linux по подтверждённой причине

Диагностика: от симптома к причине

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

Диагностика: от симптома к причине

Command not found: проверить имя, command -v и PATH. Permission denied: проверить пользователя, rwx/ACL каждого родительского каталога, executable bit и noexec; sudo не исправляет неверный путь. Existing file + no such file: проверить interpreter shebang и PT_INTERP ELF, включая CRLF. Address already in use: найти собственный слушающий PID через ss/lsof, затем выбрать свободный порт или штатно остановить нужный процесс. Connection refused часто означает отсутствие слушателя в выбранной точке, timeout имеет больше возможных причин; HTTP 500 уже относится к ответу приложения. No space left: проверить df -h, df -i и du, затем deleted-open files; свободные байты не решают исчерпанные inode. Killed: проверить OOM и ограничения, не объявлять любую остановку нехваткой RAM. Missing .so: выяснить dependencies и совместимый пакет. После исправления повторить исходную команду и HTTP-запрос, сохранить минимальный runbook. Не использовать reboot/reinstall как способ стереть диагностические данные.

Практическое следствие: Подтвердите причину, исправьте её и повторите исходный запрос.

Опыт: связать рисунок с наблюдением

command -v python3
file app.py
pwd
id
ls -ld . data
df -h .
df -i .
ss -lntp
curl --max-time 3 -i http://127.0.0.1:8000/healthz

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

Источники подробного разбора

Команды и наблюдения

Окружение: Ubuntu / Bash.

cd ~/devops-course/lab
PORT=8001 .venv/bin/python app.py
# In another terminal
curl --connect-timeout 2 http://127.0.0.1:8000/healthz
ss -ltnp | grep -E ":8000|:8001"
curl -i http://127.0.0.1:8001/healthz

Это воспроизводимая авария без изменения системных служб. После демонстрации Ctrl+C.

Ожидаемый результат: На 8000 отказ соединения, на 8001 — 200; причина в несоответствии порта запроса и запуска.

Вариант для macOS

Сценарии порта, пути, HTTP и Python одинаковы; замените ss на lsof. Не используйте systemctl для launchd. Все исследования остаются на своём localhost.

lsof -nP -iTCP:8000 -sTCP:LISTEN
lsof -nP -iTCP:8001 -sTCP:LISTEN
curl -i http://127.0.0.1:8001/healthz

Практика: Станции диагностики

  1. Станция A: преподаватель запускает сервис на другом порту. Найдите его и исправьте клиентский URL.
  2. Станция B: MODEL_PATH ссылается на отсутствующий артефакт. Восстановите путь.
  3. Станция C: запрос отправлен на /healtz. Определите различие между 404 и отказом соединения.
  4. На каждой станции оформите пять строк: симптом, проверка, причина, исправление, доказательство.

Результат: Три мини-отчёта и рабочий README проекта.

Проверка: Каждая причина подтверждена наблюдением; healthz и predict работают после восстановления.

Неисправность для разбора: Студент перезапускает всё, не сохранив доказательства.

Решение и диагностика

A: ss и curl к реальному порту. B: сообщение об ошибке конфигурации, проверка ls models/model.json, корректный MODEL_PATH. C: работающий healthz плюс 404 неверного пути; исправить URL. Итоговый POST /predict с hours=4 должен вернуть score=0.5 для базового коэффициента 0.125. Оценивать аргументацию, а не скорость и число команд.

Основные выводы

Самостоятельная работа

Сдать Linux-чекпоинт: паспорт среды, README, скрипт сводки и один отчёт об аварии.

Источники