Вариант использования / практический пример для встроенного exec Bash

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

while(true) fork();

Теперь, когда каждый слот в таблице процессов, который вам разрешено использовать, заполнен копиями этой запущенной программы, как вы собираетесь ее убить? Для запуска kill (1) требуется еще один слот процесса, которого у вас не может быть. Было бы удобно, если бы оболочка заменила себя командой kill ...

exec /bin/kill -9 -1

(Предполагается, что в вашей системе есть kill (1) в / bin / kill. "Exec` which kill` -9 -1 "потенциально безопаснее .) Это отправляет SIGKILL каждому процессу, который вы можете.

(Примечание: не выходите из своей запускающей оболочки, если только ограничения процесса всегда разрешают новый вход в слот процесса для его оболочки. Это может быть немного сложнее очистить, если вы это сделаете. Я, конечно, не делал это в начале 90-х. Нет.)

Я использовал встроенный модуль shell exec для получения идентификатора процесса (PID) программы Java. Возможно, сейчас есть способ получить PID изнутри Java, но несколько лет назад его не было. Как только процесс получает свой собственный PID, он может записать его в файл PID (ищите в /var/run/ имена файлов с суффиксом '.pid'), чтобы управляющие программы могли узнать PID запущенного процесса и предотвратить запуск второго экземпляра одного и того же сервера. Это работает примерно так:

exec java -cp=YourServer.jar StartClass -p $$

Код в методе main() класса StartClass обрабатывает разбор аргументов и может найти свой собственный идентификатор процесса.

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

#!/bin/sh

if stuff;
    EXTRA_OPTIONS="-x -y -z"
else
    EXTRA_OPTIONS="-a foo"
fi

exec /usr/local/bin/the.real.binary $EXTRA_OPTIONS "$@"

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

В своем вопросе вы также упоминаете перенаправление ввода-вывода. Это совсем другой случай использования exec и не имеет ничего общего с заменой оболочки другим процессом. Когда exec не имеет аргументов, как например:

exec 3>>/tmp/logfile

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

• Это похоже на пример Брюса, когда необходимо знать PID процесса:

   (cmdpid = $ BASHPID; (sleep 300; kill "$ cmdpid ") & exec  long-running-command ) 

  , в которой вы

  1. запускаете подоболочку (внешнюю ( и ]]» ),
  2. Узнайте PID подоболочки. ( $$ предоставит вам PID основной оболочки.)
  3. Отсоедините подоболочку, которая завершает ваш процесс после тайм-аута, и
  4. Выполните команду в процесс подоболочки, созданной на шаге 1.

  Будет запущена long-running-command , , но только в течение заранее определенного ограниченного времени.

• Это немного несерьезно, но, если вы решите, что хотите быть пользователем root (или другим пользователем) до конца сеанса входа в систему, вы можете exec su .

  На самом деле, я могу представить сценарий, в котором это действительно было бы полезно. Предположим, вы вошли в удаленную систему, и по какой-то причине возникла проблема с разрывом соединения и запуском нового соединения. Например, предположим, что в удаленной системе есть брандмауэр, работающий по расписанию. Вам разрешили подключиться, когда вы это сделали, и установленные подключения не закрываются, но в настоящее время новые подключения не принимаются.

  Вы сделали то, что хотели, и готовы выйти из системы. Ваш друг Боб находится с вами в комнате, , и он хочет поработать с удаленной системой - но он не сможет подключиться. Итак, вы набираете exec su - bob и, , когда появляется запрос пароля, передаете ему рабочую станцию. Теперь нет процесса с вашим UID (если вы не запускали что-то в фоновом режиме), поэтому Боб не сможет возиться с вашими файлами. Он фактически перехватит ваше соединение (с вашего согласия и сотрудничества).

  Примечания:

  • Конечно, это не сработает, если вам не разрешено запускать su .
  • Это будет зарегистрировано, так что вам, возможно, придется объяснить кому-нибудь свои мотивы. Поскольку вы обходите политику (расписание брандмауэра), у вас могут возникнуть проблемы.
  • Я не гарантирую, что это на 100% безопасно. Например, , который , вероятно, по-прежнему будет показывать ваше имя. Вполне возможно, что некоторая (плохо написанная) программа воспользуется этим, чтобы подумать, что Боб - это вы, и предоставить ему доступ к вашим ресурсам.
  • Если система выполняет аудит, действия Боба могут проверяться от вашего имени.