Prozess soll bevor er gekillt wird ein Signal senden

Kann ein Prozess der gekillt wird durch den Taskmanager oder über die Konsole mit taskkill beim killen ein Signal senden ? wenn ja wie geht das ?

Je nachdem wie sicher Du es haben willst gibt es unterschiedliche Ansätze.

Ich würde einen zweiten Prozess benutzen
der bei Bedarf auch die wichtigen Daten spiegelt
die in Prozess2 gerade verarbeitet/gespeichert/bearbeitet.. werden.

Wenn nun Prozess1 abgeschossen wird,
kann Prozess2 das feststellen und die Daten sichern..
------------------------------------------------------
Sollte es bei Dir um die Vorbeugung vor Datenverlust gehen,
ist ein Journal sehr von Vorteil
------------------------------------------------------
Soll das ganze noch sicherer werden würde ich auf Treiberebene
obiges anwenden und/oder mit einem zweiten Rechner arbeiten
(Im Flugverkehr sind solche Computer die sich gegenseitig absichern Standard)

Es geht um einen Serverprozess und irgendjemand beendet diesen. Es ist ein zustandsloser Server daher keine Daten gehen verloren. Habe auch an einen 2ten Prozess nachgedacht der regelmässig in einer endlosschleife konntrolliert ob der Serverprozess down ist und ihn dann startet. Nur das regelmässige kontrollieren kostet CPU-Verarbeitungszeit wollte daher mal fragen ob es ein asynchrone Möglichkeit gibt sprich wenn der Prozess beendet wird das er eventuell ein Signal sendet.Der Idealfall ist halt der Serverprozess läuft und der kontrolierende Prozess schläft, wenn nun der Serverprozess gekillt wird sendet er vorher ein Signal sodass der schlafende Prozess aufwacht den Serverprozess wieder startet und sich dannach wieder schlafen legt

p.s ist ein windowsserver

Kenne mich mit MS Servern nicht aus $:\$

Wie kritisch ist denn die Reaktionszeit ?

Du kannst mit WaitForSingleObject darauf warten, dass der Prozess beendet wird. Das hat den Vorteil, dass der Server davon nichts mit bekommt und es kostet keine CPU.

hustbaer

@AmonAmarth
Wenn der Prozess als Windows-Service läuft (was nicht interaktive Services i.A. sollten), dann gibt es die Möglichkeit einfach beim Service einzutragen was passieren soll wenn das Service unerwartet terminiert.
Dazu machst du einfach die Service-Management Konsole auf (oder rechtsklickst auf Computer->Manage), doppelklickst das entsprechende Service, und gehst dort auf den Reiter "Recovery".

Dort kannst du Aktionen für den 1. Fehler, 2. Fehler und alle folgenden Fehler konfigurieren. Ebenso kannst du einstellen wann der Fehler-Zähler resettet wird.

Default ist bei den meisten Services für alle Aktionen "Take No Action". Auswählen kann man dann noch "Restart the Service", "Run a Program" und "Restart Computer".

Für Dinge wie unseren SQL Server bzw. unsere Applikations-Server stellt ich da immer ein 1. Fehler = "Restart the Service", 2. Fehler = "Restart the Service" und weitere Fehler = "Restart Computer", und Zähler zurücksetzen nach 3 Tagen.

Für Services die nicht gleich hunderte Euro pro Ausfallssekunde kosten und im Allgemeinen sehr stabil laufen ist das mMn. vollkommen ausreichend.

Wenn man eine Benachrichtigung bekommen möchte wenn ein Service auf Grund eines Fehlers restartet wird, kann man ein Batchfile über "Run a Program" starten lassen, das erstmal das Servie restartet ("net start ServiceName"), und dann eine Mail schickt oder was auch immer.

Blöd wird es nur wenn ein Service sich so weghängt, dass der Prozess noch läuft, es aber nicht mehr reagiert. Das bekommt der Service-Control-Manager dann nicht mit, und dann macht der natürlich auch nix.

Eine Zeitlang hatten wir ein solches Problem mit dem SQL Server Agent - der ist manchmal in einen Zustand gekommen wo er sämtliche Jobs mit einem wirren .NET Framework Fehler abgebrochen hat. Backup etc. ist dann alles gestanden. Fehlerbenachrichtigungen vom Job sind keine gekommen, da ja nicht der Backup-Teil des Jobs fehlgeschlagen ist, sondern schon weit vorher ein Fehler passiert war der die Ausführung des Jobs überhaupt verhindert hat.

Wenn man mit sowas zu kämpfen hat, dann hilft mMn. wirklich nur mehr aktive Überwachung. Also irgendein Überwachungs-Service, idealerweise auf einer eigenen Box, das immer mal Anfragen an das zu überwachende Service schickt, und auch checkt ob eine korrekte Antwort zurückkommt. Und um das ganze abzurunden lässt man nicht nur ein Überwachungs-Service laufen, sondern mindestens zwei, die jeder das eigentliche "Nutz-Service" überwachen, sowie das jeweils andere Überwachungs-Service. Eines der beiden Überwachungs-Services kann man dann wenns anders nicht geht auf der selben Box laufen lassen wie das "Nutz-Service", ich würde aber eher 3 getrennte Boxen nehmen.

Was CPU-Zeit angeht... wenn die Überwachungs-Services nicht gerade alle 100 msec einen Test-Request an die überwachten Services schicken, würde ich mir da keinen Kopf machen.
Ein paar Pakete über's Netzwerk und ein paar tausend Zeilen ausgeführten Code um das Test-Request zu beantworten... das kann man sich gut und gerne alle paar Sekunden leisten.

ps: Die Service-Manager Sache funktioniert natürlich auch nur, wenn das Service unplanmässig beendet wird. D.h. wenn es Schlingel geben sollte die dem Service einen regulären Stop-Befehl senden, dann unternimmt der Service-Control-Manager natürlich nichts. Was passiert wenn das Service sich ohne Stop-Befehl beendet, dies aber vorher brav dem Service-Control-Manager meldet, das weiss ich nicht. Müsste man ausprobieren.

Jochen Kalmbach

Falls Du wissen willst, wer Dich beendet, so kannst Du ab Win7/W2k8 mit gflags dies setzen (silent process exit). Dort wird dann ein Dump erzeugt; sowohl von Deinem als auch dem Prozess, der dich beendet...
http://msdn.microsoft.com/en-us/library/windows/hardware/jj602791