🐧 Linux · 20 вопросов · ~45 мин · ⏱ Таймер 45:00 · Средний · 👥 1 прошёл

Журналы и расследование ошибок

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

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. На 20 вопросов отведено 45 минут. Не меньше половины заданий требуют разобрать команды, сценарий Bash, конфигурацию или диагностический вывод. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и краткий разбор каждого решения.

Вопрос 1 из 20

Где обычно оказываются stdout и stderr службы, запущенной systemd без отдельной настройки?

journalctl -u app.service -b

Только на виртуальной консоли В файл /tmp/service.log, заданный systemd как общий журнал служб В journal, привязанные к unit и процессу В /var/log/messages независимо от настроек дистрибутива

Вопрос 2 из 20

Что показывает journalctl -k?

Сообщения ядра из journal Только журналы Kubernetes Список kernel modules без сообщений Ключи SSH пользователей

Вопрос 3 из 20

Почему приложение может писать одновременно в journal и собственный файл?

StandardOutput=journal
# app config:
log_file=/var/log/app/app.log

journald читает файл приложения через inotify и повторяет его строки Это возможно только после сбоя Файловая система дублирует все записи Разные обработчики направляют записи в оба места

Вопрос 4 из 20

Какой источник первым проверить при сообщении, что процесс убит OOM killer?

journalctl -k -b | grep -iE 'out of memory|killed process'
cg=$(systemctl show app.service -p ControlGroup --value)
cat "/sys/fs/cgroup${cg}/memory.events"

Историю команд пользователя Kernel journal и cgroup-события памяти DNS-кэш Только access.log nginx

Вопрос 5 из 20

Зачем приложению собственный request_id в журналах?

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

Вопрос 6 из 20

Как посмотреть журнал конкретной службы только с текущей загрузки?

journalctl -u app.service -b

journalctl -u app.service -k cat /proc/app.service journalctl -u app.service -b journalctl --vacuum app.service

Вопрос 7 из 20

Какие сообщения оставит команда journalctl -p err?

Все сообщения, кроме уровней warning и notice Уровень err и более важные: crit, alert и emerg Только сообщения об успешном запуске служб Только строки, где буквально встречается слово err

Вопрос 8 из 20

Как следить за новыми строками журнала в реальном времени?

journalctl -f -u app.service -o short-iso

journalctl --disk-usage journalctl -f с нужными фильтрами journalctl -r journalctl --list-boots

Вопрос 9 из 20

Как отфильтровать journal по точному PID 4120 в пределах текущей загрузки?

journalctl -b _PID=4120

journalctl -b --grep 4120 journalctl -b PID:4120 journalctl -b _PID=4120 journalctl -b /proc/4120

Вопрос 10 из 20

Зачем использовать journalctl -o json-pretty при сложном расследовании?

journalctl -u app.service -n 1 -o json-pretty

Скрыть бинарные поля и отключить временные метки Получить только исходный текст сообщений без служебных полей Увидеть структурированные поля для обработки Отсортировать сообщения по тексту без учёта метаданных

Вопрос 11 из 20

Как увидеть список загрузок, доступных в journal?

journalctl --list-boots
journalctl -b -1 -e

journalctl --list-boots journalctl --boots-all-files systemctl list-kernels lastlog --journal

Вопрос 12 из 20

Почему строки из двух серверов лучше сводить к UTC перед сортировкой?

Часовые зоны могут исказить порядок событий UTC делает журналы меньше NTP работает только в UTC Локальное время не содержит секунд

Вопрос 13 из 20

После logrotate процесс продолжает писать в старый app.log.1, а новый app.log пуст. Почему?

lsof /var/log/app/app.log*
kill -HUP "$pid"

Новый файл принадлежит другому ядру Процесс не переоткрыл старый inode журнала logrotate сам переключает открытый дескриптор процесса на новый файл rename копирует содержимое, но запрещает новые записи

Вопрос 14 из 20

Как точнее задать абсолютный интервал journalctl?

Сравнивать только номера строк Фильтровать grep по минуте без даты Удалить старые boot Задать --since и --until с полной датой и временем

Вопрос 15 из 20

Почему время записи не всегда равно времени возникновения события?

journalctl -o verbose -n 1 | grep -E '^(__REALTIME_TIMESTAMP|__MONOTONIC_TIMESTAMP|_BOOT_ID)='

Ядро не хранит часы Запись могла задержаться из-за буфера или сети PID определяет время journalctl сортирует записи по PID, когда источники пишут одновременно

Вопрос 16 из 20

После ошибки подключения приложение пишет сотни одинаковых сообщений. Где вероятнее первичная причина?

В последней строке цикла: она содержит окончательную причину сбоя Только в журнале самого приложения, не проверяя зависимый ресурс В сообщении с самым высоким приоритетом независимо от времени В первых сообщениях перед циклом повторов и в журнале зависимого ресурса

Вопрос 17 из 20

Служба умерла с кодом 137. Какую гипотезу проверить?

systemctl show app.service -p ExecMainCode -p ExecMainStatus -p Result
journalctl -k -b --since '2026-07-13 10:00'

SIGKILL, включая OOM; проверить kernel/cgroup logs Приложение вернуло системную ошибку с номером 137 Служба штатно завершилась после reload Процесс получил SIGTERM от systemd

Вопрос 18 из 20

В error.log nginx есть upstream timed out, а приложение в тот же момент пишет slow query 48s. Что вероятнее является более ранним звеном?

Nginx обязательно повредил базу Медленный запрос upstream довёл proxy до timeout Timeout nginx вызвал запрос задним числом Обе строки не могут быть связаны

Вопрос 19 из 20

Почему удаление огромного active.log может не освободить место?

rm /var/log/app/active.log
lsof +L1 | grep app

Файл превращается в swap Блоки освобождаются только после следующего sync файловой системы df обновляется раз в неделю Пишущий процесс продолжает держать удалённый inode открытым

Вопрос 20 из 20

Какая формулировка лучше описывает установленную первопричину?

Самая последняя ошибка в журнале Общее утверждение «Linux завис» Любое изменение, после которого стало лучше Проверяемое событие, подтверждённое независимыми данными

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу