[gelöst] daemon mit g++

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
debian inside
Beiträge: 65
Registriert: 13.03.2004 10:41:31

[gelöst] daemon mit g++

Beitrag von debian inside » 27.11.2004 15:48:37

hab ein programm mit g++ geschrieben das auch super läuft nur wenn ich es als daemon laufen lassen will beendet sich dieser immer

Code: Alles auswählen

#include <stdlib.h>
#include <stdio.h>
#include <iostream>
#include <mysql/mysql.h>
#include <string>
#include <unistd.h>
#include <sstream>
#include <sys/stat.h>
#include <syslog.h>

#define CHILD 0
#define ERROR -1
void start_daemon(char *log_name, int facility)
{
    int i;
    pid_t pid;
	if((pid = fork()) != CHILD) exit(0);
	 if(setsid() == ERROR)
	  {
	  fprintf(stderr, "%s kann nicht Session-Führer werden!\n",log_name);
	  exit(0);
	  }
	 chdir("/");
	 umask(0);
	 for(i=sysconf(_SC_OPEN_MAX); i>0; i--)
	  close(i);
}
...
int main(int argc, char *argv[]) {
...
		 int log_user;
		 start_daemon("chatd",log_user);
		 while(1){
...
wie kann ich den grund herausfinden?
oder hat jemand ne idee was ich falsch mach?

danke,
Thomas
Zuletzt geändert von debian inside am 28.11.2004 00:45:08, insgesamt 1-mal geändert.

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 27.11.2004 16:25:46

ähm... Entweder verstehe ich Dich falsch, oder Deine Formulierung ist nicht ganz eindeutig: Das Programm forkt ja, und der Parent beendet sich dann. Ohne jetzt nochmal nachgeschaut zu haben, sollte das das Child entweder mit "in den Tod" reissen... Du müsstest im Parent mit "wait" auf das Child warten...

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

debian inside
Beiträge: 65
Registriert: 13.03.2004 10:41:31

Beitrag von debian inside » 27.11.2004 22:31:41

ich hab da irgendwie noch ein problem beim verstehen
eigentlich sollte das ding sich selbst nochmal starten und danach selbstmord machen oder?

übernimmt den neuen prozess automatisch init?
wie bekommt der parent prozess mit das das child läuft?
wie merkt der child prozess das er sich nicht selbst killen soll?

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 27.11.2004 22:45:34

der parent prozeß muß sterben, sonst wird der child nicht vom parent detached und lauft nicht mit der parent id 1 (init)

i = fork();
if (i<0) exit(1); // error
if (i>0) exit(0); // parent stirbt
// child continues
...


( unter windows reißt der parent die child prozesse nieder, wenn er stirbt )

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 27.11.2004 23:16:30

bei mir funktioniert dein code.

baue beim fork eine fehlerbehandlung ein und überprüfe ob dein programm nicht vielleicht nach dem fork sehr schnell terminiert

debian inside
Beiträge: 65
Registriert: 13.03.2004 10:41:31

Beitrag von debian inside » 28.11.2004 00:07:11

wie beendet man die ausgabe im terminal?
bei tty zeigt top schon ein ? aber per ssh seh ich das programm noch laufen

[EDIT] ok hab erkannt das es klappt solange man nichts ausgibt 8)
Zuletzt geändert von debian inside am 28.11.2004 00:38:50, insgesamt 1-mal geändert.

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 28.11.2004 00:38:17

ja die standard file descriptor gehören auch geschlossen:

close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 28.11.2004 00:43:01

wozu ist der code gut ?

for(i=sysconf(_SC_OPEN_MAX); i>0; i--)
close(i);

debian inside
Beiträge: 65
Registriert: 13.03.2004 10:41:31

Beitrag von debian inside » 28.11.2004 00:46:42

schließt alle geöffneten Filedeskriptoren

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 28.11.2004 00:56:57

habe mich gerade schlau gemacht, ist keine schlechte lösung

Antworten