Kernel pánik

Kernel pánik (  angolul  -  "riasztás, hiba a kernelben", szó szerint kernel pánik ) - üzenet az operációs rendszer kernelének kritikus hibájáról , amely után az operációs rendszer nem tudja folytatni a további munkát [1] .

A kifejezést általában olyan operációs rendszer környezetben használják, mint például a UNIX . Kernel panic: …Neve a " " formátumú hibaszöveghez és a kernelfüggvény nevéhez kapcsolódik panic()az eredeti UNIX operációs rendszerből [2] .

Kernelpánik lehetséges a Linux kernelen alapuló Androidon . Mivel a Mac OS X és iOS a Darwin - on alapul , amely a UNIX rendszerek egy osztálya, ezért ezek is ki vannak téve a kernelpániknak. [3] .

Történelem

A Kernel pánik története szorosan összefügg a UNIX operációs rendszerével , amelyet az 1960 -as évek végén fejlesztettek ki a Bell Labs alkalmazottai , nevezetesen Ken Thompson , Dennis Ritchie és Douglas McIlroy .

A kernel pániküzenetet a UNIX korai verzióiban vezették be, és az operációs rendszer filozófiájában fontos különbséget jelentett a UNIX fő versenytársától és elődjétől, a Multicstól . A Multicsot a 36 bites GE-645 nagyszámítógépen való futtatásra tervezték, míg a UNIX-ot a sokkal kisebb teljesítményű, 18 bites PDP-7 miniszámítógépen való futtatásra tervezték, és emiatt kevesebb erőforrás állt az operációs rendszer rendelkezésére, ami az erőforrások megtakarításának szükségessége miatt, beleértve a hibakezelést is. A Multics fejlesztője, Tom van Vleck leírja ezt a változást a UNIX fejlesztővel, Dennis Ritchie-vel folytatott megbeszélésen [4] :

Mondtam Dennisnek, hogy a Multicshoz írt kódnak körülbelül a fele hibakezelő kód. Azt válaszolta: „Eldobtuk az egészet. Ha hiba történik, van egy pánik nevű eljárásunk , és ha ezt lehívják, a számítógép lefagy, és Ön azt kiáltja: „Hé, indítsd újra!”.

Eredeti szöveg  (angol)[ showelrejt] Megjegyeztem Dennisnek, hogy a Multics-ban írt kód fele könnyen hibahelyreállító kód volt. Azt mondta: „Ezt az egészet kihagytuk. Ha hiba történik, van egy pánik nevű rutinunk, és amikor hívják, a gép összeomlik, és a folyosón kiabálsz: "Hé, indítsd újra."

Az eredeti funkció panic()alapvetően nem változott UNIX V5-ről VAX alapú 32V -os rendszerekre, és csak egy hibaüzenetet nyomtatott ki további információk nélkül, ami után a rendszer egy végtelen üres hurokba kerül . Később, a UNIX fejlesztése során a funkció panic()véglegesítésre került, és elkezdte megjeleníteni a terminálon a hibakereséshez szükséges információkat .

A kritikus hibakezelésnek ezt az elvét a legtöbb későbbi operációs rendszer átvette, mint például a Mac OS [3] vagy a Microsoft Windows [5] .

A kernelpánik okai

A kernelpánik egyik leggyakoribb oka a gyökérfájlrendszer megtalálásának és csatlakoztatásának képtelensége. Ez gyakran konfigurációs hiba, amelyet a kernel manuális újraindításával lehet kijavítani [6] .

Linuxon a kernelpánik előfordulását gyakran megelőzi az hoppá nevű állapot . Egyes esetekben az hoppá a rendszer ugyanolyan egészségtelen állapotához vezethet, mint a kernelpánik [1] .

A legtöbb esetben a kernelpánik oka egy kritikus hardverhiba ( RAM hiba , processzorhiba , alaplap, grafikus kártya vagy más kritikus eszköz) vagy magában az operációs rendszer kernelében lévő hiba , például egy hibás vagy tiltott cím a memóriában. A kernelpánik további okai lehetnek a periféria - illesztőprogramok vagy a fájlrendszer hibái [3] [7] . A felhasználói terület inicializálásának utolsó szakaszában általában kernelpánik lép fel, amikor az init nem fut , mert a futó és futó kernel ellenére maga a rendszer használhatatlan marad [8] . A kernelpánikot alkalmazási programok is okozhatják, ha nem működnek megfelelően a kernellel. Például a Google Chrome hibája kernelpánikot okozott Mac OS X rendszeren [9] .

Panic() forráskód

UNIX V6 [10] panic() forráskód :

char * panicstr ; /* * A pánikot feloldhatatlan * végzetes hibákra hívják . * Szinkronizál, kiírja a "panic: mesg"-et és *-ot, majd hurkot. */ pánik ( ok ) char * s ; { panicstr = s ; frissítés (); printf ( "pánik:%s \n " , s ); mert (;;) tétlen (); }

Kernel pánik kezelése

Normál esetben, amikor kernel pánik lép fel, az operációs rendszer leáll , és hibaüzenetek jelennek meg a képernyőn, ami után a rendszer megvárja, hogy a számítógép leálljon vagy újrainduljon . Ennek az eseménynek az ilyen feldolgozása azonban elfogadhatatlan, ha egy egyszerű számítógép nagyon nem kívánatos, vagy ha valaki nincs a közelben (például távoli szervereken vagy munkaidőn túl) [11] .

A modern operációs rendszereken, mint például a GNU/Linux , a FreeBSD vagy a Solaris , lehetőség van a panic() függvény alapértelmezett viselkedésének megváltoztatására és a számítógép automatikus újraindítására. GNU/Linux esetén ez a konfiguráció procfs [11] használatával történik :

echo 5 > /proc/sys/kernel/panic

Ahhoz, hogy a változtatások érvénybe lépjenek a GNU/Linux rendszerben az újraindítás után, hozzá kell adni egy sort a fájlhoz /etc/sysctl.d/99-sysctl.conf:

kernel.panic = 5

A kernel.panic paraméter értéke az a másodperc, amely után az újraindítás megtörténik. Ha ezt a paramétert negatívra vagy 0-ra állítja, az nem indul automatikusan újra [11] .

BSD rendszereken is van egy speciális opció a kernelben. /usr/src/sys/conf/NOTESIdézet a [12] fájlból :

# Állítsa be azt az időt (másodpercben), ameddig a rendszer # automatikusan újraindul, ha kernelpánik lép fel. Ha (-1), # a rendszer korlátlan ideig vár, amíg meg nem nyomnak egy gombot a # konzolon. opciók PANIC_REBOOT_WAIT_TIME = 16

A Solaris rendszerben a rendszermag-pánik utáni automatikus újraindítás a szokásos rendszerviselkedés [13] .

A kernel pánik utáni újraindításnak is van egy nagyon komoly hátránya, különösen, ha a változás nem szűnik meg az első újraindítás után . Abban az esetben, ha az újraindítás nem javítja ki a Kernel pánikot okozó hibát, a rendszer újra és újra leáll és újraindul, ami hardverhibákhoz vagy adatvesztéshez vezethet [6] . Abban az esetben, ha ez a helyzet egy új kernel felépítése után állna elő, a probléma megoldása a régi, működő kernel mentett másolatának betöltése lehet. Általános szabály, hogy ehhez elegendő manuálisan megadni a kernel munkapéldányának elérési útját a rendszerindítás során [14] .

A System.map [15] fájl hasznos lehet a Linux kernelpánik okának kivizsgálásához .

Kernelpánik különböző operációs rendszereken

Kezdetben a Kernel pánik üzenete egy rövid szövegre korlátozódott a rendszer újraindításának szükségességéről. A modern rendszerekben általában több kiegészítő információt adnak meg.

  • A GNU/Linux és a legtöbb UNIX - kompatibilis operációs rendszer létrehoz egy naplót, amely leírja a hibát, és egy hibaüzenetet jelenít meg a képernyőn, amely tartalmazza a hibakereséshez és a hiba okának megtalálásához szükséges információkat. Ezt a mechanizmust Linux hoppá . A modern Linux disztribúciók az X Window grafikus kiszolgálót használják , és a kernelpánik nem okoz váltást a diagnosztikai üzeneteket kinyomtató fizikai konzolra. Felismerheti a kernel pánikot a Caps Lock és a Scroll Lock LED-ek villogásáról a billentyűzeten [16] .
  • A Mac OS X eredeti verzióiban (10.0-tól 10.0.1.5-ig) a Linux kernelen alapuló operációs rendszerekkel analóg módon a képernyőn megjelentek a hibaüzenetek, ami után a rendszer leállt. A Mac OS X 10.2-től kezdődően ez az üzenet leegyszerűsödött, és csak négy nyelven (angol, német, francia és japán) jelzi a számítógép újraindítását, függetlenül az operációs rendszer nyelvi verziójától [3] [17] . Az OS X azonban lehetővé teszi [17] számára, hogy lecserélje a képet bármilyen másra, ami lehetővé teszi a fejlesztők számára, hogy különféle helyzetekben módosítsa a hibaüzeneteket [17] . Ennek a funkciónak köszönhetően az OS X-en akár a Windows operációs rendszer Blue Screen of Death -jét is szimulálhatjuk úgy, hogy a szabványos képet lecseréljük a megfelelő Windows -kép képernyőképére [17] .

Nem UNIX operációs rendszereken

Míg a kernelpánik kifejezést főként UNIX - kompatibilis operációs rendszerekre használják, más operációs rendszerekben a kritikus hibák rendszerleállítással történő kezelése is meghonosodott, és a következő neveket kapta:

Lásd még

Jegyzetek

  1. 1 2 Kirkland, Tinker, 2006 , p. 51.
  2. Pánik() információ a UNIX.com oldalon . BSD kézikönyv a UNIX és Linux fórumokon (1995. augusztus 11.). Letöltve: 2012. július 24. Az eredetiből archiválva : 2012. augusztus 6..
  3. 1 2 3 4 A kernelpánik okai Mac OS X rendszerben. macmaps.com. Letöltve: 2012. július 24. Az eredetiből archiválva : 2012. augusztus 6..
  4. Unix és Multics . www.multicians.org (93/03/21). Letöltve: 2012. július 24. Az eredetiből archiválva : 2012. augusztus 6..
  5. 1 2 3 Információk a Windows rendellenes helyzetekben való viselkedéséről . Microsoft Corp. Letöltve: 2012. július 24. Az eredetiből archiválva : 2012. augusztus 6..
  6. 1 2 Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, Philippe Gerum, 2008 , p. 170.
  7. Információ a kernelpánik okairól az Apple webhelyén . Apple Inc. Letöltve : 2012. július 24. Az eredetiből archiválva : 2012. augusztus 6..
  8. Wolfgang Mauerer. Professzionális Linux Kernel Architecture  (neopr.) . - John Wiley and Sons , 2008. - S. 1238-1239. — ISBN 978-0-470-34343-2 .
  9. A Google tiszta: Igen, a kernelpánik a Chrome hibája . Betanews (2012. január 7.). Letöltve: 2012. július 24. Az eredetiből archiválva : 2012. augusztus 6..
  10. Forráskód prf.c UNIX V6 . Unix fa. Letöltve: 2012. július 24. Az eredetiből archiválva : 2012. augusztus 6..
  11. 1 2 3 Kopper, 2005 , p. 178.
  12. OpenBSD SYSCTL.CONF kézikönyvoldal . OpenBSD. Letöltve: 2012. július 24. Az eredetiből archiválva : 2012. augusztus 6..
  13. Solaris System Engineers, 2009 , p. 9.3.4.2.
  14. Michael Urban, Brian Tiemann, 2002 , p. 172.
  15. Michael Schwarz, 2002 , p. 21.
  16. Kirkland, Tinker, 2006 , p. 52.
  17. 1 2 3 4 A halál új képernyője Mac OS X rendszerhez. Amit Singh. Letöltve: 2012. július 30. Az eredetiből archiválva : 2012. augusztus 6..
  18. Ted Landau, 2000 , p. 133.
  19. Ted Landau, 2000 , p. 83.
  20. 1 2 Eric S. Raymond, 1996 , p. 230.

Irodalom

  • Karl Kopper. A Linux Enterprise Cluster: Hozzon létre egy magasan elérhető fürtöt. - No Starch Press, 2005. - P. 430. - ISBN 1593270364 .
  • Michael Urban, Brian Tiemann. Sams Tanítsd meg magad a FreeBSD-re 24 órán belül. - Sams Publishing, 2002. - P. 456. - ISBN 0672324245 .
  • James Kirkland, Christopher L. Tinker. Linux-hibaelhárítás rendszergazdák és magas szintű felhasználók számára. - Prentice Hall Professional, 2006. - P. 571. - ISBN 0-13-185515-8 .
  • Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, Philippe Gerum. Beágyazott Linux rendszerek építése. - O'Reilly Media, 2008. - P. 439. - ISBN 0596529686 .
  • Solaris rendszermérnökök. A Solaris 10 rendszeradminisztráció alapjai. - Pearson Education, 2009. - P. 456. - ISBN 013700009X .
  • Michael Schwarz. Multitool Linux: Nyílt forráskódú szoftverek gyakorlati felhasználásai. - Addison-Wesley Professional, 2002. - P. 532. - ISBN 0201734206 .
  • Ted Landau. Szomorú Mac-ek, bombák és egyéb katasztrófák: és mit tegyünk ellenük ? - Peachpit Press, 2000. - S.  955 . — ISBN 020169963X .
  • Eric S. Raymond. Az új hacker szótára. - MIT Press, 1996. - P. 547. - ISBN 0262680920 .

Linkek