Jak mogę zabić proces i mieć pewność, że PID nie został ponownie użyty

Załóżmy na przykład, że masz skrypt powłoki podobny do:

longrunningthing &
p=$!
echo Killing longrunningthing on PID $p in 24 hours
sleep 86400
echo Time up!
kill $p

Powinien załatwić sprawę, prawda? Tyle że proces mógł zostać wcześniej zakończony, a jego PID mógł zostać poddany recyklingowi, co oznacza, że ​​niektóre niewinne prace dostają bombę w kolejce sygnałowej. W praktyce może to mieć znaczenie, ale martwi mnie to. Hakowanie długiego wybiegania, aby samemu upaść lub zachować / usunąć swój PID na FS, wystarczy, ale myślę o ogólnej sytuacji tutaj.

Najlepiej byłoby użyć timeoutpolecenia, jeśli je masz:

timeout 86400 cmd

Obecna implementacja GNU (8.23) działa przynajmniej przy użyciu alarm()lub równoważnej podczas oczekiwania na proces potomny. Wydaje się, że nie chroni przed SIGALRMdostarczeniem pomiędzy waitpid()powrotem a timeoutwyjściem (skuteczne anulowanie tego alarmu ). Podczas tego małego okna timeoutmoże nawet pisać wiadomości na stderr (na przykład, jeśli dziecko zrzuci rdzeń), co jeszcze bardziej powiększy to okno wyścigu (na czas nieokreślony, jeśli stderr jest na przykład pełną potokiem).

Osobiście mogę żyć z tym ograniczeniem (które prawdopodobnie zostanie naprawione w przyszłej wersji). timeoutdołoży także starań, aby zgłosić poprawny status wyjścia, obsługiwać inne przypadki narożne (takie jak SIGALRM zablokowane / ignorowane przy uruchamianiu, obsługiwać inne sygnały ...) lepiej niż prawdopodobnie robiłbyś to ręcznie.

Dla przybliżenia możesz napisać w następujący sposób perl:

perl -MPOSIX -e '
  $p = fork();
  die "fork: $!\n" unless defined($p);
  if ($p) {
    $SIG{ALRM} = sub {
      kill "TERM", $p;
      exit 124;
    };
    alarm(86400);
    wait;
    exit (WIFSIGNALED($?) ? WTERMSIG($?)+128 : WEXITSTATUS($?))
  } else {exec @ARGV}' cmd

Na stronie http://devel.ringlet.net/sysutils/timelimit/ znajduje się timelimitpolecenie (poprzedza GNU o kilka miesięcy).timeout

 timelimit -t 86400 cmd

Ten używa alarm()podobnego mechanizmu, ale instaluje moduł obsługi SIGCHLD(ignorując zatrzymane dzieci) w celu wykrycia śmierci dziecka. Anuluje również alarm przed uruchomieniem waitpid()(nie anuluje dostarczenia, SIGALRMjeśli był w toku, ale sposób, w jaki jest napisany, nie widzę problemu) i zabija przed wywołaniem waitpid()(więc nie mogę zabić ponownie wykorzystanego pid ).

netpipes ma również timelimitpolecenie. To, że wyprzedza wszystkie pozostałe o dziesięciolecia, przyjmuje jeszcze inne podejście, ale nie działa poprawnie dla zatrzymanych poleceń i zwraca 1status wyjścia po upływie limitu czasu.

Jako bardziej bezpośrednią odpowiedź na twoje pytanie możesz zrobić coś takiego:

if [ "$(ps -o ppid= -p "$p")" -eq "$$" ]; then
  kill "$p"
fi

To znaczy, sprawdź, czy proces jest nadal naszym dzieckiem. Znów jest małe okno wyścigu (pomiędzy psodzyskaniem statusu tego procesu a killzabiciem go), podczas którego proces może umrzeć, a jego pid może zostać ponownie wykorzystany przez inny proces.

Z niektórych muszli ( zsh, bash, mksh), można przekazać widowisko pracy zamiast PID.

cmd &
sleep 86400
kill %
wait "$!" # to retrieve the exit status

Działa to tylko wtedy, gdy spawnujesz tylko jedno zadanie w tle (w przeciwnym razie uzyskanie właściwego rodzaju zadania nie zawsze będzie możliwe w sposób niezawodny).

Jeśli to jest problem, po prostu uruchom nową instancję powłoki:

bash -c '"$@" & sleep 86400; kill %; wait "$!"' sh cmd

Działa to, ponieważ powłoka usuwa zadanie ze stołu zadań po śmierci dziecka. Tutaj nie powinno być żadnego okna wyścigu, ponieważ do czasu wywołania powłoki kill()albo sygnał SIGCHLD nie został obsłużony, a pid nie mógł zostać ponownie użyty (ponieważ nie był oczekiwany), lub został obsłużony, a zadanie zostało usunięte z tabeli procesów (i killzgłosiłoby błąd). bash„s killco najmniej bloków SIGCHLD zanim dostęp swoją tabelę pracy, aby rozwinąć %i odblokowuje to po kill().

Innym rozwiązaniem, aby uniknąć tego sleepprocesu wiszące wokół nawet po cmdumarł, z bashlub ksh93jest użycie rurę read -tzamiast sleep:

{
  {
    cmd 4>&1 >&3 3>&- &
    printf '%d\n.' "$!"
  } | {
    read p
    read -t 86400 || kill "$p"
  }
} 3>&1

Ten nadal ma warunki wyścigu i tracisz status wyjścia z polecenia. Zakłada również, cmdże nie zamyka swojego fd 4.

Możesz spróbować wdrożyć rozwiązanie bez wyścigu w perl:

perl -MPOSIX -e '
   $p = fork();
   die "fork: $!\n" unless defined($p);
   if ($p) {
     $SIG{CHLD} = sub {
       $ss = POSIX::SigSet->new(SIGALRM); $oss = POSIX::SigSet->new;
       sigprocmask(SIG_BLOCK, $ss, $oss);
       waitpid($p,WNOHANG);
       exit (WIFSIGNALED($?) ? WTERMSIG($?)+128 : WEXITSTATUS($?))
           unless $? == -1;
       sigprocmask(SIG_UNBLOCK, $oss);
     };
     $SIG{ALRM} = sub {
       kill "TERM", $p;
       exit 124;
     };
     alarm(86400);
     pause while 1;
   } else {exec @ARGV}' cmd args...

(choć należałoby go ulepszyć, aby obsługiwał inne typy skrzynek narożnych).

Inną bez rasową metodą może być użycie grup procesów:

set -m
((sleep 86400; kill 0) & exec cmd)

Należy jednak pamiętać, że korzystanie z grup procesów może mieć skutki uboczne, jeśli zaangażowane jest we / wy do urządzenia końcowego. Ma jednak tę dodatkową zaletę, że zabija wszystkie inne dodatkowe procesy odradzane przez cmd.

Ogólnie nie możesz. Wszystkie dotychczasowe odpowiedzi to błędna heurystyka. Jest tylko jeden przypadek, w którym możesz bezpiecznie używać pid do wysyłania sygnałów: gdy proces docelowy jest bezpośrednim potomkiem procesu, który będzie wysyłał sygnał, a rodzic jeszcze na niego nie czekał. W takim przypadku, nawet jeśli wyszedł, pid jest zarezerwowany (tak właśnie jest „procesem zombie”), dopóki rodzic na niego nie poczeka. Nie znam żadnego sposobu, aby zrobić to czysto za pomocą powłoki.

Alternatywnym bezpiecznym sposobem na zabicie procesów jest uruchomienie ich ze sterującym zestawem tty na pseudo-terminalu, dla którego jesteś właścicielem strony głównej. Następnie możesz wysyłać sygnały przez terminal, np. Zapisując znak za SIGTERMlub SIGQUITponad pty.

Jeszcze innym sposobem, który jest wygodniejszy w skryptowaniu, jest użycie nazwanej screensesji i wysłanie poleceń do sesji ekranowej, aby ją zakończyć. Proces ten odbywa się za pomocą potoku lub gniazda unix o nazwie zgodnej z sesją ekranową, która nie zostanie automatycznie ponownie użyta, jeśli wybierzesz bezpieczną unikalną nazwę.

1. Podczas uruchamiania procesu oszczędzaj jego czas rozpoczęcia:

   longrunningthing &
   p=$!
   stime=$(TZ=UTC0 ps -p "$p" -o lstart=)
   
   echo "Killing longrunningthing on PID $p in 24 hours"
   sleep 86400
   echo Time up!
   

2. Zanim spróbujesz zabić proces, zatrzymaj go (nie jest to naprawdę konieczne, ale jest to sposób na uniknięcie warunków wyścigu: jeśli zatrzymasz proces, nie będzie można go ponownie wykorzystać)

   kill -s STOP "$p"
   

3. Sprawdź, czy proces z tym PID ma ten sam czas rozpoczęcia, a jeśli tak, zabij go, w przeciwnym razie pozwól procesowi kontynuować:

   cur=$(TZ=UTC0 ps -p "$p" -o lstart=)
   
   if [ "$cur" = "$stime" ]
   then
       # Okay, we can kill that process
       kill "$p"
   else
       # PID was reused. Better unblock the process!
       echo "long running task already completed!"
       kill -s CONT "$p"
   fi
   

Działa to, ponieważ w danym systemie operacyjnym może istnieć tylko jeden proces z tym samym PID i czasem rozpoczęcia.

Zatrzymanie procesu podczas kontroli sprawia, że ​​warunki wyścigu nie stanowią problemu. Oczywiście ma to problem polegający na tym, że niektóre losowe procesy mogą zostać zatrzymane na kilka milisekund. W zależności od rodzaju procesu może to stanowić problem.

Osobiście po prostu użyłbym Pythona i psutilktóry automatycznie obsługuje ponowne użycie PID:

import time

import psutil

# note: it would be better if you were able to avoid using
#       shell=True here.
proc = psutil.Process('longrunningtask', shell=True)
time.sleep(86400)

# PID reuse handled by the library, no need to worry.
proc.terminate()   # or: proc.kill()

W systemie Linux możesz mieć pewność, że pid nie zostanie ponownie użyty, utrzymując przestrzeń nazw pid przy życiu. Można to zrobić za pomocą /proc/$pid/ns/pidpliku.

• man namespaces -

  Powiązanie montowania (patrz mount(2)) jednego z plików w tym katalogu z innym miejscem w systemie plików utrzymuje odpowiednią przestrzeń nazw procesu określonego przez pid, nawet jeśli wszystkie procesy aktualnie znajdujące się w przestrzeni nazw zakończą się.

  Otwarcie jednego z plików w tym katalogu (lub pliku podłączonego do jednego z tych plików) zwraca uchwyt pliku dla odpowiedniej przestrzeni nazw procesu określonego przez pid. Dopóki ten deskryptor pliku pozostanie otwarty, przestrzeń nazw pozostanie aktywna, nawet jeśli wszystkie procesy w przestrzeni nazw zostaną zakończone. Deskryptor pliku można przekazać setns(2).

• man pid_namespaces -

  Pierwszy proces stworzony w nowej przestrzeni nazw (czyli proces tworzony przy użyciu clone(2) z CLONE_NEWPID flagi, lub pierwszego dziecka stworzonej przez proces po wywołaniu unshare(2)za pomocą CLONE_NEWPID flagę) ma na PID 1 i jest initproces przestrzeni nazw ( patrz init(1)) . Proces potomny, który jest osierocony w przestrzeni nazw, zostanie ponownie powiązany z tym procesem init(1) (chyba że jeden z przodków dziecka w tej samej przestrzeni nazw PID prctl(2) użył polecenia PR_SET_CHILD_SUBREAPER, aby oznaczyć siebie jako żniwiarza osieroconych procesów potomnych) .

  Jeśli initproces przestrzeni nazw PID zakończy się, jądro kończy wszystkie procesy w przestrzeni nazw sygnałem SIGKILL . To zachowanie odzwierciedla fakt, że initproces jest niezbędny do poprawnego działania przestrzeni nazw PID .

unshare -fp sh -c 'n=
    echo "PID = $$"
    until   [ "$((n+=1))" -gt 5 ]
    do      while   sleep 1
            do      date
            done    >>log 2>/dev/null   &
    done;   sleep 5' >log
cat log; sleep 2
echo 2 secs later...
tail -n1 log

Jeśli nie ustawiłeś przestrzeni nazw użytkownika, możesz nadal bezpiecznie wykonywać dowolne polecenia, natychmiast porzucając uprawnienia. runuserPolecenia jest inny (nie setuid) binarny dostarczane przez util-linuxpakiet i wprowadzenie może wyglądać następująco:

sudo unshare -fp runuser -u "$USER" -- sh -c '...'

...i tak dalej.

W powyższym przykładzie dwa przełączniki są przekazywane do unshare(1)tej --forkflagi, która sprawia, że wywołany sh -cproces pierwsze dziecko utworzony i zapewnia jego initstan, a --pidflaga, która nakazuje unshare(1), aby stworzyć przestrzeń nazw PID.

Proces sh -cten tworzy pięć potomnych powłok w tle - każdą nieskończoną whilepętlę, która będzie dołączała dane wyjściowe datedo końca logtak długo, jak długo sleep 1zwraca wartość true. Po spawnowaniu procesy te shwymagają sleepdodatkowych 5 sekund, a następnie kończą się.

Warto zauważyć, że gdyby -fflaga nie była używana, żadna z whilepętli w tle nie zakończyłaby się, ale wraz z nią ...

WYDAJNOŚĆ:

PID = 1
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:48 PST 2015
Mon Jan 26 19:17:48 PST 2015
Mon Jan 26 19:17:48 PST 2015
Mon Jan 26 19:17:48 PST 2015
Mon Jan 26 19:17:48 PST 2015
2 secs later...
Mon Jan 26 19:17:48 PST 2015

Zastanów się nad tym, aby longrunningthingzachować się nieco lepiej, bardziej przypominając demona. Na przykład możesz zmusić go do utworzenia pliku pid , który pozwoli przynajmniej na ograniczoną kontrolę procesu. Istnieje kilka sposobów na zrobienie tego bez modyfikowania oryginalnego pliku binarnego, z których wszystkie obejmują opakowanie. Na przykład:

1. prosty skrypt otoki, który uruchomi wymagane zadanie w tle (z opcjonalnym przekierowaniem wyjścia), zapisz PID tego procesu do pliku, a następnie poczekaj, aż proces się zakończy (za pomocą wait) i usunie plik. Jeśli podczas oczekiwania proces zostanie zabity np. Przez coś takiego

   kill $(cat pidfile)
   

   opakowanie upewni się, że plik pid został usunięty.

2. opakowanie monitora, które umieści gdzieś swój własny PID i przechwytuje (i reaguje na) wysyłane do niego sygnały. Prosty przykład:

    #!/bin/bash
    p=0
    trap killit USR1

    killit () {
        printf "USR1 caught, killing %s\n" "$p"
        kill -9 $p
    }

    printf "monitor $$ is waiting\n"
    therealstuff &
    p=%1
    wait $p
    printf "monitor exiting\n"

Teraz, jak zauważyli @R .. i @ StéphaneChazelas, podejścia te często mają gdzieś warunek wyścigu lub nakładają ograniczenia na liczbę procesów, które możesz spawnować. Ponadto nie obsługuje przypadków, w których longrunningthingmoże rozwidlać się, a dzieci zostają odłączone (co prawdopodobnie nie stanowiło problemu w pierwotnym pytaniu).

W przypadku najnowszych (przeczytanych kilka lat) jąder Linuksa można to ładnie potraktować za pomocą cgroups , a mianowicie zamrażarki - co, jak sądzę, jest tym, czego używają niektóre nowoczesne systemy inicjujące Linuksa.

Jeśli używasz Linuksa (i kilku innych * nixów), możesz sprawdzić, czy proces, który chcesz zabić, jest nadal używany i czy wiersz poleceń pasuje do twojego długiego procesu. Coś jak :

echo Time up!
grep -q longrunningthing /proc/$p/cmdline 2>/dev/null
if [ $? -eq 0 ]
then
  kill $p
fi

Alternatywą może być sprawdzenie, jak długo trwa proces, który chcesz zabić, za pomocą czegoś takiego ps -p $p -o etime=. Możesz to zrobić samodzielnie, wyodrębniając te informacje /proc/$p/stat, ale byłoby to trudne (czas mierzony jest w jiffies i będziesz musiał również wykorzystać czas pracy systemu /proc/stat).

W każdym razie zazwyczaj nie możesz upewnić się, że proces nie zostanie zastąpiony po sprawdzeniu i przed jego zabiciem.

To właściwie bardzo dobre pytanie.

Sposobem ustalenia wyjątkowości procesu jest przyjrzenie się (a) miejscu w pamięci; oraz (b) co zawiera ta pamięć. Mówiąc konkretnie, chcemy wiedzieć, gdzie w pamięci znajduje się tekst programu do pierwszego wywołania, ponieważ wiemy, że obszar tekstowy każdego wątku zajmie inną lokalizację w pamięci. Jeśli proces umrze, a inny zostanie uruchomiony z tym samym pid, tekst programu nowego procesu nie zajmie tego samego miejsca w pamięci i nie będzie zawierał tych samych informacji.

Więc natychmiast po uruchomieniu procesu wykonaj md5sum /proc/[pid]/mapsi zapisz wynik. Później, gdy chcesz zabić proces, zrób kolejny md5sum i porównaj go. Jeśli pasuje, zabij pid. Jeśli nie, nie rób tego.

aby się przekonać, uruchom dwie identyczne powłoki bash. Sprawdź /proc/[pid]/mapsje, a przekonasz się, że są różne. Czemu? Ponieważ mimo że jest to ten sam program, zajmują one różne miejsca w pamięci, a adresy ich stosów są różne. Tak więc, jeśli twój proces umrze, a jego PID zostanie ponownie użyty, nawet po ponownym uruchomieniu tego samego polecenia z tymi samymi argumentami , plik „map” będzie inny i będziesz wiedział, że nie masz do czynienia z pierwotnym procesem.

Szczegółowe informacje można znaleźć na stronie proc proc .

Zauważ, że plik /proc/[pid]/statzawiera już wszystkie informacje, o których wspominał inny plakat: wiek procesu, pid nadrzędny itp. Plik ten zawiera zarówno informacje statyczne, jak i dynamiczne, więc jeśli wolisz używać tego pliku jako podstawy porównania, a następnie po uruchomieniu longrunningthingnależy wyodrębnić z statpliku następujące pola statyczne i zapisać je do porównania później:

pid, nazwa pliku, pid rodzica, identyfikator grupy procesów, terminal sterujący, proces czasu rozpoczęty po uruchomieniu systemu, rozmiar zestawu rezydenta, adres początku stosu,

wzięte razem, powyższe jednoznacznie identyfikują proces, a zatem stanowi to inną drogę. W rzeczywistości można uciec z niczym więcej niż „pid” i „proces czasu rozpoczęty po uruchomieniu systemu” z wysokim poziomem pewności. Po prostu wyodrębnij te pola z statpliku i zapisz je gdzieś po uruchomieniu procesu. Później przed zabiciem wyodrębnij go ponownie i porównaj. Jeśli się zgadzają, masz pewność, że patrzysz na oryginalny proces.

Innym sposobem byłoby sprawdzenie wieku procesu przed jego zabiciem. W ten sposób możesz upewnić się, że nie zabijasz procesu, który nie pojawi się w ciągu mniej niż 24 godzin. Możesz dodać ifwarunek na tej podstawie przed zabiciem procesu.

if [[ $(ps -p $p -o etime=) =~ 1-. ]] ; then
    kill $p
fi

Ten ifwarunek sprawdzi, czy identyfikator procesu $pjest krótszy niż 24 godziny (86400 sekund).

PS: - Polecenie ps -p $p -o etime=będzie miało format<no.of days>-HH:MM:SS

Po zabiciu tego procesu robię to jeszcze raz. Za każdym razem, gdy to robię, odpowiedź powraca: „nie ma takiego procesu”

allenb   12084  5473  0 08:12 pts/4    00:00:00 man man
allenb@allenb-P7812 ~ $ kill -9 12084
allenb@allenb-P7812 ~ $ kill -9 12084
bash: kill: (12084) - No such process
allenb@allenb-P7812 ~ $ 

Nie może być prościej i robię to od lat bez żadnych problemów.