A már futó segédről szóló üzenetet életciklus-nyomnak tekintse, ne annak engedélyének, hogy elkezdjen folyamatokat ölni. A veszélyes lépés nem maga a leállítás, hanem az előtte álló azonosítás, mert egy Macen több hasonló nevű összetevő is létezhet, és csak az egyikük birtokolja a kapcsolatot. Először építse fel az identitásrekordot. Utána döntse el, hogy a leállítás egyáltalán a helyes művelet-e.

Építsen identitásrekordot, mielőtt cselekszik

Négy tény teszi azonosíthatóvá a folyamatot: az aktuális PID a kezdési időpontjával, a végrehajtható fájl és a termék, amelyhez tartozik, a felhasználói vagy jogosultsági környezet, amelyben fut, és mindaz, ami elindította. ps -o pid,ppid,user,etime,command -p 1234 az első hármat egy sorban adja, beleértve azt is, milyen régóta él a folyamat. Az Activity Monitor ugyanezt az információt barátságosabb arccal mutatja. Adja hozzá a vezérlőt, vagyis azt az alkalmazást vagy szolgáltatást, amely az elindításáért és leállításáért felelős. Ezzel a néggyel a folyamat megszűnik név lenni, és olyan objektummá válik, amelyről gondolkodhat.

Ha a négy közül egy ismeretlen, álljon meg ott. Az ismeretlen összetevő kérdés a kiadó vagy a rendszergazda felé, nem kísérlet.

A régi naplóban szereplő PID most valaki máshoz tartozik

A folyamat-azonosítók újrahasznosulnak, és a tegnapi naplóból másolt szám most valami teljesen összefüggéstelenre mutathat. Mielőtt bármilyen következtetést levonna, hasonlítsa össze a kezdési időt a napló időbélyegével. Ugyanez igaz egy rövid névre is: egy termék két buildje azonos nevű és eltérő célú segédeket szállíthat. Az identitás a tuple, soha nem önmagában a szám.

Válassza szét a szerepeket, mielőtt bármi máshoz hozzányúlna. Egyetlen kapcsolat kliense, több alkalmazást kiszolgáló megosztott segéd, és mások munkameneteit fogadó kiszolgáló egyaránt háttérfolyamatnak látszik egy listában. Csak az egyikük állítható le olyan következmények nélkül, amelyeket nem vett figyelembe.

A tulajdonoson keresztül állítsa le, ne a jelzésen keresztül

Kezdje azzal a vezérlővel, amely a dolgot birtokolja: a kapcsolat Leválasztás gombjával, a szolgáltatás támogatott leállítási parancsával vagy a felügyeleti ügynök saját műveletével. Ezek az utak futtatják a termék által elvárt bontást, amely magában foglalja az útvonalak eltávolítását és az alagúteszköz lezárását. A jelzés mindezt kihagyja, és állapotot hagy maga után.

Figyelje meg, mi marad utána. A memóriában maradó folyamat talán a következő kapcsolatra vár, ami tervezési döntés, és nem sikertelen leállítás.

Miért indítja újra a felügyelő azt, amit megölt

Ha egy indító démon vagy egy automatikus kapcsolódási szabály azt szeretné, hogy az alagút fenn legyen, a folyamat megölése semmit sem fejez ki. A felügyelő látja a kilépést, és újraindítja, néha még mielőtt befejezné a napló olvasását.

Találja meg a felügyelőt, mielőtt harcolna vele. launchctl list megmutatja a betöltött feladatokat és címkéiket, és az életben tartás beállításával rendelkező feladat kilépéskor tervezés szerint újraindul. A helyes művelet ott a szándék megváltoztatása: töltse ki a feladatot, kapcsolja ki az automatikus kapcsolódási szabályt, vagy kérje meg a rendszergazdát erre. Az erőltetett kilépés más eszköz, más jelentéssel, és egy beragadt folyamat dokumentált helyreállítási eljárásához tartozik, nem a szokásos kapcsolatkezeléshez.

Az életciklus-eseményt rögzítse, ne az ölést

Írja fel az összetevő identitását, a kliens verzióját, az első releváns életciklus-eseményt és azt, hogy mit tett. Az esemény fontosabb a műveletnél, mert két példány megjelenése bejelentkezéskor olyan indítási sorrendprobléma, amely meg fog ismétlődni. Az a feljegyzés, amely megnevezi a végrehajtható fájlt és vezérlőjét, lehetővé teszi a következő embernek a reprodukálást.

Ezután ellenőrizze a szándékolt állapotot: a szolgáltatást, amelyre a felhasználónak szüksége volt, és a privát erőforrást, amelyet elér. Kerülje azt a csővezetéket, amely részstringet grep-el és minden találatot erőszakkal megöl, mert elveti a fenti mindent, és általában megsemmisíti annak bizonyítékát, miért létezett két példány. Ha a folyamat újra és újra visszatér, a lelet konfigurációs vagy sorrendezési hiba, és a javítás annak a dolga, aki a kliens indítási viselkedését birtokolja.

Kapcsolódó cikkek