Informationen eines (eignen) "deamon" process via shh abfragen

SeppJ

@SoIntMan sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

wie kann ich dann bspw. sowas machen:

Befehlzeile:
user@linux: MyDemon --start
user@linux: MyDemon --stop
user@linux: MyDemon  --getState
und ich bekomm output?;)

Normalerweise erst einmal gar nicht. Der ganze Witz an der Geschichte ist ja, dass der Daemon komplett abgekoppelt von der Umgebung ist, daher kann er natürlich auch nichts in dein Terminal schreiben. Was man noch machen kann, ist dem Daemon Signale senden, und der Daemon kann auf Dateien zugreifen. (Da deine Terminalausgabe auch eine Datei deines Terminalprozesses ist, könnte es sogar möglich sein, dem Daemon diese irgendwie zu kommunizieren, so dass er da was reinschreibt, aber das habe ich noch nie probiert.) Daher kann man so vorgehen:

Starte deine Daemonexecutable, der völlig unabhängige Daemonprozess ist nun in der Liste der Prozesse auffindbar
Der Daemonprozess wartet auf Signale, oder überwacht den Inhalt bestimmter, verabredeter Dateien
Du schickst dem Daemonprozess ein Signal und/oder änderst eine bestimmte, verabredete Datei
Der Daemon tut wie verlangt, z.B. schreibt seinen Status in eine bestimmte, verabredete Datei
Du guckst dir das Ergebnis am verabredeten Ort an

Das ist natürlich erst einmal abschreckend und umständlich. Signale an Prozesse schicken, die man sich selber suchen muss? Rechtemanagement für Dateien, die wer weiß wo liegen? Daher schreibt man sich ein kleines Wrapperscript, das diese Aufgaben übernimmt. Das Script startet den Daemon, kommuniziert mit diesem, und gibt die Antworten an dein Terminal. (Es hilft, wenn der Daemon seine Prozess-ID an einem verabredeten Ort hinterlegt, so dass das Script leichter mit ihm kommunizieren kann.) Das heißt, dein Script wird beispielsweise mit mein_daemon_wrapper --status aufgerufen, und hat dann einen Zweig, so dass es dem Daemonprozess das Signal zur Statusausgabe senden soll, es liest das Ergebnis aus der verabredeten Datei, und printed das dann. Natürlich mit Fehlerbehandlung, wie zu prüfen, ob der Daemon überhaupt läuft bei der Statusabfrage.

Dann hat man ja sehr häufig den Fall, dass der Daemon irgendwie ein globaler Systemservice sein soll. Hier kommt nun alles zusammen. Die meisten Linuxdistributionen kommen dafür mit irgendeinem Ökosystem, das es einem ermöglicht, solche Daemons zu steuern. systemd ist beispielsweise weit verbreitet. Du "installierst" da deinen Daemon, indem du dort dein Wrapperscript hinterlegst. Weiterhin sollte die Daemonexecutable natürlich für die Nutzer, die den Daemon steuern können sollen, zugreifbar sein, ebenso die Dateien für die Kommunikation - oft wählt man aber, dass nur Root so etwas darf. Und dann ist dein daemon voll eingebunden in das Ökosystem deiner Distribution. Du hast sicherlich schon einmal Kommandos der Art

sudo service irgendein_service --status

gesehen. Das würde einfach das Wrapperscript irgendein_service, das bei systemd hinterlegt ist, mit dem Parameter --status aufrufen. Das kann auch dein eigenes Wrapperscript sein, wenn du es dort hinpackst.

Ich muss gestehen, dass ich mir das autodidaktisch beigebracht habe. Vielleicht gibt es da noch irgendwelche netten Vereinfachungen, mit denen einem das Ökosystem hilft. Aber diese Methode funktioniert ja sogar ganz ohne Serviceökosystem und ist eigentlich gar nicht so schwer, wenn man das einmal gemacht hat. Wenn aber jemand noch tolle Tricks oder gute Konventionen kennt, bin ich auch interessiert.

SoIntMan

@cpr sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

Die Anzahl der Parameter (Arguments), mit der Dein "MyDemon" aufgerufen wurde, steht in argc, die Parameter selbst in argv. Achtung, der erste ist, meine ich, das current directory.
Ich würde hiervon was nehmen, um die zu verarbeiten: https://github.com/p-ranav/awesome-hpp?tab=readme-ov-file#argument-parsers
... und dann braucht dein Hauptprog. eben eine entsprechende Fallunterscheidung.
Vielleicht hab ich aber auch die Frage falsch verstanden.
Achso, bzgl. start/stop/getState: Dann würde ich zwei Binaries vorsehen - das erste (MyDemon) macht die Fallunterscheidung und startet dann entweder den eigentlichen Demon als eigenen Prozess (zweites Binary) oder sendet eine Stopanfrage an diesen Prozess oder eine getState-Anfrage. Kommunikation zwischen den beiden hätte ich über Files gemacht, für IPC gibts aber natürlich viele Möglichkeiten.

Danke für die Antwort. Aber das meinte ich nicht, war aber auch nich klar von mir kommuniziert. Ich meine ehr wie ich meinem Deamon Prozess Anweisungen geben nach dem es gestartet wurde und im Hintergrund läuft...

@SeppJ sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

Normalerweise erst einmal gar nicht. Der ganze Witz an der Geschichte ist ja, dass der Daemon komplett abgekoppelt von der Umgebung ist, daher kann er natürlich auch nichts in dein Terminal schreiben. Was man noch machen kann, ist dem Daemon Signale senden, und der Daemon kann auf Dateien zugreifen. (Da deine Terminalausgabe auch eine Datei deines Terminalprozesses ist, könnte es sogar möglich sein, dem Daemon diese irgendwie zu kommunizieren, so dass er da was reinschreibt, aber das habe ich noch nie probiert.) Daher kann man so vorgehen:

Starte deine Daemonexecutable, der völlig unabhängige Daemonprozess ist nun in der Liste der Prozesse auffindbar
Der Daemonprozess wartet auf Signale, oder überwacht den Inhalt bestimmter, verabredeter Dateien
Du schickst dem Daemonprozess ein Signal und/oder änderst eine bestimmte, verabredete Datei
Der Daemon tut wie verlangt, z.B. schreibt seinen Status in eine bestimmte, verabredete Datei
Du guckst dir das Ergebnis am verabredeten Ort an

Das ist natürlich erst einmal abschreckend und umständlich. Signale an Prozesse schicken, die man sich selber suchen muss? Rechtemanagement für Dateien, die wer weiß wo liegen? Daher schreibt man sich ein kleines Wrapperscript, das diese Aufgaben übernimmt. Das Script startet den Daemon, kommuniziert mit diesem, und gibt die Antworten an dein Terminal. (Es hilft, wenn der Daemon seine Prozess-ID an einem verabredeten Ort hinterlegt, so dass das Script leichter mit ihm kommunizieren kann.) Das heißt, dein Script wird beispielsweise mit mein_daemon_wrapper --status aufgerufen, und hat dann einen Zweig, so dass es dem Daemonprozess das Signal zur Statusausgabe senden soll, es liest das Ergebnis aus der verabredeten Datei, und printed das dann. Natürlich mit Fehlerbehandlung, wie zu prüfen, ob der Daemon überhaupt läuft bei der Statusabfrage.
Dann hat man ja sehr häufig den Fall, dass der Daemon irgendwie ein globaler Systemservice sein soll. Hier kommt nun alles zusammen. Die meisten Linuxdistributionen kommen dafür mit irgendeinem Ökosystem, das es einem ermöglicht, solche Daemons zu steuern. systemd ist beispielsweise weit verbreitet. Du "installierst" da deinen Daemon, indem du dort dein Wrapperscript hinterlegst. Weiterhin sollte die Daemonexecutable natürlich für die Nutzer, die den Daemon steuern können sollen, zugreifbar sein, ebenso die Dateien für die Kommunikation - oft wählt man aber, dass nur Root so etwas darf. Und dann ist dein daemon voll eingebunden in das Ökosystem deiner Distribution. Du hast sicherlich schon einmal Kommandos der Art
sudo service irgendein_service --status

gesehen. Das würde einfach das Wrapperscript irgendein_service, das bei systemd hinterlegt ist, mit dem Parameter --status aufrufen. Das kann auch dein eigenes Wrapperscript sein, wenn du es dort hinpackst.
Ich muss gestehen, dass ich mir das autodidaktisch beigebracht habe. Vielleicht gibt es da noch irgendwelche netten Vereinfachungen, mit denen einem das Ökosystem hilft. Aber diese Methode funktioniert ja sogar ganz ohne Serviceökosystem und ist eigentlich gar nicht so schwer, wenn man das einmal gemacht hat. Wenn aber jemand noch tolle Tricks oder gute Konventionen kennt, bin ich auch interessiert.

Kurz gesagt, du meinst ich habe mein "MyDeamon" Prozess und ein "MyDeamonControl" Executable..
Der "MyDeamon" Prozess wird gestarte und läuft im Hintergrund.

Meine "MyDeamonControl" mit Argumenten gestartet, verbindet sich, und kommuniziert mit meinen "MyDeamon" und gibt dessen ausgabe im Terminal aus.. und schließt wieder die Verbindung mit dem "MyDemon" ??

Eigentlich ein cooler Ansatz

SeppJ

Genau. Der Controller ist oft ein einfaches Shellscript.

Finnegan

Was die Kommunikation mit dem Hintergrundprozess angeht: Ich sehe viele simple Daemons, die über eine Named Pipe kommunizieren. Ich hatte zwar selbst noch nicht nötig, sowas zu programmieren, aber das scheint mir ein recht einfacher Ansatz zu sein. Das ist letztendlich eine Datei an einem "vereinbarten" Ort und die Kommunikation programmiert man dann so, als sei die Datei jeweils stdin/stdout für Hintergrund- und Kontrollprozess.

Ist vielleicht ein sinnvoller Ansatz für Experimente, da man sich so erstmal komplexere IPC-Methoden oder gar Netzwerkkommunikation zwischen Service und Client sparen kann.

*john 0

Die einfachste Variante ist es eine Konfigurationsdatei zu haben, die immer dann eingelesen wird, wenn ein SIGHUP empfangen wird.

SoIntMan

@Finnegan sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

Was die Kommunikation mit dem Hintergrundprozess angeht: Ich sehe viele simple Daemons, die über eine Named Pipe kommunizieren. Ich hatte zwar selbst noch nicht nötig, sowas zu programmieren, aber das scheint mir ein recht einfacher Ansatz zu sein. Das ist letztendlich eine Datei an einem "vereinbarten" Ort und die Kommunikation programmiert man dann so, als sei die Datei jeweils stdin/stdout für Hintergrund- und Kontrollprozess.
Ist vielleicht ein sinnvoller Ansatz für Experimente, da man sich so erstmal komplexere IPC-Methoden oder gar Netzwerkkommunikation zwischen Service und Client sparen kann.

Ja an named-pipes habe ich auch schon gedacht:) habe aber mir auch schon Gedanken gemacht ggf. REST zu verwenden, dann wäre die deaom terminal komm nicht zu properitär.. mal überlegen;)

@john-0 sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

Die einfachste Variante ist es eine Konfigurationsdatei zu haben, die immer dann eingelesen wird, wenn ein SIGHUP empfangen wird.

das verstehe ich nicht , kannst du mal ein beispiel machen, oder mehr infos dazu geben?

*john 0

@SoIntMan sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

das verstehe ich nicht , kannst du mal ein beispiel machen, oder mehr infos dazu geben?

Du schreibst einen signal handler, registrierst diesen mit der Funktion sigaction und dann wird jedesmal, wenn jemand das passende Signal schickt diese Routine ausgeführt.

Hier kannst Du Dir ein Beispiel anschauen. Beispiel

Finnegan

@SoIntMan sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

@Finnegan sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

Was die Kommunikation mit dem Hintergrundprozess angeht: Ich sehe viele simple Daemons, die über eine Named Pipe kommunizieren. Ich hatte zwar selbst noch nicht nötig, sowas zu programmieren, aber das scheint mir ein recht einfacher Ansatz zu sein. Das ist letztendlich eine Datei an einem "vereinbarten" Ort und die Kommunikation programmiert man dann so, als sei die Datei jeweils stdin/stdout für Hintergrund- und Kontrollprozess.
Ist vielleicht ein sinnvoller Ansatz für Experimente, da man sich so erstmal komplexere IPC-Methoden oder gar Netzwerkkommunikation zwischen Service und Client sparen kann.

Ja an named-pipes habe ich auch schon gedacht:) habe aber mir auch schon Gedanken gemacht ggf. REST zu verwenden, dann wäre die deaom terminal komm nicht zu properitär.. mal überlegen;)

Ich dachte auch eher an eine simple Lösung für ein z.B. in C oder C++ geschriebenes Programm. Diesem ein REST-Interface zu verpassen würde enorm viele Abhängigkeiten hinzufügen, während für Pipes die Standardbibliothek und vielleicht ein paar System-Header ausreichen.

Vielleicht ist für REST auch ein simples Programm eine Idee, das lediglich auf stdin und stdout arbeitet und über CGI die ganze Netzwerk- und Protokoll-Komplexität von einem Webserver erledigen lässt. Der "Daemon" wäre dann quasi der Webserver-Prozess. Das hat natürlich den Nachteil, das das Programm nur dann aktiv wird, wenn eine Anfrage an die API geschickt wird. Je nach Art des "Service" kann das ausreichend sein, wenn man aber auch langfristigere Jobs im Hintergrund erledigen will, müsste man da anders rangehen: Dann wäre tatsächlich ein eigener Daemon angesagt.

Ich habe sowas zwar noch nicht gemacht, aber es gibt definitiv Bibliotheken für einen simplen HTTP-Server, mit denen man sowas machen kann. Die müssen meines Erachtens nicht viel können, ein einfacher, schlanker HTTP/1.1-Server ohne Verschlüsselung würde reichen. Den würde man dann für die Kommunikation mit der Außenwelt über eine Reverse Proxy-Konfiguration mit einem vollwertigen Webserver anbinden. Dieser würde dann Dinge wie Verschlüsselung oder modernere Protokolle übernehmen, ohne dass man die selbst in den Daemon integrieren müsste (was sehr aufwändig und fehleranfällig wäre).

Ansonsten gibt's natürlich noch zig andere Möglichkeiten, das Problem anzugehen. Über Dateien, wie von @john-0 angeregt, über Shared Memory in einem Memory Mapped File, ein eigenes Netzwerkprotokoll, Dienste wie D-Bus und ähnliche, etc.

SoIntMan

@Finnegan sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

Ich dachte auch eher an eine simple Lösung für ein z.B. in C oder C++ geschriebenes Programm. Diesem ein REST-Interface zu verpassen würde enorm viele Abhängigkeiten hinzufügen, während für Pipes die Standardbibliothek und vielleicht ein paar System-Header ausreichen.
Vielleicht ist für REST auch ein simples Programm eine Idee, das lediglich auf stdin und stdout arbeitet und über CGI die ganze Netzwerk- und Protokoll-Komplexität von einem Webserver erledigen lässt. Der "Daemon" wäre dann quasi der Webserver-Prozess. Das hat natürlich den Nachteil, das das Programm nur dann aktiv wird, wenn eine Anfrage an die API geschickt wird. Je nach Art des "Service" kann das ausreichend sein, wenn man aber auch langfristigere Jobs im Hintergrund erledigen will, müsste man da anders rangehen: Dann wäre tatsächlich ein eigener Daemon angesagt.
Ich habe sowas zwar noch nicht gemacht, aber es gibt definitiv Bibliotheken für einen simplen HTTP-Server, mit denen man sowas machen kann. Die müssen meines Erachtens nicht viel können, ein einfacher, schlanker HTTP/1.1-Server ohne Verschlüsselung würde reichen. Den würde man dann für die Kommunikation mit der Außenwelt über eine Reverse Proxy-Konfiguration mit einem vollwertigen Webserver anbinden. Dieser würde dann Dinge wie Verschlüsselung oder modernere Protokolle übernehmen, ohne dass man die selbst in den Daemon integrieren müsste (was sehr aufwändig und fehleranfällig wäre).
Ansonsten gibt's natürlich noch zig andere Möglichkeiten, das Problem anzugehen. Über Dateien, wie von @john-0 angeregt, über Shared Memory in einem Memory Mapped File, ein eigenes Netzwerkprotokoll, Dienste wie D-Bus und ähnliche, etc.

ja da hast du schon recht... vom Aufwand her wäre namee-pipes wäre überschaubar. REST wäre halt dann cool wenn man den Demon auch von außen "diagnostiieren" könnte. Aber würde alles aufplustern.. schon richtig

@cpr sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

Die Anzahl der Parameter (Arguments), mit der Dein "MyDemon" aufgerufen wurde, steht in argc, die Parameter selbst in argv. Achtung, der erste ist, meine ich, das current directory.
Ich würde hiervon was nehmen, um die zu verarbeiten: https://github.com/p-ranav/awesome-hpp?tab=readme-ov-file#argument-parsers

der parser schau ich mir an.. das macht es einfacher... danke dir

@SoIntMan sagte in Informationen eines (eignen) "deamon" process via shh abfragen:

Hallo Leute,

bin relative frisch in der Linux, kann vll. bissel die basics.. aber ich kann schonmal eine simple Anwendung compilieren und ausführen.:) ok soweit so gut..

Ich möchte eine Anwendung bzw. als Deamon process implementieren der als service läuft.. via ssh möchte ich dann gerne Informationen des laufenden Processes abrufen. bspw- Process state etc.

Gibt es da in linux eine api/methodik mit der ich sowas machen könnte?

Mit systemd kannst du all dies implementieren. Wenn du eine eigene Anwendung hast, musst du die zusätzlichen Features eigenständig implementieren. systemd hilft dir dabei sogenannte Service-Dateien zu haben, und weiteres. Beispielsweise systemd.timer eignet sich für eine direkte Schnittstelle zwischen einem Init-System-Dienst und einem definierbaren Timer.

Wenn das ein selbstständig programmierter Daemon ist musst du die Dinge augenscheinlich selbst implementieren, wenn es ein Programm ist, welches als Daemon anwendbar ist würde ich auf die systemd Infrastruktur zugreifen.

AthSoon

Dieser Beitrag wurde gelöscht!