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

SoIntMan

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?

Tyrdal

@SoIntMan
#include <unistd.h>
int daemon(int nochdir, int noclose);

SoIntMan

ok gut , angenommen ich starte "MyDeamon" so:

#include <unistd.h>
#include <stdio.h>

int
main(int argc, char* argv[])
{
  // change to the "/" directory
  int nochdir = 0;

  // redirect standard input, output and error to /dev/null
  // this is equivalent to "closing the file descriptors"
  int noclose = 0;

  // glibc call to daemonize this process without a double fork
  if(daemon(nochdir, noclose))
    perror("daemon");

  // our process is now a daemon!
  sleep(60);

  return 0;
}

wie kann ich dann bspw. sowas machen:

Befehlzeile:

user@linux: MyDemon --start
user@linux: MyDemon --stop
user@linux: MyDemon  --getState

und ich bekomm output?;)

cpr

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.

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.