Anzeige:
Ergebnis 1 bis 9 von 9

Thema: Geforkten Childprozess auskoppeln?

  1. #1
    Registrierter Benutzer
    Registriert seit
    02.07.2004
    Beiträge
    456

    Geforkten Childprozess auskoppeln?

    Hi Leute,

    ich hab in meinem Programm einen Child-Prozess mit fork() gestartet und mit exec() ein anderes Programm als solchen eingesetzt.

    Diesen Child-Prozess möchte ich zu einem bestimmten Zeitpunkt so auskoppeln, daß er und seine eigenen Childs (die Enkel des Parent) beim Terminieren (SIGTERM) des Parent-Prozesses NICHT mit beendet wird. Also so, daß sich der Child dann auf der selben Prozess-Ebene befindet, wie der Parent, quasi erwachsen wird...

    Geht sowas? Wenn ja, wie? Ich habe Zugriff auf die Sourcen aller drei Ebenen (Parent, Child, Enkel), kann dieses Auskoppeln also in jeder der drei Ebenen vornehmen, wenn nötig.

    Ein Enkel des Parent soll nämlich eben jenen Parent (welcher ein Service-Daemon ist) neu starten, ohne selber zu sterben (der besagte Enkel ist ein Update-Programm, das unter anderem den Parent erneuert).

  2. #2
    Registrierter Benutzer
    Registriert seit
    16.06.2003
    Beiträge
    73
    Hi,

    Vielleicht kann clone das was du brauchst:

    man 2 clone

    Ist allerdings erst ab einer bestimmten libc (glibc) Version verfügbar (siehe man page). Da gibt es das CLONE_PARENT Flag, mit welchem der neue Prozess den selben Vater bekommt wie der erzeugende Prozess. Die Prozesse laufen dann also als Kinder desselben Vaters.

  3. #3
    Registrierter Benutzer
    Registriert seit
    05.09.2002
    Ort
    Neuhausen
    Beiträge
    320
    Da Problem dabei sehe ich darin, dass es mehr als ein Child gibt und so der Update-Prozess die Rolle des Vaters übernehmen soll. Am einfachsten wird es sein, wenn der Parent mittels exec() sich durch das Update ersetzt, und der Update-Prozess bleibt was er ist. Sollte das nicht funktionieren, suchen wir weiter

    Gruss, Andy

  4. #4
    Registrierter Benutzer
    Registriert seit
    02.07.2004
    Beiträge
    456
    Hmm... RapidMax: dein Punkt bringt mich ins Grübeln... den Parent durch den Update-Prozess ersetzen... das muss ich mir mal genau anschauen.

    Bei Clone sehe ich das Problem, daß SIGCHLD Signale nicht mehr in dem eigentlichen Parent (der jetzt viel mehr ein Bruder-Prozess ist) ankommen. Das heißt, Kind geht nur bei Mama oder Papa petzen, nicht bei Brüderchen, oder?

  5. #5
    Registrierter Benutzer
    Registriert seit
    20.06.2005
    Beiträge
    40
    kannst du den vater nicht selbst beenden lassen? dann würden ja alle kinder weiterleben...
    Geändert von mcspam (03-07-2006 um 21:15 Uhr)

  6. #6
    Registrierter Benutzer
    Registriert seit
    02.07.2004
    Beiträge
    456
    Könnte ich über ein anderes Signal machen, ja. Die Kinder bleiben am Leben, wenn der Vater sich selbst terminiert?

  7. #7
    Registrierter Benutzer
    Registriert seit
    20.06.2005
    Beiträge
    40
    Zitat Zitat von 7.e.Q
    Die Kinder bleiben am Leben, wenn der Vater sich selbst terminiert?
    ja. hier mal ein Beispiel:
    Code:
    #include <unistd.h>
    #include <stdio.h>
    
    int main(void)
    {
        int client;
        if((client=fork())==0) {
            puts("child -> daemon");
            for(;;) {
                puts("alife");
                sleep(5);
            }
        }
        puts("parent -> quitting");
        return 0;
    }

  8. #8
    Registrierter Benutzer
    Registriert seit
    02.07.2004
    Beiträge
    456
    Logisch... so macht man Daemons. *kopf->tisch*

  9. #9
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    377
    Wieso nicht? Du musst nur unterscheiden koennen zwischen Zombi-Prozessen und Orphanen Prozessen.
    Sogar der Explorer von Windows laeuft als Orphaner Prozess. Der Userinit Prozess startet den Window Manager (explorer.exe) und beendet sch dann selber.
    Jedenfall funktioniert das bei Windows Vista so.
    Amilo D - 2,8 Ghz - ATI Radeon 9000
    Debian GNU/Linux 3.1 (Sarge)

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •