Also das ding startet zwar auf unix, aber mehr nicht. Wenn das geklappt hätte, dann hätte ich bestimmt nicht gefragt
Erstellen eines Daemons und unix
Re: Erstellen eines Daemons und unix
Ne, wir reden aneinander vorbei. Ich habe Lazarus auf Debian. Dort habe ich lazdaemon installiert. Wenn ich nun auf Datei/Neu gehe kann ich mir einen Daemon ohne GUI auswählen. Wenn ich das mache und "leer" erstelle, dann kommt ein 2MB teil hinten raus was für unix ist. Dort habe ich auch die shell aufgabe her die ich oben gepostet habe.
Also das ding startet zwar auf unix, aber mehr nicht. Wenn das geklappt hätte, dann hätte ich bestimmt nicht gefragt
Also das ding startet zwar auf unix, aber mehr nicht. Wenn das geklappt hätte, dann hätte ich bestimmt nicht gefragt
-
mschnell
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Erstellen eines Daemons und unix
Also kommt kein Windows Dienst da raus.
Alles klar.
-Michael
Alles klar.
-Michael
Re: Erstellen eines Daemons und unix
Ne, also man kann es nicht auf windows starten. Aber das ding meint es wäre ein windows-dienst. Es ist halt ein unix programm. Ich denke mal das die "vorlage" nicht stimmt bzw. nur für windows ist.
-
Christian
- Beiträge: 6079
- Registriert: Do 21. Sep 2006, 07:51
- OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
- CPU-Target: AVR,ARM,x86(-64)
- Wohnort: Dessau
- Kontaktdaten:
Re: Erstellen eines Daemons und unix
Doxh stimmt alles du weisst nur nicht wie man unter unix nen daemon startet
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/
Re: Erstellen eines Daemons und unix
Ich zwar nicht was du grade meinst, aber ich bin ja hier weil ich nicht alles weiß. Dann sag es mir doch was ich falsch mache.
-
mschnell
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: Erstellen eines Daemons und unix
Vielleicht muss auch noch geklärt werden, was überhaupt unter einem "Daemon" verstanden wird.
Zunächst ist klar dass ein Daemon keine direkte Bedienung durch einen Benutzer benötigt / zulässt. Er hat also werde eine GUI noch kommuniziert er per ByteStream mit einem Terminal.
Hieraus folgt, dass er auf einem System laufen können sollte, dass keine GUI zur Verfügung stellt (er also kein Binding zu einem GUI System hat). Von einem Kommandozeilen-Programm ist er eigentlich nur dadurch unterschieden, dass die Standard Input und Output-Pipes (stdin, stdout, stderr) beim Start nicht an ein Terminal verbunden werden. Das muss die Software des Daemon berücksichtigen, aber nicht realisieren.
Wenn man einen Daemon vom System-Initialisierungs-Script-System (also indirekt über initab) oder direkt durch initab starten will, braucht er sich nicht selbst zu daemonisieren, dass kann das Start-System tun. Stderr wird dann üblicherweise automatisch zum syslog Daemon verbunden (die Ausgaben landen dann z.B. in /log/messages).
Da "normalerweise" keine GUI angekoppelt (s.o.) ist, gehen in Lazarus TTimer, QueuAsnycCall und ähnliche Funktionalitäten nicht. Man kann also nicht "Event-orientiert" programmieren, sondern muss selber eine "Hauptschleife" bauen.
Da der Deamon sich ja nicht (so schnell) beenden soll, und auch keine 100% CPU Last erzeugen darf, muss er in der Hauptschleife irgendwo warten. Das geht am einfachsten mit Sleep (was aber eine unerwünschte Grundlast und eine unerwünschte Latenz erzeugt). Schöner ist es, auf einen Treiber zu warten (z.B. mit Blocking Read), dann kann man aber nur auf diesen einen warten (es sei denn man programmiert mehrere Threads). In Linux gibt es als Lösung Spezialitäten wie "Select" oder "epoll", in Windows gibt es System-Messages und Blocking read mit Timeout. Ich glaube aber nicht, das so etwas in Lazarus in (Linux/Mac/Windows) portierbarer Weise enkapsuliert ist.
Viele Linux-Daemons können sich (z.B. bei Angabe entsprechender Kommandozeilen-Optionen) selbst daemonisieren (in den Hintergrund schieben). Ich finde, das ist nett, aber nicht wirklich zwingend notwendig.
Beispiel:
Ein Daemon soll Zeichen von einer seriellen Schnittstelle empfangen und auf eine andere ausgeben.
Kann man z.B. einfach durch
cp /dev/tty0 /dev/tty1 &
realisieren.
Ein entsprechendes Programm zu schreiben, ist auch kein Problem.
Will man das bidirektional machen kann man (Linux-typisch) einfach zwei Daemons verwenden:
cp /dev/tty0 /dev/tty1 &
cp /dev/tty1 /dev/tty0 &
Das geht natürlich nur bei völlig unabhängigen Funktionen. Ansonsten muss das in einem Programm realisiert werden.
Das muss nun auf beide Input-Treiber gleichzeitig warten (z.B. mit sleep und non-blocking read oder mit select() und blocking read - siehe oben).
Wenn ein Linux-Daemon irgendwie bedient werden soll (z.B. Aufforderung, sich zu beenden), kann er Signale (kill) verarbeiten und/oder z.B. eine entsprechende pipe-Schnittstelle zu einem Bedien-Programm zur Verfügung stellen (Bei Windows verwendet man Windows-Messages). Das (z.B.) Suse rc-Script System definiert dazu einige Mechanismen, an die man sich halten kann, wenn man will. Hier werden alle Daemons über init Scripts gestartet, die beim Systemstart (und -ende) je nach run-level ausgeführt werden. Zur Bedienung steht bei richtiger Installation (über eine rpc-Datei) u.a. für einen Daemon (der beispielsweise System-Notations-konform "mydaemond" heißt) ein vom Benutzer in der Kommandozeile auszuführendes Script (das entsprechend "rcmydeamon" heißt) bereit, dass mindestens die Parameter "start" "stop" und "restart" kennt.
-Michael
Zunächst ist klar dass ein Daemon keine direkte Bedienung durch einen Benutzer benötigt / zulässt. Er hat also werde eine GUI noch kommuniziert er per ByteStream mit einem Terminal.
Hieraus folgt, dass er auf einem System laufen können sollte, dass keine GUI zur Verfügung stellt (er also kein Binding zu einem GUI System hat). Von einem Kommandozeilen-Programm ist er eigentlich nur dadurch unterschieden, dass die Standard Input und Output-Pipes (stdin, stdout, stderr) beim Start nicht an ein Terminal verbunden werden. Das muss die Software des Daemon berücksichtigen, aber nicht realisieren.
Wenn man einen Daemon vom System-Initialisierungs-Script-System (also indirekt über initab) oder direkt durch initab starten will, braucht er sich nicht selbst zu daemonisieren, dass kann das Start-System tun. Stderr wird dann üblicherweise automatisch zum syslog Daemon verbunden (die Ausgaben landen dann z.B. in /log/messages).
Da "normalerweise" keine GUI angekoppelt (s.o.) ist, gehen in Lazarus TTimer, QueuAsnycCall und ähnliche Funktionalitäten nicht. Man kann also nicht "Event-orientiert" programmieren, sondern muss selber eine "Hauptschleife" bauen.
Da der Deamon sich ja nicht (so schnell) beenden soll, und auch keine 100% CPU Last erzeugen darf, muss er in der Hauptschleife irgendwo warten. Das geht am einfachsten mit Sleep (was aber eine unerwünschte Grundlast und eine unerwünschte Latenz erzeugt). Schöner ist es, auf einen Treiber zu warten (z.B. mit Blocking Read), dann kann man aber nur auf diesen einen warten (es sei denn man programmiert mehrere Threads). In Linux gibt es als Lösung Spezialitäten wie "Select" oder "epoll", in Windows gibt es System-Messages und Blocking read mit Timeout. Ich glaube aber nicht, das so etwas in Lazarus in (Linux/Mac/Windows) portierbarer Weise enkapsuliert ist.
Viele Linux-Daemons können sich (z.B. bei Angabe entsprechender Kommandozeilen-Optionen) selbst daemonisieren (in den Hintergrund schieben). Ich finde, das ist nett, aber nicht wirklich zwingend notwendig.
Beispiel:
Ein Daemon soll Zeichen von einer seriellen Schnittstelle empfangen und auf eine andere ausgeben.
Kann man z.B. einfach durch
cp /dev/tty0 /dev/tty1 &
realisieren.
Ein entsprechendes Programm zu schreiben, ist auch kein Problem.
Will man das bidirektional machen kann man (Linux-typisch) einfach zwei Daemons verwenden:
cp /dev/tty0 /dev/tty1 &
cp /dev/tty1 /dev/tty0 &
Das geht natürlich nur bei völlig unabhängigen Funktionen. Ansonsten muss das in einem Programm realisiert werden.
Das muss nun auf beide Input-Treiber gleichzeitig warten (z.B. mit sleep und non-blocking read oder mit select() und blocking read - siehe oben).
Wenn ein Linux-Daemon irgendwie bedient werden soll (z.B. Aufforderung, sich zu beenden), kann er Signale (kill) verarbeiten und/oder z.B. eine entsprechende pipe-Schnittstelle zu einem Bedien-Programm zur Verfügung stellen (Bei Windows verwendet man Windows-Messages). Das (z.B.) Suse rc-Script System definiert dazu einige Mechanismen, an die man sich halten kann, wenn man will. Hier werden alle Daemons über init Scripts gestartet, die beim Systemstart (und -ende) je nach run-level ausgeführt werden. Zur Bedienung steht bei richtiger Installation (über eine rpc-Datei) u.a. für einen Daemon (der beispielsweise System-Notations-konform "mydaemond" heißt) ein vom Benutzer in der Kommandozeile auszuführendes Script (das entsprechend "rcmydeamon" heißt) bereit, dass mindestens die Parameter "start" "stop" und "restart" kennt.
-Michael
Verein
Links
Suche