In den beiden Kapiteln zuvor dürfte sich die Frage gestellt haben, wie man wohl eigene Dämonen erstellen kann.

Wenn sie mal in der Konsole....

pstree | less  

....eingeben, wird Ihnen auffallen, das alle Dämonprozesse als Elternprozess den init-Prozess haben (wie sie eigentlich schon wissen sollten). Und sie wiesen auch wenn sich der Elternprozess vor dem Kindprozess beendet, haben wir ein Waisenkind, dessen sich der Vater aller Prozesse init annimmt.

Nun sehen sie sich nochmals die Prozesse mit pstree | less an. Sie sehen das alle Prozesse einen Anführer haben, einen Dämonprozess. Wie können wir es nun bewerkstelligen das der verwaiste Kindprozess, dessen sich init angenommen hat, zum Häuptling, genauer Sessionsführer wird?

Ein Aufruf der man-Page (deutsch)......

man 2 setsid  

...gibt uns darüber Auskunft. Diese Funktion erzeugt als eine neue Sitzung wenn der aufrufenden Prozess, kein Prozessgruppenführer ist. Somit wird der Aufrufende Prozess der einzige Prozess in der neuen Prozessgruppe und in dieser Sitzung. Hier der Syntax für setsid........

#include <stdio.h>

pid_t setsid(void); 

Mehr dazu entnehmen sie bitte der aus angesprochenen man-Pages. Zum Schluss wechseln wir noch mal ins Root-Wurzelverzeichnis und setzen die Dateikreierungsmaske auf 0.

Weitere Vorgänge sind im Code dokumentiert......

/*Download:mydaemon.c*/ #include <stdio.h> #include <unistd.h> #include <syslog.h> #include <sys/types.h> #define CHILD 0 #define ERROR -1 void start_daemon(char *log_name, int facility) { int i; pid_t pid; /*Elternprozeß beenden, somit haben wir einen Waisen dessen sie jetzt vorerst init annimmt*/ if((pid = fork()) != CHILD) exit(0); /*Unser Kindprozess wird zum Session-Führer. Mißlingt dies, kann der Fehler daran liegen das der Prozeß bereits Sessionführer ist */ if(setsid() == ERROR) { fprintf(stderr, "%s kann nicht Session-Führer werden!\n",log_name); exit(0); } /* Gründe für das Root-Wurzelverzeichnis: +core-Datei wird im aktuellen Arbeitsverzeichnis hinterlegt +Damit bei Beendigung mit umount das Dateisystem sicher abgehängt werde kann */ chdir("/"); /*Damit wir nicht die Bitmaske vom Elternprozeß erben bzw. diese bleiben, stellen wir diese auf 0*/ umask(0); /*Wir schließen alle geöffneten Filedeskriptoren....*/ for(i=sysconf(_SC_OPEN_MAX); i>0; i--) close(i); /*Da unser Dämonprozeß selbst kein Terminal für die Ausgabe hat....*/ openlog(log_name, LOG_PID, facility); } int main(int argc, char **argv) { start_daemon("meinDaemon", LOG_USER); while(1); /*Enlossschleifen: Hier sollte nun der Code für den Daemon stehen, was immer er auch tun soll. Bei Fehlermeldungen Beispiesweise: if(dies_ist_Passiert) syslog(LOG_WARNING, "dies_ist_Passiert"); else if(das_ist_Passiert) syslog(LOG_INFO, "das_ist_Passiert");*/ return 0; }

Starten sie nun dieses Programm und geben sie im Terminal....

ps xj  

...ein und sie erkennen unseren Dämonprozess am Fragezeichen bei TTY und am Elternprozess PPID der hier 1 (init) ist. Wir habe in diesem Fall einfach einen Dämonprozess gestartet, der nichts tut. Fehlermeldungen oder sonstige Nachrichten die uns der Dämonprozess schickt müssen sie ebenso selbst mit der Datei syslog.conf abgleichen (siehe Kapitel zuvor). Wir haben hier zwar als Typen LOG_USER verwendet aber sollten sie schon selbst darauf achten wo die Nachricht dafür geschrieben wird (/dev/log).

Vor kurzem bekam ich eine Mail, in der jemand die Frage stellte, ob ein Dämon ähnlich wie ein Trojaner funktioniert und wie es mit der Sicherheit dabei aussieht? Im Prinzip kann man sich den Dämon als einen Trojaner vorstellen, da es sich dabei ja auch um Prozesse im Hintergrund handelt. Aber Sicherheitsprobleme dürften sich da nicht finden. Denn für einen Dämon benötigt man erst mal root-Rechte. Selbst wenn man diese theoretisch hat gibt es noch einig Dinge zu beachten. Dazu finden sie Sicherlich auf anderen Webseiten etwas.

Ein weiterer Hinweis zu unserem Programmbeispiel oben. Da ein Dämon kein Terminal zur Verfügung stehen hat, sollten einen Signalhandler einrichten der folgende Signale IGNORIEREN soll....

SIGHUP,SIGINT, SIGWINCH  

Wie sie Signalhandler einrichten können steht im Kapitel "Signale".

cron-Jobs == Dämonprozess? Viele von euch werden sich jetzt sicherlich fragen, wie sie einen Dämonprozeß dauerhaft einrichten können?

• Entweder sie schreiben ein Skript für Ihren Dämon wie sie diese in /etc/rc.d/init.d/ oder /etc/init.d/ finden.
  
  
• Oder sie verwenden cron-Jobs. crond ist ebenfalls ein Dämon, mit dem sie Programme zu einer bestimmten Zeit und Datum ausführen können.

Wir wollen uns die cron-Jobs ansehen. Die Programme oder Skripte die vom cron-Job aufgerufen werden, laufen wiederum als Dämon (egal ob sie sie als Dämon geschrieben haben oder nicht). Der cron - Dämon wird bereits zu Systemstart mit Hilfe eines Skriptes gestartet.

Was für Programme sie verwenden bleibt Ihnen überlassen. Häufig verwendet werden dafür Perl-Skripts, Shell-Skripts, C-Programme oder CGI-Programme.

Sie finden die Konfigurations-Files im Verzeichnis /etc Die Zentrale Datei dazu ist /etc/crontab. Mit diesem Befehl können sie eigene cron-Jobs komfortabel erstellen.

Im Internet finden sie Tausende Seiten die Dokumentieren wie sie einen cron-Job einrichten können. Wem das Errichten von cron-Jobs in der Text-Konsole zu lau ist, der kann sich ja für KDE kcron oder für alle Vcron ansehen.

Zugegeben, man könnte zu diesem Thema noch mehr schreiben, aber sie wissen jetzt zumindest, wie sie Dämonprozesse selbst erstellen können und wie sie (Fehler)Meldungen dieser Prozessen anzeigen bzw. protokollieren können. Wir werden bei der Netzwerkprogrammierung dieses Thema wieder aufgreifen.