Mikor küld a rendszer SIGTERM-et egy folyamatnak?

A szerverprogramom SIGTERM-et kapott, és leállt (0-s kilépési kóddal). Ezen csodálkozom, mivel egészen biztos vagyok abban, hogy rengeteg memória volt rá. Milyen körülmények között küldi a linux (busybox) SIGTERM-et egy folyamathoz?

Megjegyzések

  • Tudok ' t gondoljon minden olyan esetre, amikor a kernel vagy egy szabványos eszköz a SIGTERM-et véletlenszerű folyamatba küldi. Mit tud mondani arról, hogy a program mit csinál, és hogyan indult '? Hogyan értesült a program ' program kilépési állapotáról? Meg tudja reprodukálni a problémát? Van naplója, amelyet ellenőrizhet?
  • Ez egy soros vonal olvasása és írása, és válaszol az UDP és TCP kérésekre. A végrehajtást egy bash szkriptre csomagoltam, és ezért tudom a kilépési kódot.
  • A Posix dokumentációja azt jelzi, hogy a SIGTERM szigorúan felhasználói szintű esemény. Lehetséges, hogy valaki más megölhette a szerver programját?
  • Te vagy az! A 0 visszatérési kód normál kijáratot jelent. Ha volt SIGTERM, akkor az $? értéke 143 (128 + jelszám).
  • ^ C is SIGINT, nem SIGTERM, és ez kilép 130-as kóddal.

Válasz

Ezt “válaszként közzé teszem” hogy van valamilyen megoldás, ha kiderül, hogy ez a probléma.

A 0 kilépési állapot a sikeres program normál kilépését jelenti. Egy kilépõ program bármely 0 és 255 közötti egész számot választhat kilépési állapotának. Hagyományosan a programok kis értékeket használnak. A héj a 126-os és annál magasabb értékeket használja a speciális feltételek jelentésére, ezért ezeket a legjobb elkerülni.

A C API-szinten a programok jelentést készítenek. 16 bites állapot¹ , amely a program kilépési állapotát és az azt megölő jelet is kódolja, ha van ilyen.

A shellben egy parancs kilépési állapota (az $? mappába mentve) összemossa a program tényleges kilépési állapotát és a jelértéket: ha egy programot egy jel megöl, div id = “efc34fc771″>

értéke nagyobb, mint 128 (a legtöbb kagyló esetén ez az érték 128 plusz a jel száma; az ATT ksh 256 + jelszámot, a yash pedig 384 + jelszámot használ, ami elkerüli a kétértelműség, de a többi héj nem követte a példáját).

Különösen, ha az $? értéke 0, akkor a program rendesen kilépett.

Ne feledje, hogy ez magában foglalja egy olyan folyamat esetét is, amely fogadja a SIGTERM-et, de rendelkezik jelkezelővel, és végül normálisan kilép (talán a SIGTERM jel közvetett következménye, talán nem).


A címben szereplő kérdés megválaszolásához a SIGTERM-et soha nem küldi automatikusan a rendszer. Van néhány olyan jel, amelyet automatikusan küldenek, mint a SIGHUP, amikor egy terminál megszűnik, SIGSEGV / SIGBUS / SIGILL, amikor egy folyamat olyan dolgokat végez, amelyeket nem kellene tennie, SIGPIPE, ha törött csőbe / foglalatba ír, stb. És vannak néhány jel, amelyet a terminál egy gombnyomása okoz, elsősorban a SIGINT a Ctrl + C számára, a SIGQUIT a Ctrl + \ és SIGTSTP a Ctrl + Z fájlhoz, de a SIGTERM nem tartozik ezek közé. Ha egy folyamat SIGTERM-et kap, akkor más folyamat küldte ezt a jelet.

¹ durván szólva

Megjegyzések

  • Szép magyarázat arról, hogyan lehet meghatározni a kilépés állapotát egy jel vételekor. Ez a válasz azonban nem ' t címzi az OP ' kérdést.
  • @codeforester válaszoltam a kérdésre test, nem a címben szereplő kérdés. Nos, a test egyik kérdése – tekintettel arra, hogy félreértésen alapult, kissé rendetlen. I ' hozzáadok néhány szót a többiről.
  • Ez a héjától függ. A ksh93-ban ' s 256 + signum, yash-ban ' s 384 + signum
  • Ne feledje, hogy 256 feletti érték használata a la ksh nem feltétlenül jobb, mivel ez megakadályozza annak átadását a exit címre. A yash megközelítés jó kompromisszum, de lásd még az rc-t. Lásd még: Alapértelmezett kilépési kód, amikor a folyamat leáll?

Válasz

A SIGTERM az a jel, amelyet általában a folyamat adminisztratív leállítására használnak.

Ez nem egy jel, amelyet a kern elküldene, hanem az a jel, amelyet egy folyamat általában küldjön egy másik folyamat befejezésére (kecsesen).

Ez az a jel, amelyet alapértelmezés szerint a kill, pkill, killall … parancsokat.

Ez az a jel, amelyet a démonoknak küldenek, hogy megállítsák őket (például egy service some-service stop esetén), vagy a init leállítás előtt (utána következik a SIGKILL azoknál a folyamatoknál, amelyeknek a SIGTERM után nem sikerült időben befejeződnie).

Vegye figyelembe, hogy a SIGTERM nem az a jel, amelyre ^C. A ^C címre küldött jel SIGINT.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük