systemd и служебные сценарии — бесплатный тест онлайн

Вопрос 1 из 30

Разберите код без пробного запуска; его тема — «Unit-файл». Не предполагая намерение автора, что можно утверждать об этой конструкции?

[Service]
ExecStart=/usr/bin/echo $HOME

Полное значение задают явно либо используют подходящие механизмы systemd, не рассчитывая на профиль оболочки. Если оболочечная подготовка закончена, exec заменяет shell рабочим процессом, и systemd сигнализирует ему напрямую. Неэкранированная переменная из EnvironmentFile становится частью shell-кода и создаёт риск разбиения или инъекции. Явный Bash включает shell-семантику, но добавляет слой кавычек; для простых аргументов лучше передать их непосредственно без -c. systemd не выполнит обычную shell-подстановку $HOME; аргумент может остаться буквальным или обрабатываться по собственным правилам спецификаторов.

Вопрос 2 из 30

Разберите код без пробного запуска; его тема — «Окружение службы». Какое утверждение точно относится к показанному фрагменту?

[Service]
Environment="PORT=8080" "GREETING=hello world"
ExecStart=/opt/app/run

daemon-reload перечитывает unit, но немедленный restart без verify и просмотра diff может уронить работающую службу. Процесс получает две переменные, причём пробел сохраняется внутри GREETING благодаря кавычкам синтаксиса unit. Проверка находит неизвестные директивы и часть ошибок синтаксиса до перезапуска менеджера. Прямой запуск сохраняет предсказуемые аргументы и позволяет systemd отслеживать основной процесс без промежуточной оболочки. Обычная подстановка $PATH не выполняется как в Bash; служба может получить буквальный фрагмент $PATH.

Вопрос 3 из 30

Разберите код без пробного запуска; его тема — «Перезапуск службы». Какой вывод об этом варианте можно сделать без догадок о внешнем контексте?

[Service]
Restart=always
RestartSec=0

Оболочка ждёт ребёнка, но без trap может не переслать TERM так, как ожидается; systemd может отслеживать shell как главный процесс. Служба, мгновенно завершающаяся из-за постоянной ошибки, будет часто перезапускаться до срабатывания ограничителей start rate. Обработчик пересылает сигнал и ждёт завершения ребёнка, сохраняя возможность его очистки. Задержка и лимит снижают шторм повторов, но постоянный дефект всё равно должен завершиться заметным failed-состоянием. Полное значение задают явно либо используют подходящие механизмы systemd, не рассчитывая на профиль оболочки.

Вопрос 4 из 30

Разберите код без пробного запуска; его тема — «Корректное завершение». Какой разбор соответствует именно показанной последовательности команд?

#!/usr/bin/env bash
/opt/app/worker &
wait

Полное значение задают явно либо используют подходящие механизмы systemd, не рассчитывая на профиль оболочки. Обработчик пересылает сигнал и ждёт завершения ребёнка, сохраняя возможность его очистки. Процесс получает две переменные, причём пробел сохраняется внутри GREETING благодаря кавычкам синтаксиса unit. Оболочка ждёт ребёнка, но без trap может не переслать TERM так, как ожидается; systemd может отслеживать shell как главный процесс. Процесс не получает новые привилегии, видит системные пути read-only и может писать только в явно разрешённое место.

Вопрос 5 из 30

Разберите код без пробного запуска; его тема — «Проверка и диагностика». Какое описание не приписывает фрагменту лишних гарантий?

systemd-analyze verify /etc/systemd/system/app.service

Проверка находит неизвестные директивы и часть ошибок синтаксиса до перезапуска менеджера. daemon-reload перечитывает unit, но немедленный restart без verify и просмотра diff может уронить работающую службу. Неэкранированная переменная из EnvironmentFile становится частью shell-кода и создаёт риск разбиения или инъекции. Оболочка ждёт ребёнка, но без trap может не переслать TERM так, как ожидается; systemd может отслеживать shell как главный процесс. Если оболочечная подготовка закончена, exec заменяет shell рабочим процессом, и systemd сигнализирует ему напрямую.

Вопрос 6 из 30

Разберите код без пробного запуска; его тема — «Безопасность и переносимость». Не предполагая намерение автора, что можно утверждать об этой конструкции?

[Service]
User=app
NoNewPrivileges=yes
ProtectSystem=strict
ReadWritePaths=/var/lib/app

Проверка находит неизвестные директивы и часть ошибок синтаксиса до перезапуска менеджера. Обработчик пересылает сигнал и ждёт завершения ребёнка, сохраняя возможность его очистки. Процесс не получает новые привилегии, видит системные пути read-only и может писать только в явно разрешённое место. Неэкранированная переменная из EnvironmentFile становится частью shell-кода и создаёт риск разбиения или инъекции. daemon-reload перечитывает unit, но немедленный restart без verify и просмотра diff может уронить работающую службу.

Вопрос 7 из 30

Для блока «Unit-файл» сравнивают несколько внешне похожих решений. Что действительно гарантирует или, наоборот, не гарантирует эта конструкция?

[Service]
ExecStart=/usr/bin/bash -c 'exec /opt/app/run --home "$HOME"'

Служба, мгновенно завершающаяся из-за постоянной ошибки, будет часто перезапускаться до срабатывания ограничителей start rate. Полное значение задают явно либо используют подходящие механизмы systemd, не рассчитывая на профиль оболочки. Прямой запуск сохраняет предсказуемые аргументы и позволяет systemd отслеживать основной процесс без промежуточной оболочки. Обычная подстановка $PATH не выполняется как в Bash; служба может получить буквальный фрагмент $PATH. Явный Bash включает shell-семантику, но добавляет слой кавычек; для простых аргументов лучше передать их непосредственно без -c.

Вопрос 8 из 30

Для блока «Окружение службы» сравнивают несколько внешне похожих решений. Фрагмент запускают как часть служебного сценария. Как его следует оценить?

Environment="PATH=/opt/app/bin:$PATH"

Прямой запуск сохраняет предсказуемые аргументы и позволяет systemd отслеживать основной процесс без промежуточной оболочки. Обычная подстановка $PATH не выполняется как в Bash; служба может получить буквальный фрагмент $PATH. Задержка и лимит снижают шторм повторов, но постоянный дефект всё равно должен завершиться заметным failed-состоянием. Полное значение задают явно либо используют подходящие механизмы systemd, не рассчитывая на профиль оболочки. Объявлять временный отказ 75 «успехом» опасно, если Restart=on-failure должен на него реагировать; семантику кодов нужно согласовать.

Вопрос 9 из 30

Для блока «Перезапуск службы» сравнивают несколько внешне похожих решений. Какой вывод наиболее точно привязан к показанной реализации?

Restart=on-failure
RestartSec=5s
StartLimitBurst=3

Задержка и лимит снижают шторм повторов, но постоянный дефект всё равно должен завершиться заметным failed-состоянием. Объявлять временный отказ 75 «успехом» опасно, если Restart=on-failure должен на него реагировать; семантику кодов нужно согласовать. Фактический код и причина полезны, но вывод Environment может содержать секреты и требует осторожности. Явный Bash включает shell-семантику, но добавляет слой кавычек; для простых аргументов лучше передать их непосредственно без -c. Если оболочечная подготовка закончена, exec заменяет shell рабочим процессом, и systemd сигнализирует ему напрямую.

Вопрос 10 из 30

Для блока «Корректное завершение» сравнивают несколько внешне похожих решений. Какое утверждение о поведении кода остаётся точным на граничном входе?

trap 'kill -TERM "$child" 2>/dev/null; wait "$child"' TERM INT
/opt/app/worker & child=$!
wait "$child"

Если оболочечная подготовка закончена, exec заменяет shell рабочим процессом, и systemd сигнализирует ему напрямую. Программа должна читать переменные как данные; если нужны составные аргументы, безопаснее конфигурационный файл или фиксированная обёртка с проверкой. Обработчик пересылает сигнал и ждёт завершения ребёнка, сохраняя возможность его очистки. Процесс не получает новые привилегии, видит системные пути read-only и может писать только в явно разрешённое место. Процесс получает две переменные, причём пробел сохраняется внутри GREETING благодаря кавычкам синтаксиса unit.

Вопрос 11 из 30

Для блока «Проверка и диагностика» сравнивают несколько внешне похожих решений. Что важно заметить в этом фрагменте до его включения в автоматизацию?

systemctl daemon-reload
systemctl restart app

daemon-reload перечитывает unit, но немедленный restart без verify и просмотра diff может уронить работающую службу. Если оболочечная подготовка закончена, exec заменяет shell рабочим процессом, и systemd сигнализирует ему напрямую. Неэкранированная переменная из EnvironmentFile становится частью shell-кода и создаёт риск разбиения или инъекции. Фактический код и причина полезны, но вывод Environment может содержать секреты и требует осторожности. Обработчик пересылает сигнал и ждёт завершения ребёнка, сохраняя возможность его очистки.

Вопрос 12 из 30

Для блока «Безопасность и переносимость» сравнивают несколько внешне похожих решений. Что действительно гарантирует или, наоборот, не гарантирует эта конструкция?

ExecStart=/bin/bash -c '/opt/app/run $OPTIONS'

Программа должна читать переменные как данные; если нужны составные аргументы, безопаснее конфигурационный файл или фиксированная обёртка с проверкой. Задержка и лимит снижают шторм повторов, но постоянный дефект всё равно должен завершиться заметным failed-состоянием. Неэкранированная переменная из EnvironmentFile становится частью shell-кода и создаёт риск разбиения или инъекции. Объявлять временный отказ 75 «успехом» опасно, если Restart=on-failure должен на него реагировать; семантику кодов нужно согласовать. Процесс получает две переменные, причём пробел сохраняется внутри GREETING благодаря кавычкам синтаксиса unit.

Вопрос 13 из 30

В служебном сценарии найден следующий фрагмент по теме «Unit-файл». Что является главным свойством этого варианта?

[Service]
ExecStart=/opt/app/run --mode=worker

Программа должна читать переменные как данные; если нужны составные аргументы, безопаснее конфигурационный файл или фиксированная обёртка с проверкой. Обычная подстановка $PATH не выполняется как в Bash; служба может получить буквальный фрагмент $PATH. Служба, мгновенно завершающаяся из-за постоянной ошибки, будет часто перезапускаться до срабатывания ограничителей start rate. systemd не выполнит обычную shell-подстановку $HOME; аргумент может остаться буквальным или обрабатываться по собственным правилам спецификаторов. Прямой запуск сохраняет предсказуемые аргументы и позволяет systemd отслеживать основной процесс без промежуточной оболочки.

Вопрос 14 из 30

В служебном сценарии найден следующий фрагмент по теме «Окружение службы». Как следует оценить конструкцию, не считая её автоматически исправлением?

Environment="PATH=/opt/app/bin:/usr/bin:/bin"

Процесс получает две переменные, причём пробел сохраняется внутри GREETING благодаря кавычкам синтаксиса unit. Полное значение задают явно либо используют подходящие механизмы systemd, не рассчитывая на профиль оболочки. Задержка и лимит снижают шторм повторов, но постоянный дефект всё равно должен завершиться заметным failed-состоянием. Объявлять временный отказ 75 «успехом» опасно, если Restart=on-failure должен на него реагировать; семантику кодов нужно согласовать. Обработчик пересылает сигнал и ждёт завершения ребёнка, сохраняя возможность его очистки.

Вопрос 15 из 30

В служебном сценарии найден следующий фрагмент по теме «Перезапуск службы». Какое суждение правильно описывает показанную реализацию?

SuccessExitStatus=75

Объявлять временный отказ 75 «успехом» опасно, если Restart=on-failure должен на него реагировать; семантику кодов нужно согласовать. Проверка находит неизвестные директивы и часть ошибок синтаксиса до перезапуска менеджера. Фактический код и причина полезны, но вывод Environment может содержать секреты и требует осторожности. Прямой запуск сохраняет предсказуемые аргументы и позволяет systemd отслеживать основной процесс без промежуточной оболочки. Служба, мгновенно завершающаяся из-за постоянной ошибки, будет часто перезапускаться до срабатывания ограничителей start rate.

Вопрос 16 из 30

В служебном сценарии найден следующий фрагмент по теме «Корректное завершение». Какой ответ учитывает и полезный эффект, и остающееся ограничение кода?

exec /opt/app/worker

Процесс получает две переменные, причём пробел сохраняется внутри GREETING благодаря кавычкам синтаксиса unit. Если оболочечная подготовка закончена, exec заменяет shell рабочим процессом, и systemd сигнализирует ему напрямую. Программа должна читать переменные как данные; если нужны составные аргументы, безопаснее конфигурационный файл или фиксированная обёртка с проверкой. Оболочка ждёт ребёнка, но без trap может не переслать TERM так, как ожидается; systemd может отслеживать shell как главный процесс. Процесс не получает новые привилегии, видит системные пути read-only и может писать только в явно разрешённое место.

Вопрос 17 из 30

В служебном сценарии найден следующий фрагмент по теме «Проверка и диагностика». Код предлагают как альтернативу. Какова его точная техническая оценка?

systemctl show app -p ExecMainStatus -p Result -p Environment

Проверка находит неизвестные директивы и часть ошибок синтаксиса до перезапуска менеджера. Обычная подстановка $PATH не выполняется как в Bash; служба может получить буквальный фрагмент $PATH. Процесс не получает новые привилегии, видит системные пути read-only и может писать только в явно разрешённое место. Полное значение задают явно либо используют подходящие механизмы systemd, не рассчитывая на профиль оболочки. Фактический код и причина полезны, но вывод Environment может содержать секреты и требует осторожности.

Вопрос 18 из 30

В служебном сценарии найден следующий фрагмент по теме «Безопасность и переносимость». Что является главным свойством этого варианта?

ExecStart=/opt/app/run
EnvironmentFile=/etc/app/env

Программа должна читать переменные как данные; если нужны составные аргументы, безопаснее конфигурационный файл или фиксированная обёртка с проверкой. Объявлять временный отказ 75 «успехом» опасно, если Restart=on-failure должен на него реагировать; семантику кодов нужно согласовать. Обычная подстановка $PATH не выполняется как в Bash; служба может получить буквальный фрагмент $PATH. Процесс не получает новые привилегии, видит системные пути read-only и может писать только в явно разрешённое место. Процесс получает две переменные, причём пробел сохраняется внутри GREETING благодаря кавычкам синтаксиса unit.

Вопрос 19 из 30

Для блока «Unit-файл» требуется формулировка без лишних обещаний. Какой эксплуатационный компромисс здесь нельзя скрывать за успешным кодом возврата?

systemd не выполнит обычную shell-подстановку $HOME; аргумент может остаться буквальным или обрабатываться по собственным правилам спецификаторов. EnvironmentFile удобен для настроек, но не является безопасным хранилищем секретов; права, credentials-механизмы и журналирование требуют отдельной политики. Некоторые hardening-директивы требуют конкретной версии systemd; переносимый пакет должен объявлять минимальную версию и иметь проверяемый запасной режим. ProtectSystem, PrivateTmp и другие ограничения меняют доступные пути и пространство имён; успешный запуск от того же пользователя вне systemd не доказывает работоспособность. В одном ExecStart перенос строки и префиксы имеют специальный синтаксис systemd; unit нельзя проверять только bash -n.

Вопрос 20 из 30

Для блока «Окружение службы» требуется формулировка без лишних обещаний. Что обязательно нужно проверить в соседнем сценарии, чтобы не получить ложную надёжность?

KillMode определяет, получает ли сигнал только главный процесс или вся cgroup; фоновые внуки без учёта этой политики могут остаться жить. EnvironmentFile удобен для настроек, но является безопасным хранилищем секретов; права, credentials-механизмы и журналирование требуют отдельной политики. Некоторые hardening-директивы требуют конкретной версии systemd; переносимый пакет должен объявлять минимальную версию и иметь проверяемый запасной режим. В одном ExecStart перенос строки и префиксы имеют специальный синтаксис systemd; unit нельзя проверять только bash -n. EnvironmentFile удобен для настроек, но не является безопасным хранилищем секретов; права, credentials-механизмы и журналирование требуют отдельной политики.

Вопрос 21 из 30

Для блока «Перезапуск службы» требуется формулировка без лишних обещаний. На какой границе эта техника перестаёт быть достаточной сама по себе?

В одном ExecStart перенос строки и префиксы имеют специальный синтаксис systemd; unit нельзя проверять только bash -n. KillMode определяет, получает ли сигнал только главный процесс или вся cgroup; фоновые внуки без учёта этой политики могут остаться жить. Служба, мгновенно завершающаяся из-за постоянной ошибки, будет часто перезапускаться до срабатывания ограничителей start rate. EnvironmentFile удобен для настроек, но не является безопасным хранилищем секретов; права, credentials-механизмы и журналирование требуют отдельной политики. Restart не заменяет внутреннюю идемпотентность: процесс может упасть после частичной записи, и повтор запустит ту же операцию заново.

Вопрос 22 из 30

Для блока «Корректное завершение» требуется формулировка без лишних обещаний. Где заканчивается защита, которую даёт рассматриваемая конструкция?

KillMode определяет, получает ли сигнал только главный процесс или вся cgroup; фоновые внуки без учёта этой политики могут остаться жить. Restart не заменяет внутреннюю идемпотентность: процесс может упасть после частичной записи, и повтор запустит ту же операцию заново. EnvironmentFile удобен для настроек, но не является безопасным хранилищем секретов; права, credentials-механизмы и журналирование требуют отдельной политики. KillMode определяет, не получает ли сигнал только главный процесс или вся cgroup; фоновые внуки без учёта этой политики могут остаться жить. ProtectSystem, PrivateTmp и другие ограничения меняют доступные пути и пространство имён; успешный запуск от того же пользователя вне systemd не доказывает работоспособность.

Вопрос 23 из 30

Для блока «Проверка и диагностика» требуется формулировка без лишних обещаний. Что способно нарушить ожидаемый результат, хотя основной фрагмент написан корректно?

ProtectSystem, PrivateTmp и другие ограничения меняют доступные пути и пространство имён; успешный запуск от того же пользователя вне systemd не доказывает работоспособность. Некоторые hardening-директивы требуют конкретной версии systemd; переносимый пакет должен объявлять минимальную версию и иметь проверяемый запасной режим. KillMode определяет, получает ли сигнал только главный процесс или вся cgroup; фоновые внуки без учёта этой политики могут остаться жить. В одном ExecStart перенос строки и префиксы имеют специальный синтаксис systemd; unit нельзя проверять только bash -n. ProtectSystem, PrivateTmp и другие ограничения меняют доступные пути и пространство имён; неуспешный запуск от того же пользователя вне systemd не доказывает работоспособность.

Вопрос 24 из 30

Для блока «Безопасность и переносимость» требуется формулировка без лишних обещаний. Какой эксплуатационный компромисс здесь нельзя скрывать за успешным кодом возврата?

Процесс не получает новые привилегии, видит системные пути read-only и может писать только в явно разрешённое место. EnvironmentFile удобен для настроек, но не является безопасным хранилищем секретов; права, credentials-механизмы и журналирование требуют отдельной политики. ProtectSystem, PrivateTmp и другие ограничения меняют доступные пути и пространство имён; успешный запуск от того же пользователя вне systemd не доказывает работоспособность. Некоторые hardening-директивы требуют конкретной версии systemd; переносимый пакет должен объявлять минимальную версию и иметь проверяемый запасной режим. В одном ExecStart перенос строки и префиксы имеют специальный синтаксис systemd; unit нельзя проверять только bash -n.

Вопрос 25 из 30

В тесте «systemd и служебные сценарии» разбирается тема «Unit-файл». Какая формулировка связывает частные примеры одним проверяемым правилом?

Environment= не выполняет shell-расширения, а EnvironmentFile читает собственный формат; секреты в unit доступны через конфигурацию и свойства службы. ExecStart не проходит через shell по умолчанию: конвейеры, перенаправления и $VAR не работают как в интерактивном Bash без явного запуска оболочки. Служебный сценарий должен работать с минимальными правами, фиксированным пользователем и ограничениями файловой системы, а не полагаться на root по умолчанию. Restart= определяет, при каких завершениях systemd запускает процесс снова; слишком агрессивная политика создаёт цикл отказов и нагрузку. systemd не выполнит обычную shell-подстановку $HOME; аргумент может остаться буквальным или обрабатываться по собственным правилам спецификаторов.

Вопрос 26 из 30

В тесте «systemd и служебные сценарии» разбирается тема «Окружение службы». Что в этой теме является свойством языка, а не случайностью конкретного запуска?

ExecStart не проходит через shell по умолчанию: конвейеры, перенаправления и $VAR не работают как в интерактивном Bash без явного запуска оболочки. Environment= не выполняет shell-расширения, а EnvironmentFile читает собственный формат; секреты в unit доступны через конфигурацию и свойства службы. systemd-analyze verify проверяет unit, а journalctl и systemctl show раскрывают фактические свойства; ручной запуск сценария не воспроизводит sandbox. Environment= не выполняет shell-расширения, а EnvironmentFile не читает собственный формат; секреты в unit доступны через конфигурацию и свойства службы. Restart= определяет, при каких завершениях systemd запускает процесс снова; слишком агрессивная политика создаёт цикл отказов и нагрузку.

Вопрос 27 из 30

В тесте «systemd и служебные сценарии» разбирается тема «Перезапуск службы». Какое утверждение точнее всего описывает контракт рассматриваемого механизма?

systemd обычно посылает SIGTERM и после TimeoutStopSec усиливает остановку; сценарий должен переслать сигнал рабочему процессу и дождаться его. systemd-analyze verify проверяет unit, а journalctl и systemctl show раскрывают фактические свойства; ручной запуск сценария не воспроизводит sandbox. Restart= определяет, при каких завершениях systemd запускает процесс снова; слишком агрессивная политика не создаёт цикл отказов и нагрузку. Restart= определяет, при каких завершениях systemd запускает процесс снова; слишком агрессивная политика создаёт цикл отказов и нагрузку. Environment= не выполняет shell-расширения, а EnvironmentFile читает собственный формат; секреты в unit доступны через конфигурацию и свойства службы.

Вопрос 28 из 30

В тесте «systemd и служебные сценарии» разбирается тема «Корректное завершение». Какое правило позволяет правильно разобрать эту тему до запуска кода?

Оболочка ждёт ребёнка, но без trap может не переслать TERM так, как ожидается; systemd может отслеживать shell как главный процесс. Служебный сценарий должен работать с минимальными правами, фиксированным пользователем и ограничениями файловой системы, а не полагаться на root по умолчанию. systemd-analyze verify проверяет unit, а journalctl и systemctl show раскрывают фактические свойства; ручной запуск сценария не воспроизводит sandbox. Restart= определяет, при каких завершениях systemd запускает процесс снова; слишком агрессивная политика создаёт цикл отказов и нагрузку. systemd обычно посылает SIGTERM и после TimeoutStopSec усиливает остановку; сценарий должен переслать сигнал рабочему процессу и дождаться его.

Вопрос 29 из 30

В тесте «systemd и служебные сценарии» разбирается тема «Проверка и диагностика». Какое свойство механизма нельзя подменять удачным примером запуска?

systemd-analyze verify не проверяет unit, а journalctl и systemctl show раскрывают фактические свойства; ручной запуск сценария не воспроизводит sandbox. Служебный сценарий должен работать с минимальными правами, фиксированным пользователем и ограничениями файловой системы, а не полагаться на root по умолчанию. Environment= не выполняет shell-расширения, а EnvironmentFile читает собственный формат; секреты в unit доступны через конфигурацию и свойства службы. systemd обычно посылает SIGTERM и после TimeoutStopSec усиливает остановку; сценарий должен переслать сигнал рабочему процессу и дождаться его. systemd-analyze verify проверяет unit, а journalctl и systemctl show раскрывают фактические свойства; ручной запуск сценария не воспроизводит sandbox.

Вопрос 30 из 30

В тесте «systemd и служебные сценарии» разбирается тема «Безопасность и переносимость». Какая формулировка связывает частные примеры одним проверяемым правилом?

systemd обычно посылает SIGTERM и после TimeoutStopSec усиливает остановку; сценарий должен переслать сигнал рабочему процессу и дождаться его. ExecStart не проходит через shell по умолчанию: конвейеры, перенаправления и $VAR не работают как в интерактивном Bash без явного запуска оболочки. Служебный сценарий должен работать с минимальными правами, фиксированным пользователем и ограничениями файловой системы, а не полагаться на root по умолчанию. Процесс не получает новые привилегии, видит системные пути read-only и может писать только в явно разрешённое место. systemd-analyze verify проверяет unit, а journalctl и systemctl show раскрывают фактические свойства; ручной запуск сценария не воспроизводит sandbox.