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

[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

[Ein ehemaliger Benutzer]

@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!

[dadidag]

Die systemd Infrastruktur ist eindeutig die modernere Methode, Services zu machen. Vor allem muss man nicht selbst einen Daemon machen.
Das daemon(nochdir, noclose) reicht nicht, ein Daemon muss sich 2 Mal selbst forken um a) kein Kontrollterminal zu haben und b) um nicht in einer Prozessgruppe zu sein.

Weitere Vorteile von systemd:

• systemd überwacht, ob der Prozess abgestürzt ist und startet ihn ggfs. neu
• jedes beliebige Programm (auch Scripte) können daemonisiert werden.

Man muss eigentlich "nur" eine korrekte Unit-Datei erstellen.

Zum Thema Ein-/Ausgabe:

• die einfachste Methode sind Dateien
• syslog oder das modernere Journalling ist am einfachsten (f. Ausgaben)