Процессы, задания и сигналы — бесплатный тест онлайн

Вопрос 1 из 25

Этот участок из темы «Фоновые процессы» относится к практической части теста «Процессы, задания и сигналы». Что в этом коде произойдёт или останется верным при указанных условиях?

sleep 0.1 &
pid=$!
printf 'pid=%s\n' "$pid"
wait "$pid"
printf 'status=%s\n' "$?"

Сообщение о запуске не означает успех самой работы; без wait её отказ может никогда не повлиять на код сценария. Сценарий сохраняет PID, ждёт именно этот процесс и получает код 0 после его завершения. Обычный wait без учёта отдельных PID способен скрыть, какая задача упала, а его итоговый статус не является полным массивом результатов. wait обычно возвращает 143, то есть 128+15 для завершения по SIGTERM; успешный kill сам по себе имел код 0. Корректная остановка сначала посылает TERM, ждёт ограниченное время и только затем усиливает сигнал, учитывая возможность повторного использования PID.

Вопрос 2 из 25

Этот участок из темы «Ожидание процессов» относится к практической части теста «Процессы, задания и сигналы». Как следует оценить этот вариант с учётом синтаксиса Bash и вызванных программ?

(exit 3) & a=$!
(exit 7) & b=$!
wait "$a"; sa=$?
wait "$b"; sb=$?
printf '%s:%s\n' "$sa" "$sb"

Печатается 3:7: статусы сохранены отдельно после ожидания каждого PID. Корректная остановка сначала посылает TERM, ждёт ограниченное время и только затем усиливает сигнал, учитывая возможность повторного использования PID. Обычный wait без учёта отдельных PID способен скрыть, какая задача упала, а его итоговый статус не является полным массивом результатов. При включённом управлении заданиями jobs -p показывает PID фонового задания текущей оболочки, но состояние не переносится между отдельными запусками скрипта. PID может быть устаревшим, повторно выданным другому процессу или повреждённым; kill -0 подтверждает лишь доступ к текущему PID.

Вопрос 3 из 25

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

sleep 10 & pid=$!
kill "$pid"
wait "$pid"
printf '%s\n' "$?"

PID может быть устаревшим, повторно выданным другому процессу или повреждённым; kill -0 подтверждает лишь доступ к текущему PID. SIGKILL не даёт процессу выполнить обработчики и очистку; применять его первым шагом опасно для данных и временного состояния. Для долгоживущей задачи менеджер служб даёт явный жизненный цикл, журнал и статус вместо скрытого фонового процесса оболочки. wait обычно возвращает 143, то есть 128+15 для завершения по SIGTERM; успешный kill сам по себе имел код 0. После ! rc становится кодом инвертированного условия, а не исходным кодом job; нужно вызывать wait и сохранять статус без инверсии.

Вопрос 4 из 25

Этот участок из темы «Состояния заданий» относится к практической части теста «Процессы, задания и сигналы». Что точнее всего характеризует работу показанного кода?

set -m
sleep 5 &
jobs -p

При включённом управлении заданиями jobs -p показывает PID фонового задания текущей оболочки, но состояние не переносится между отдельными запусками скрипта. Корректная остановка сначала посылает TERM, ждёт ограниченное время и только затем усиливает сигнал, учитывая возможность повторного использования PID. PID может быть устаревшим, повторно выданным другому процессу или повреждённым; kill -0 подтверждает лишь доступ к текущему PID. Обычный wait без учёта отдельных PID способен скрыть, какая задача упала, а его итоговый статус не является полным массивом результатов. nohup меняет обработку SIGHUP и перенаправления по умолчанию, но не превращает процесс в управляемую службу и не обеспечивает перезапуск.

Вопрос 5 из 25

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

if [[ -f app.pid ]]; then
  kill -0 "$(cat app.pid)"
fi

Корректная остановка сначала посылает TERM, ждёт ограниченное время и только затем усиливает сигнал, учитывая возможность повторного использования PID. Два запуска могут одновременно перезаписать PID-файл и оба продолжить работу; trap не решает гонку взаимного исключения. При включённом управлении заданиями jobs -p показывает PID фонового задания текущей оболочки, но состояние не переносится между отдельными запусками скрипта. PID может быть устаревшим, повторно выданным другому процессу или повреждённым; kill -0 подтверждает лишь доступ к текущему PID. Обычный wait без учёта отдельных PID способен скрыть, какая задача упала, а его итоговый статус не является полным массивом результатов.

Вопрос 6 из 25

Разберите код без пробного запуска; его тема — «Фоновые процессы». Какой разбор не смешивает этот вариант с другими способами решения задачи?

start_job &
echo "started $!"
do_other_work

Сообщение о запуске не означает успех самой работы; без wait её отказ может никогда не повлиять на код сценария. Итоговый код сценария всегда совпадает с кодом последнего фонового задания, независимо от результата do_other_work и последующих команд. Переменная $! содержит код завершения фоновой команды, поэтому строка started подтверждает, что start_job уже успешно закончился. Ненулевой код фоновой команды автоматически становится ошибкой родительского сценария, даже если wait ни разу не вызван. Перед запуском следующей обычной команды Bash автоматически ждёт последний фоновый процесс, поэтому do_other_work начнётся после start_job.

Вопрос 7 из 25

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

jobs=(...)
wait
echo success

Корректная остановка сначала посылает TERM, ждёт ограниченное время и только затем усиливает сигнал, учитывая возможность повторного использования PID. wait обычно возвращает 143, то есть 128+15 для завершения по SIGTERM; успешный kill сам по себе имел код 0. SIGKILL не даёт процессу выполнить обработчики и очистку; применять его первым шагом опасно для данных и временного состояния. Обычный wait без учёта отдельных PID способен скрыть, какая задача упала, а его итоговый статус не является полным массивом результатов. Сценарий ждёт каждого ребёнка и накапливает факт отказа, не прекращая сбор остальных результатов.

Вопрос 8 из 25

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

kill -9 "$pid"

SIGKILL не даёт процессу выполнить обработчики и очистку; применять его первым шагом опасно для данных и временного состояния. Корректная остановка сначала посылает TERM, ждёт ограниченное время и только затем усиливает сигнал, учитывая возможность повторного использования PID. nohup меняет обработку SIGHUP и перенаправления по умолчанию, но не превращает процесс в управляемую службу и не обеспечивает перезапуск. Печатается 3:7: статусы сохранены отдельно после ожидания каждого PID. При включённом управлении заданиями jobs -p показывает PID фонового задания текущей оболочки, но состояние не переносится между отдельными запусками скрипта.

Вопрос 9 из 25

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

nohup long_task &

PID может быть устаревшим, повторно выданным другому процессу или повреждённым; kill -0 подтверждает лишь доступ к текущему PID. nohup меняет обработку SIGHUP и перенаправления по умолчанию, но не превращает процесс в управляемую службу и не обеспечивает перезапуск. Для долгоживущей задачи менеджер служб даёт явный жизненный цикл, журнал и статус вместо скрытого фонового процесса оболочки. Сценарий ждёт каждого ребёнка и накапливает факт отказа, не прекращая сбор остальных результатов. Печатается 3:7: статусы сохранены отдельно после ожидания каждого PID.

Вопрос 10 из 25

Разберите код без пробного запуска; его тема — «Проверка и диагностика». Что следует записать в заключении ревью этого фрагмента?

echo $$ > app.pid
trap 'rm -f app.pid' EXIT

Два запуска могут одновременно перезаписать PID-файл и оба продолжить работу; trap не решает гонку взаимного исключения. Файловая блокировка на открытом дескрипторе атомарно запрещает второй запуск на системах с flock и освобождается при завершении процесса. Сценарий сохраняет PID, ждёт именно этот процесс и получает код 0 после его завершения. Печатается 3:7: статусы сохранены отдельно после ожидания каждого PID. Обычный wait без учёта отдельных PID способен скрыть, какая задача упала, а его итоговый статус не является полным массивом результатов.

Вопрос 11 из 25

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

start_job & pid=$!
if ! wait "$pid"; then
  rc=$?
fi

Сценарий сохраняет PID, ждёт именно этот процесс и получает код 0 после его завершения. После ! rc становится кодом инвертированного условия, а не исходным кодом job; нужно вызывать wait и сохранять статус без инверсии. SIGKILL не даёт процессу выполнить обработчики и очистку; применять его первым шагом опасно для данных и временного состояния. При включённом управлении заданиями jobs -p показывает PID фонового задания текущей оболочки, но состояние не переносится между отдельными запусками скрипта. nohup меняет обработку SIGHUP и перенаправления по умолчанию, но не превращает процесс в управляемую службу и не обеспечивает перезапуск.

Вопрос 12 из 25

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

failed=0
for pid in "${pids[@]}"; do
  wait "$pid" || failed=1
done
((failed==0))

nohup меняет обработку SIGHUP и перенаправления по умолчанию, но не превращает процесс в управляемую службу и не обеспечивает перезапуск. Сценарий ждёт каждого ребёнка и накапливает факт отказа, не прекращая сбор остальных результатов. Файловая блокировка на открытом дескрипторе атомарно запрещает второй запуск на системах с flock и освобождается при завершении процесса. Для долгоживущей задачи менеджер служб даёт явный жизненный цикл, журнал и статус вместо скрытого фонового процесса оболочки. Печатается 3:7: статусы сохранены отдельно после ожидания каждого PID.

Вопрос 13 из 25

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

kill -TERM "$pid" 2>/dev/null || true
for _ in {1..20}; do kill -0 "$pid" 2>/dev/null || break; sleep .1; done
kill -KILL "$pid" 2>/dev/null || true

Сообщение о запуске не означает успех самой работы; без wait её отказ может никогда не повлиять на код сценария. После ! rc становится кодом инвертированного условия, а не исходным кодом job; нужно вызывать wait и сохранять статус без инверсии. Файловая блокировка на открытом дескрипторе атомарно запрещает второй запуск на системах с flock и освобождается при завершении процесса. Корректная остановка сначала посылает TERM, ждёт ограниченное время и только затем усиливает сигнал, учитывая возможность повторного использования PID. wait обычно возвращает 143, то есть 128+15 для завершения по SIGTERM; успешный kill сам по себе имел код 0.

Вопрос 14 из 25

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

systemd-run --user --unit=my-task long_task

Сообщение о запуске не означает успех самой работы; без wait её отказ может никогда не повлиять на код сценария. Для долгоживущей задачи менеджер служб даёт явный жизненный цикл, журнал и статус вместо скрытого фонового процесса оболочки. Сценарий сохраняет PID, ждёт именно этот процесс и получает код 0 после его завершения. Печатается 3:7: статусы сохранены отдельно после ожидания каждого PID. При включённом управлении заданиями jobs -p показывает PID фонового задания текущей оболочки, но состояние не переносится между отдельными запусками скрипта.

Вопрос 15 из 25

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

exec 9>app.lock
flock -n 9 || exit 75

PID может быть устаревшим, повторно выданным другому процессу или повреждённым; kill -0 подтверждает лишь доступ к текущему PID. Файловая блокировка на открытом дескрипторе атомарно запрещает второй запуск на системах с flock и освобождается при завершении процесса. Для долгоживущей задачи менеджер служб даёт явный жизненный цикл, журнал и статус вместо скрытого фонового процесса оболочки. Сообщение о запуске не означает успех самой работы; без wait её отказ может никогда не повлиять на код сценария. После ! rc становится кодом инвертированного условия, а не исходным кодом job; нужно вызывать wait и сохранять статус без инверсии.

Вопрос 16 из 25

Разработчики спорят о границах механизма «Фоновые процессы». Какую оговорку стоит вынести в описание эксплуатационного контракта?

wait -n ждёт любое следующее завершение, а в новых Bash -p может записать идентификатор; доступность этих возможностей зависит от версии. Сценарий сохраняет PID, ждёт именно этот процесс и получает код 0 после его завершения. kill -0 не посылает сигнал, но проверяет существование процесса и право сигнализировать; это не доказывает, что PID всё ещё принадлежит нужной задаче. Диагностика процесса должна связывать PID, командную строку, время запуска, родителя и открытые ресурсы; одна команда ps с усечённым выводом может вводить в заблуждение. Фоновый процесс наследует открытые дескрипторы и окружение; он может удерживать канал или временный файл после завершения родительской логики.

Вопрос 17 из 25

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

wait -n ждёт любое следующее завершение, а в новых Bash -p может записать идентификатор; доступность этих возможностей не зависит от версии. kill -0 не посылает сигнал, но проверяет существование процесса и право сигнализировать; это не доказывает, что PID всё ещё принадлежит нужной задаче. disown — интерактивная возможность Bash, зависящая от таблицы заданий; её отсутствие в /bin/sh и неинтерактивной среде нужно учитывать. Фоновый процесс наследует открытые дескрипторы и окружение; он может удерживать канал или временный файл после завершения родительской логики. wait -n ждёт любое следующее завершение, а в новых Bash -p может записать идентификатор; доступность этих возможностей зависит от версии.

Вопрос 18 из 25

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

kill -0 не посылает сигнал, но не проверяет существование процесса и право сигнализировать; это не доказывает, что PID всё ещё принадлежит нужной задаче. disown — интерактивная возможность Bash, зависящая от таблицы заданий; её отсутствие в /bin/sh и неинтерактивной среде нужно учитывать. kill -0 не посылает сигнал, но проверяет существование процесса и право сигнализировать; это не доказывает, что PID всё ещё принадлежит нужной задаче. Диагностика процесса должна связывать PID, командную строку, время запуска, родителя и открытые ресурсы; одна команда ps с усечённым выводом может вводить в заблуждение. wait -n ждёт любое следующее завершение, а в новых Bash -p может записать идентификатор; доступность этих возможностей зависит от версии.

Вопрос 19 из 25

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

При включённом управлении заданиями jobs -p показывает PID фонового задания текущей оболочки, но состояние не переносится между отдельными запусками скрипта. kill -0 не посылает сигнал, но проверяет существование процесса и право сигнализировать; это не доказывает, что PID всё ещё принадлежит нужной задаче. wait -n ждёт любое следующее завершение, а в новых Bash -p может записать идентификатор; доступность этих возможностей зависит от версии. disown — интерактивная возможность Bash, зависящая от таблицы заданий; её отсутствие в /bin/sh и неинтерактивной среде нужно учитывать. Диагностика процесса должна связывать PID, командную строку, время запуска, родителя и открытые ресурсы; одна команда ps с усечённым выводом может вводить в заблуждение.

Вопрос 20 из 25

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

Диагностика процесса должна связывать PID, командную строку, время запуска, родителя и открытые ресурсы; одна команда ps с усечённым выводом может вводить в заблуждение. disown — интерактивная возможность Bash, зависящая от таблицы заданий; её отсутствие в /bin/sh и неинтерактивной среде нужно учитывать. PID может быть устаревшим, повторно выданным другому процессу или повреждённым; kill -0 подтверждает лишь доступ к текущему PID. kill -0 не посылает сигнал, но проверяет существование процесса и право сигнализировать; это не доказывает, что PID всё ещё принадлежит нужной задаче. Фоновый процесс наследует открытые дескрипторы и окружение; он может удерживать канал или временный файл после завершения родительской логики.

Вопрос 21 из 25

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

jobs, fg и bg относятся к управлению заданиями текущей оболочки и обычно не подходят как интерфейс неинтерактивного служебного сценария. kill по умолчанию отправляет SIGTERM и сообщает только об успешной передаче сигнала, а не о фактическом завершении процесса. wait PID возвращает код завершения указанного дочернего процесса; wait без аргументов ждёт всех известных детей, но не даёт отдельный статус каждого. Оператор & не запускает конвейер асинхронно, а $! содержит PID последнего фонового процесса или лидера соответствующего задания. Оператор & запускает конвейер асинхронно, а $! содержит PID последнего фонового процесса или лидера соответствующего задания.

Вопрос 22 из 25

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

kill по умолчанию отправляет SIGTERM и сообщает только об успешной передаче сигнала, а не о фактическом завершении процесса. Оператор & запускает конвейер асинхронно, а $! содержит PID последнего фонового процесса или лидера соответствующего задания. wait PID не возвращает код завершения указанного дочернего процесса; wait без аргументов ждёт всех известных детей, но не даёт отдельный статус каждого. jobs, fg и bg относятся к управлению заданиями текущей оболочки и обычно не подходят как интерфейс неинтерактивного служебного сценария. wait PID возвращает код завершения указанного дочернего процесса; wait без аргументов ждёт всех известных детей, но не даёт отдельный статус каждого.

Вопрос 23 из 25

Для блока «Отправка сигналов» требуется формулировка без лишних обещаний. Какое правило лучше всего объясняет корректный способ решения?

Оператор & запускает конвейер асинхронно, а $! содержит PID последнего фонового процесса или лидера соответствующего задания. jobs, fg и bg относятся к управлению заданиями текущей оболочки и обычно не подходят как интерфейс неинтерактивного служебного сценария. wait обычно возвращает 143, то есть 128+15 для завершения по SIGTERM; успешный kill сам по себе имел код 0. kill по умолчанию отправляет SIGTERM и сообщает только об успешной передаче сигнала, а не о фактическом завершении процесса. wait PID возвращает код завершения указанного дочернего процесса; wait без аргументов ждёт всех известных детей, но не даёт отдельный статус каждого.

Вопрос 24 из 25

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

jobs, fg и bg относятся к управлению заданиями текущей оболочки и обычно не подходят как интерфейс неинтерактивного служебного сценария. wait PID возвращает код завершения указанного дочернего процесса; wait без аргументов ждёт всех известных детей, но не даёт отдельный статус каждого. PID-файл сам по себе не доказывает, что процесс жив и относится к нужной программе; нужны блокировка и проверка идентичности. При включённом управлении заданиями jobs -p показывает PID фонового задания текущей оболочки, но состояние не переносится между отдельными запусками скрипта. kill по умолчанию отправляет SIGTERM и сообщает только об успешной передаче сигнала, а не о фактическом завершении процесса.

Вопрос 25 из 25

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

wait PID возвращает код завершения указанного дочернего процесса; wait без аргументов ждёт всех известных детей, но не даёт отдельный статус каждого. kill по умолчанию отправляет SIGTERM и сообщает только об успешной передаче сигнала, а не о фактическом завершении процесса. PID может быть устаревшим, повторно выданным другому процессу или повреждённым; kill -0 подтверждает лишь доступ к текущему PID. jobs, fg и bg относятся к управлению заданиями текущей оболочки и обычно не подходят как интерфейс неинтерактивного служебного сценария. PID-файл сам по себе не доказывает, что процесс жив и относится к нужной программе; нужны блокировка и проверка идентичности.