5
Überwachen ob ein Skript läuft - ausgeführt als geplante Task unter Windows Server 2008
Hallo,
ich muss prüfen, ob eine ein Batch-Skript (cmd.exe) noch läuft.
Das Problem dabei ist, dass ich in einem Batch-Skript (skript1) ein Skript (skript2) eines SW-Herstellers aufrufe, welches sofort mit ERRORLEVEL=0 zurück kommt. Dieser ERRORLEVEL bezieht sich aber nur darauf, dass ein weitetres Skript (skript3) erfolgreich gestartet wurde
Ich muss nun in skript1 abwarten, dass skript3 beendet ist, bevor ich die Verarbeitung fortsetzten kann. (OK, eigentlich startet skript3 noch ein skript4 bevor es sich beendet und ich muss auf das Ende von skript4 warten aber ist hier nicht das Problem)
Bisher (Windows Server 2003) habe ich das ganze in der Form gelöst, dass ich über "tasklist" und den eindeutigen Fenstertitel des skript3 die ProzessID ermittelt habe und in bestimmten Intervallen diese PID abgefragt habe. Ist die PID nicht mehr vorhanden konnte ich meine Verarbeitung fortsetzen.
Nun habe ich das ganze nach Windows Server 2008 portiert und habe folgendes festgestellt.
Starte ich mein Skript per Doppelklick oder per Aufruf aus einer cmd funktioniert alles wie gewünscht.
Nutze ich hingegen eine geplante Task (bzw. at aus der cmd) steht mit "tasklist" der Fenstertitel nicht zur Verfügung.
Hat jemand eine Idee, wie ich das Problem lösen kann?
Die Skripte 2 und 3 kann bzw. will ich eigentlich nicht anpassen, da es sich um Skripte eines SW-Herstellers handelt und ich diese aus Support- und Wartungsgesichtspunkten nur ungerne anfasse.
Der Softwarehersteller weiss grundsätzlich darum, dass die Jobsteuerung an der Stelle nicht optimal gelöst ist, hat aber aktuell kein Interesse dies kurzfristig zu verändern.
Es muss sich also um eine Lösung handeln, die über skript1 abzubilden ist.
Falls jemandem nicht ganz klar ist, wass ich meine. Hier ist ein kleines Beispiel in 2 Skripten:
MeinTest.bat:
MeinTest2.bat:
Starte ich "MeinTest.bat" direkt enthält die Datei "find.tasklist.log" eine Zeile und die Datei "all.tasklist.log" die gesamte Tasklist.
Starte ich "MeinTest.bat" als geplante Task über "at" ist die Datei "find.tasklist.log" leer und die Datei "all.tasklist.log" wieder die gesamte Tasklist, aus der sich dann "orakeln" lässt, dass ein "cmd.exe" Prozess zu "MeinTest2.bat" gehört.
Gruß icsAT
ich muss prüfen, ob eine ein Batch-Skript (cmd.exe) noch läuft.
Das Problem dabei ist, dass ich in einem Batch-Skript (skript1) ein Skript (skript2) eines SW-Herstellers aufrufe, welches sofort mit ERRORLEVEL=0 zurück kommt. Dieser ERRORLEVEL bezieht sich aber nur darauf, dass ein weitetres Skript (skript3) erfolgreich gestartet wurde
Ich muss nun in skript1 abwarten, dass skript3 beendet ist, bevor ich die Verarbeitung fortsetzten kann. (OK, eigentlich startet skript3 noch ein skript4 bevor es sich beendet und ich muss auf das Ende von skript4 warten aber ist hier nicht das Problem)
Bisher (Windows Server 2003) habe ich das ganze in der Form gelöst, dass ich über "tasklist" und den eindeutigen Fenstertitel des skript3 die ProzessID ermittelt habe und in bestimmten Intervallen diese PID abgefragt habe. Ist die PID nicht mehr vorhanden konnte ich meine Verarbeitung fortsetzen.
Nun habe ich das ganze nach Windows Server 2008 portiert und habe folgendes festgestellt.
Starte ich mein Skript per Doppelklick oder per Aufruf aus einer cmd funktioniert alles wie gewünscht.
Nutze ich hingegen eine geplante Task (bzw. at aus der cmd) steht mit "tasklist" der Fenstertitel nicht zur Verfügung.
Hat jemand eine Idee, wie ich das Problem lösen kann?
Die Skripte 2 und 3 kann bzw. will ich eigentlich nicht anpassen, da es sich um Skripte eines SW-Herstellers handelt und ich diese aus Support- und Wartungsgesichtspunkten nur ungerne anfasse.
Der Softwarehersteller weiss grundsätzlich darum, dass die Jobsteuerung an der Stelle nicht optimal gelöst ist, hat aber aktuell kein Interesse dies kurzfristig zu verändern.
Es muss sich also um eine Lösung handeln, die über skript1 abzubilden ist.
Falls jemandem nicht ganz klar ist, wass ich meine. Hier ist ein kleines Beispiel in 2 Skripten:
MeinTest.bat:
start "MeinTest2" "C:\temp\meintest2.bat" MeinTest2.bat:
tasklist /V /FO TABLE|find "MeinTest2" >C:\temp\find.tasklist.log
tasklist /V /FO TABLE >C:\temp\all.tasklist.logStarte ich "MeinTest.bat" direkt enthält die Datei "find.tasklist.log" eine Zeile und die Datei "all.tasklist.log" die gesamte Tasklist.
Starte ich "MeinTest.bat" als geplante Task über "at" ist die Datei "find.tasklist.log" leer und die Datei "all.tasklist.log" wieder die gesamte Tasklist, aus der sich dann "orakeln" lässt, dass ein "cmd.exe" Prozess zu "MeinTest2.bat" gehört.
Gruß icsAT
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 207156
Url: https://administrator.de/forum/ueberwachen-ob-ein-skript-laeuft-ausgefuehrt-als-geplante-task-unter-windows-server-2008-207156.html
Ausgedruckt am: 31.12.2024 um 20:12 Uhr
5 Kommentare
Neuester Kommentar
Hi,
ein möglicher Ansatz (ungetestet) wäre evtl, dass du Abfragst, ob der entsprechende geplante Task gerade aktiv ist und welchen Status er hat.
Grüße
ein möglicher Ansatz (ungetestet) wäre evtl, dass du Abfragst, ob der entsprechende geplante Task gerade aktiv ist und welchen Status er hat.
Grüße
moin,
das Original benennst Du Um.
Dein 1. Script startet normal Das 2. Script und Wartet auf die Meldung "ScripnameFertig"
Somit belässt Du Dein HerstellerScript und hast es nur Umbenannt.
Gruß Phil
Die Skripte 2 und 3 kann bzw. will ich eigentlich nicht anpassen, da es sich um Skripte eines SW-Herstellers handelt und ich diese aus Support- und Wartungsgesichtspunkten nur ungerne anfasse.
dann baue zu dem "auf das zu wartende Script" ein Gleichnamiges Script@echo off
call "D:\auf das zu wartendende Umbenannte Original Script"
waitfor /si ScripnameFertig 1>nulDein 1. Script startet normal Das 2. Script und Wartet auf die Meldung "ScripnameFertig"
@echo off
setlocal
set "LOG=D:\Script 1_Log.txt"
call "D:\Script 1.cmd" || >&2 echo FEHLER! Script 3 konnte nicht gestartet werden. && >>"%log%" echo FEHLER! Script 3 konnte nicht gestartet werden. &&exit /b 1
>>"%log%" echo Script 3 wurde gestartet.
echo Script 3 wurde gestartet.
rem Warte auf SriptEnde
waitfor ScripnameFertig
rem hier geht es nachher weiter.Somit belässt Du Dein HerstellerScript und hast es nur Umbenannt.
Gruß Phil
1
Hi certifiedit,
das funktioniert leider nicht oder ich habe dich falsch verstanden.
Mein Skript1 läuft als geplante Task. Wenn ich die Task abfragen würde wäre sie natürlich da und aktiv. Ich muss aber wissen was mit skript3 ist.
Gruß icsAT
das funktioniert leider nicht oder ich habe dich falsch verstanden.
Mein Skript1 läuft als geplante Task. Wenn ich die Task abfragen würde wäre sie natürlich da und aktiv. Ich muss aber wissen was mit skript3 ist.
Gruß icsAT
Hey Phil,
danke für den Ansatz. Waitfor war mir bisher nicht bekannt.
Liegt vermutlich daran, das mir die 2008 er Kiste gerade erst vor die Nase gestellt wurde
Werde mit dem Ansatz später mal etwas testen.
Gruß icsAT
danke für den Ansatz. Waitfor war mir bisher nicht bekannt.
Liegt vermutlich daran, das mir die 2008 er Kiste gerade erst vor die Nase gestellt wurde
Werde mit dem Ansatz später mal etwas testen.
Gruß icsAT
Moin Moin,
ich habe das Problem zwischenzeitlich gelöst.
Danke noch mal an Phil, dessen Ansatz mich dazu bewegt hat die Dinge noch einmal anders zu betrachten.
Ich hatte mich allerdings doch gegen "WAITFOR" entschieden, da ich auch noch einen 2003er Testserver habe auf dem "WAITFOR" natürlich nicht vorhanden ist und ich ganz gerne auf allen Systemen die gleichen Skripte laufen habe. Ich wollte es dann, angelehnt an Phil's Vorschlag, alternativ mit einer Datei lösen, deren vorhanden sein oder nicht vorhanden sein ich in skript1 abfrage.
Gelöst habe ich es dann aber doch noch wieder anders. Das hat aber eigentlich nichts mehr mit meiner Fragestellung zu tun.
Ich habe mir die Skripte des SW-Herstellers noch einmal genauer angesehen und festgestellt, dass skript3 sehr wohl auf skript4 warten kann, wenn bestimmte Umgebungsvariablen gesetzt sind. Schade, dass mir die Hersteller Hotline das nicht sagen konnte. Weiter habe ich festgestellt, dass skript2 "nur" prüft ob bestimmte Umgebungsvarieblen korrekt gesetzt sind und theoretisch mehrere Instanzen von skript3 startet. (Theoretisch, weil es bei uns immer nur eine ist).
Daher übergehe ich jetzt skript2 und starte skript3 direkt aus skript1 und warte auf dessen Beendigung, welche dank der gesetzten Umgebungsvariablen erst nach Beendigung von skript4 erfolgt.
Das ist zwar nicht im Sinne des Erfinders (Softwareherstellers) aber was solls.
Gruß icsAT
ich habe das Problem zwischenzeitlich gelöst.
Danke noch mal an Phil, dessen Ansatz mich dazu bewegt hat die Dinge noch einmal anders zu betrachten.
Ich hatte mich allerdings doch gegen "WAITFOR" entschieden, da ich auch noch einen 2003er Testserver habe auf dem "WAITFOR" natürlich nicht vorhanden ist und ich ganz gerne auf allen Systemen die gleichen Skripte laufen habe. Ich wollte es dann, angelehnt an Phil's Vorschlag, alternativ mit einer Datei lösen, deren vorhanden sein oder nicht vorhanden sein ich in skript1 abfrage.
Gelöst habe ich es dann aber doch noch wieder anders. Das hat aber eigentlich nichts mehr mit meiner Fragestellung zu tun.
Ich habe mir die Skripte des SW-Herstellers noch einmal genauer angesehen und festgestellt, dass skript3 sehr wohl auf skript4 warten kann, wenn bestimmte Umgebungsvariablen gesetzt sind. Schade, dass mir die Hersteller Hotline das nicht sagen konnte. Weiter habe ich festgestellt, dass skript2 "nur" prüft ob bestimmte Umgebungsvarieblen korrekt gesetzt sind und theoretisch mehrere Instanzen von skript3 startet. (Theoretisch, weil es bei uns immer nur eine ist).
Daher übergehe ich jetzt skript2 und starte skript3 direkt aus skript1 und warte auf dessen Beendigung, welche dank der gesetzten Umgebungsvariablen erst nach Beendigung von skript4 erfolgt.
Das ist zwar nicht im Sinne des Erfinders (Softwareherstellers) aber was solls.
Gruß icsAT
