Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Märkligt beteende hos SIGKILL

Tråden skapades och har fått 4 svar. Det senaste inlägget skrevs .
1

Mitt långvariga IDE-projekt har eventuellt nått en brytpunkt: Eländet med att den ibland inte kan skapa processer kanske är åtgärdat, och på ett egendomligt sätt. Om man lämnar processer oavslutade så kan de ta upp resurser som till slut tar slut och då får man inte skapa fler processer.

När man vill stoppa en process (kompilering, debugging, körning av program, till och med vissa filkopieringar) så skickar man normalt kill med SIGTERM, vilket är att vänligt be processen avsluta. Går inte det skickar man SIGKILL, vilket är tvingande och skall alltid fungera. Men det gör det inte! Nu snurrar jag en loop med upprepade SIGKILL tills det går. Det kräver ofta ett par försök, men sällan mer än ett tiotal.

Frågan är bara om jag jagar spöken, om det är rätt fel jag löser. Det kan ju vara så att SIGKILL tar lite tid så att det kanske skulle funka om jag väntade lite... men så vitt jag kan se verkar det här hamrandet hjälpa.

Finns det andra här med erfarenhet av kill, SIGTERM, SIGKILL och sånt som har en åsikt?

  • Medlem
  • Stockholm
  • 2011-08-23 09:27

Du kanske inte jagar spöken utan zombies?

Om du ger en SIGKILL till en process så försvinner den inte genast utan blir en zombie tills dess att förälderprocessen läser av dess status med wait().

Med lämplig switch till ps kan du se om processen är en zombie.

Zombie process - Wikipedia, the free encyclopedia

Ursprungligen av pesc:

Du kanske inte jagar spöken utan zombies?

Om du ger en SIGKILL till en process så försvinner den inte genast utan blir en zombie tills dess att förälderprocessen läser av dess status med wait().

Vilket är exakt vad jag gör för att se om den stannat! Eller snarare med waitpid, men det borde väl vara likvärdigt?

Citat:

Med lämplig switch till ps kan du se om processen är en zombie.

Zombie process - Wikipedia, the free encyclopedia

Skall kolla det.

Det måste vara så att jag jagar fel bugg, att problemet inte är att nacka processen utan att stänga portarna till den. Dvs det är det jag börjar misstänka.

Nu har jag kommit en bit till på det här.

SIGKILL har jag avfärdat, det är inte där skon klämmer. Problemet är forkpty, att om jag skapar nya processer med den så lägger det av efter ett tag. Idag skrev jag ett hårt nedskalat exempel på hur det går fel:

---
#include <stdio.h>
#include <util.h>
#include <stdlib.h>
#include <unistd.h>

void RunTest(int i)
{
int pty;

switch(forkpty(&pty, NULL, NULL, NULL))
{
case -1: // Error
printf("pty error after %d\n", i); exit(1);
case 0: // Child
_exit(0);
default: // Parent
close(pty);
}
}

int main(int argc, char *const argv[])
{
int i;

for (i = 0; i < 1000; i++)
RunTest(i);
printf("Successfully ran %i times\n", i);
exit(0);
}
---

// Ultra-minimal pty demo showing the problem I have with failing pty code.
// The program just creates and closes ptys over and over.
// This will fail after pretty exactly 232 runs. (I have also seen 231 and 233.)
// If I don't close the pty, after 30 (running out of ptys).
// So I am running ut of something else. What?

Detta mysigt lilla exemplet skapar alltså pty-baserade processer om och om igen och stänger dem. Och det går... 232 gånger sådär. Sedan är det tvärnit. Vad är det som tar slut? Någon resurs som inte avallokeras?

Jaha, det problemet är löst. Den här gången var det verkligen zombies, för jag gjorde inte wait/waitpid på varje process, så de fortsatte vara zombies tills det inte fick vara fler underprocesser. Så den här gången var det faktiskt just det som pesc föreslog!

1
Bevaka tråden