2010-09-14 13 views
8

Przeczytałem już stronę podręcznika dla rodziny funkcji pidfile. Ale tak naprawdę nie rozumiem tego. Jakie jest prawidłowe użycie? Czy jest dostępny bardziej rozbudowany przykład? Myślę, że rozumiem pidfile_open. Ale kiedy powinienem zadzwonić pod numer pidfile_write i prdfile_close? Z którego procesu? Rodzic czy dziecko? Jakie parametry muszę przekazać do tych funkcji? Prawdopodobnie brakuje mi pewnej podstawki * nix.Jak poprawnie korzystać z biblioteki pidfile?

Aktualizacja:

Poniżej można zobaczyć przykład od człowieka pliki pid. Dlaczego się rozwidlają dwa razy? Dlaczego pidfile_close? Kiedy wołam pidfile_close mogę uruchomić innego demona. Czy to nie jest niechciane?

struct pidfh *pfh; 
pid_t otherpid, childpid; 

pfh = pidfile_open("/var/run/daemon.pid", 0600, &otherpid); 
if (pfh == NULL) { 
     if (errno == EEXIST) { 
       errx(EXIT_FAILURE, "Daemon already running, pid: %jd.", 
        (intmax_t)otherpid); 
     } 
     /* If we cannot create pidfile from other reasons, only warn. */ 
     warn("Cannot open or create pidfile"); 
} 

if (daemon(0, 0) == -1) { 
     warn("Cannot daemonize"); 
     pidfile_remove(pfh); 
     exit(EXIT_FAILURE); 
} 

pidfile_write(pfh); 

for (;;) { 
     /* Do work. */ 
     childpid = fork(); 
     switch (childpid) { 
     case -1: 
       syslog(LOG_ERR, "Cannot fork(): %s.", strerror(errno)); 
       break; 
     case 0: 
       pidfile_close(pfh); 
       /* Do child work. */ 
       break; 
     default: 
       syslog(LOG_INFO, "Child %jd started.", (intmax_t)childpid); 
       break; 
     } 
} 

pidfile_remove(pfh); 
exit(EXIT_SUCCESS); 
+0

Czy strona podręcznika ma sekcję "przykład"? Jest to BSD, co dość dobrze ilustruje powszechne użycie. Zobacz http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?pidfile+3, zobacz sekcję "przykład". –

+0

@Tim, strona man zawiera przykład, ale mam problemy z zastosowaniem go do mojego kodu demona. Mój demon ma inną strukturę. Na przykład nie używam demona funkcji (3). –

Odpowiedz

5

Problemem jest to, że chcesz dać się komunikat o błędzie, zanim demon jest zrodził, i że wiesz plik PID po demon jest zrodził.

Zwykle robisz pidfile_open przed widelcem, co daje ci możliwość wyświetlenia komunikatu o błędzie. Po rozwidleniu znasz plik pid i możesz zrobić plik pidfile_write.

+0

Dlaczego widelec tak? daemon(), czyż nie? Dlaczego drugi widelec? –

+0

Tak, daemon(). Miałem na myśli tego widelca, nie ma drugiego widelca. Tak więc wywołujemy pidfile_open(), daemon(), pidfile_write(), pidfile_close(). W ten sposób możesz wyprowadzać dowolne błędy z pidfile_open() na terminalu (zanim zostanie on odłączony) i zapisać PID elementu podrzędnego, który jest znany tylko po wywołaniu daemona(). – Sjoerd

+0

Och, myślałem, że chodzi ci o przykładowy kod z pliku pidfile man. Ponieważ istnieje "drugi" fork po demonie(). Wiesz dlaczego? –

1

Wykonuje się pidfile_open (3) przed przejściem do tła, dzięki czemu można natychmiast zgłaszać wszelkie problemy. Nie piszesz jeszcze PID, ponieważ twój PID zmieni się po demonie (3). pidfile_open (3) tylko blokuje plik pidfile. Po demonie (3) możesz wywołać pidfile_write (3), ponieważ masz teraz swój końcowy PID (demon (3) wewnętrzny). W głównym procesie nie można wywołać pidfile_close (3), ponieważ jest to cały pomysł - poprzez utrzymywanie otwartego i zablokowanego pliku pidfile dajesz innym znać, że nadal żyjesz. Drugie widowisko jest całkowicie opcjonalne. Obrazuje powszechne zachowanie, które demony wywołują procesy potomne/pracownicze. Jeśli ich nie używasz, nie potrzebujesz tego widelca(). Ten fork() jest tam tylko po to, aby pokazać, że w takim procesie roboczym powinieneś zamknąć plik pid, więc jest on tylko otwarty i zablokowany przez główny proces, a nie przez dziecko.

Powiązane problemy