Przykład użycia / praktyczny przykład dla wbudowanego exec Bash

Rozważ to z dokumentacji wbudowanego exec Bash:

exec zastępuje powłokę bez tworzenia nowego procesu

Podaj przypadek użycia / praktyczny przykład. Nie rozumiem, jak to ma sens.

Poszukałem go i znalazłem informacje o przekierowaniu we / wy . Czy możesz to lepiej wyjaśnić?

execjest często używany w skryptach powłoki, które działają głównie jako opakowania dla uruchamiania innych plików binarnych. Na przykład:

#!/bin/sh

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

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

tak, że po zakończeniu działania opakowania, „prawdziwy” plik binarny przejmuje kontrolę i nie ma już śladu skryptu opakowania, który tymczasowo zajmował to samo miejsce w tabeli procesów. „Prawdziwy” plik binarny jest bezpośrednim dzieckiem tego, co go uruchomiło, a nie wnukiem.

W swoim pytaniu wspominasz również o przekierowaniu wejścia / wyjścia. Jest to zupełnie inny przypadek użycia execi nie ma nic wspólnego z zastąpieniem powłoki innym procesem. Kiedy execnie ma argumentów, tak:

exec 3>>/tmp/logfile

następnie przekierowania we / wy w wierszu poleceń obowiązują w bieżącym procesie powłoki, ale bieżący proces powłoki nadal działa i przechodzi do następnego polecenia w skrypcie.

Użyłem execwbudowanej powłoki, aby uzyskać identyfikator procesu (PID) dla programu Java. Może istnieć sposób na uzyskanie PID z poziomu Javy, ale kilka lat temu nie było. Gdy proces ma swój własny PID, może zapisać go do pliku PID (poszukaj /var/run/nazw plików z sufiksem „.pid”), aby umożliwić programom zarządzającym rozpoznanie PID uruchomionego procesu i zapobiec drugiej instancji z tego samego serwera przed uruchomieniem. Działa to mniej więcej tak:

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

Kod w main()metodzie klasy StartClassobsługuje parsowanie argumentów i może znaleźć własny identyfikator procesu.

Dla zabawy uruchom następujący program (przetłumaczony na wybrany język implementacji) w tle w systemie z rozliczaniem procesów użytkownika i limitami.

while(true) fork();

Teraz, gdy każde miejsce w tabeli procesów, którego możesz używać, jest pełne kopii tego uruchomionego programu, jak zamierzasz go zabić? Uruchomienie kill (1) wymaga innego gniazda procesu, którego nie możesz mieć. Przydałoby się zastąpienie powłoki przez polecenie zabicia ...

exec /bin/kill -9 -1

(Zakłada się, że twój system ma kill (1) w / bin / kill. "Exec` which kill` -9 -1 "jest potencjalnie bezpieczniejszy.) Wysyła SIGKILL do każdego procesu, jaki możesz.

(Uwaga: nie wylogowuj się z uruchomionej powłoki, chyba że limity procesu zawsze pozwalają na nowe logowanie do gniazda procesu dla jej powłoki. Może to być nieco trudniejsze do wyczyszczenia, jeśli tak zrobisz. Z pewnością nie zrobiłem tego w wczesne lata 90. Nie.)

• Jest to podobne do przykładu Bruce'a, że ​​trzeba znać PID procesu:

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

  w którym ty

  1. Uruchom podpowłokę (zewnętrzną (i )),
  2. Znajdź PID podpowłoki. ( $$poda ci PID głównej powłoki).
  3. Odłącz podpowłokę, która zabija twój proces po upływie limitu czasu, i
  4. Uruchom polecenie w procesie podpowłoki utworzonej w kroku 1.

  Będzie to działało long-running-command, ale tylko przez z góry określony, ograniczony czas. 

• Jest to trochę niepoważne, ale jeśli zdecydujesz, że chcesz być rootem (lub innym użytkownikiem) do końca sesji logowania, możesz exec su.

  Właściwie mogę sobie wyobrazić scenariusz, w którym byłoby to naprawdę przydatne. Załóżmy, że jesteś zalogowany do systemu zdalnego i z jakiegoś powodu występuje problem z zerwaniem połączenia i nawiązaniem nowego połączenia. Załóżmy na przykład, że system zdalny ma zaporę ogniową zgodną z harmonogramem. Pozwolono ci się połączyć, kiedy to zrobiono, a ustanowione połączenia nie są zamykane, ale w tej chwili nowe połączenia nie są akceptowane.

  Zrobiłeś to, co chciałeś i jesteś gotowy do wylogowania. Twój przyjaciel Bob jest w pokoju z tobą i chce popracować nad systemem zdalnym - ale nie będzie mógł się połączyć. Więc piszesz exec su - bob, a kiedy pojawi się monit o hasło, oddaj mu stację roboczą. Nie ma teraz żadnego procesu z twoim identyfikatorem UID (chyba że uruchomiłeś coś w tle), więc Bob nie będzie mógł zadzierać z twoimi plikami. Skutecznie przejmie twoje połączenie (za twoją zgodą i współpracą).

  Uwagi:

  • Oczywiście to nie zadziała, jeśli nie wolno ci biegać su.
  • Zostanie zalogowany, więc być może będziesz musiał wyjaśnić komuś swoje motywy. Ponieważ obchodzisz zasady (harmonogram zapory), możesz wpaść w kłopoty.
  • Nie gwarantuję, że jest w 100% bezpieczny. Na przykład whoprawdopodobnie nadal pokaże twoje imię. Można sobie wyobrazić, że jakiś (źle napisany) program użyje tego, aby myśleć, że Bob jest tobą, i dać mu dostęp do twoich zasobów.
  • Jeśli system przeprowadza inspekcję, działania Boba mogą być kontrolowane pod Twoim nazwiskiem.