Supportnet / Forum / BS-Sonstige
Batch-File Abbruch, zeitliche Begrenzung
Frage
Bezug auf Thread: https://supportnet.de/discussion/listmessages.asp?AutoID=165275
Hallo Marc,
jetzt habe ich doch doch noch ein kleines Problem.
Das Programm fdfmngr.exe wird von unseren Systemadministratoren von Zeit zu Zeit aktualisiert.
Die Verteilung auf die Stationen geschieht automatisch.
Nach dem Aufruf von fdfmngr.exe erkennt dieser selber, dass er nicht mehr aktuell ist und holt sich die aktuelle Version vom Server. Während des Aktualisierungsvorgangs darf der laufende Prozess fdfmngr.exe jedoch nicht unterbrochen werden, sonst wird das Programm fdfmngr.exe zerstört.
Wenn also gerade während des Aktualisierungsvorgangs die Zeit von sleep.exe ablaeuft und der Killer zuschlägt werden Teile des fdfmanagers zerstoert und dieser unbrauchbar gemacht.
Kennst Du eine Möglichkeit, das gestartete Script zu beenden also sozusagen die Bombe zu entschärfen, wenn ein Sonderfall eintritt, wie in meinem Fall der Aktualisierungsvorgang ?
Antwort 1 von Undertaker
Hi,
ups, Dein letztes Posting im vorherigen Thread hatte ich garnicht mehr gelesen, sorry!
Und ja, die Addy ist richtig.
Wenn sich fdfmngr.exe aktuallisiert, macht es das über das Netzwerk - es wird also wahrscheinlich in fport (www.foundstone.com -> Resources -> Free Tools -> Intrusion Detection Tools -> Fport v2.0 -> Download this Tool Now -> Download Now) angezeigt.
Man könnte nach Ablauf der eingestellten Zeit nun die Ausgabe von fport auswerten und, wenn fdfmngr.exe Ports offen hat, eine gewisse Zeit warten, die das Programm gewöhnlich benötigt um sich zu aktuallisieren. Danach würde erneut mit fport geprüft. Was allerdings vorher bekann sein müßte wäre der Zustand, wenn sich das Programm aufgehängt hat. Nicht, das da eine Verbindung bestehen bleibt und deshalb das Programm garnicht mehr beendet wird...
Ein anderer Ansatz wäre vielleicht, mit pslist aus den PS-Tools den Prozess in Intervallen zu prüfen und erst dann zu beenden, wenn sich beispielsweise die "Elapsed Time" nicht mehr ändert - vorausgesetzt, die "Elapsed Time" bleibt stehen, wenn sich der Prozess aufhängt...
Aber ohne genaue Analyse kann ich da auch nur raten...
Gruß
Undertaker
ups, Dein letztes Posting im vorherigen Thread hatte ich garnicht mehr gelesen, sorry!
Und ja, die Addy ist richtig.
Wenn sich fdfmngr.exe aktuallisiert, macht es das über das Netzwerk - es wird also wahrscheinlich in fport (www.foundstone.com -> Resources -> Free Tools -> Intrusion Detection Tools -> Fport v2.0 -> Download this Tool Now -> Download Now) angezeigt.
Man könnte nach Ablauf der eingestellten Zeit nun die Ausgabe von fport auswerten und, wenn fdfmngr.exe Ports offen hat, eine gewisse Zeit warten, die das Programm gewöhnlich benötigt um sich zu aktuallisieren. Danach würde erneut mit fport geprüft. Was allerdings vorher bekann sein müßte wäre der Zustand, wenn sich das Programm aufgehängt hat. Nicht, das da eine Verbindung bestehen bleibt und deshalb das Programm garnicht mehr beendet wird...
Ein anderer Ansatz wäre vielleicht, mit pslist aus den PS-Tools den Prozess in Intervallen zu prüfen und erst dann zu beenden, wenn sich beispielsweise die "Elapsed Time" nicht mehr ändert - vorausgesetzt, die "Elapsed Time" bleibt stehen, wenn sich der Prozess aufhängt...
Aber ohne genaue Analyse kann ich da auch nur raten...
Gruß
Undertaker
Antwort 2 von robbie17
ich weiß zwar nicht worum es geht
aber ich würde zuerst laden
und danach überschreiben
aber ich würde zuerst laden
und danach überschreiben
Antwort 3 von Undertaker
Hi,
@robbie17
>> ich weiß zwar nicht worum es geht
Dann lese doch bitte den in der Frage referenzierten Thread und überdenke Deine Antwort. Danke.
Gruß
Undertaker
@robbie17
>> ich weiß zwar nicht worum es geht
Dann lese doch bitte den in der Frage referenzierten Thread und überdenke Deine Antwort. Danke.
Gruß
Undertaker
Antwort 4 von robbie17
@undertaker
den thread hatte ich schon gelesen
enthält aber auch keine genaueren angaben darüber
wie dieser aktualisierungsvorgang abläuft
da google zum namen nix ausspuckt
wird es wohl eine eigenentwicklung sein
für mich hört sich das so an
daß sich hier ein programm selbst überschreibt
während es die daten dafür noch über ein netzwerk lädt
das wäre fatal - aber vielleicht hab ichs falsch verstanden
den thread hatte ich schon gelesen
enthält aber auch keine genaueren angaben darüber
wie dieser aktualisierungsvorgang abläuft
da google zum namen nix ausspuckt
wird es wohl eine eigenentwicklung sein
für mich hört sich das so an
daß sich hier ein programm selbst überschreibt
während es die daten dafür noch über ein netzwerk lädt
das wäre fatal - aber vielleicht hab ichs falsch verstanden
Antwort 5 von Undertaker
Hi,
@robbie17
>> Für mich hört sich das so an
>> daß sich hier ein programm selbst überschreibt
>> während es die daten dafür noch über ein netzwerk lädt
>> aber ich würde zuerst laden
>> und danach überschreiben
nun ist mir auch Deine erste Antwort verständlich...
Juergen (oder Yul) schrieb ja bereits, das die Administratoren noch an dem Programm fdfmngr.exe modifizieren. Deshalb wird es sich höchstwahrscheinlich um eine Eigenentwicklung handeln.
Außerdem schreibt er von "unsere System-Administratoren", weshalb ich davon ausgehe, das er selbst nicht zur Gruppe der Administratoren gehört und somit wahrscheinlich auch keinen Einfluß auf die Funktionsweise von fdfmngr.exe hat.
Das Problem ist nun, das fdfmngr.exe zusätzlich zur primären Aufgabe (was das auch immer sein mag) ein Update seiner selbst (wie das auch immer gelöst wurde) ausführt.
Nun ist es so, das fdfmngr.exe anscheinend zuerst, aber eben nicht immer, das Update ausführt und sich im weiteren Programmablauf u.U. aufhängt. Im Fall des Updates wird der Prozess während des Updates vom Script gekillt, wodurch fdfmngr.exe nicht mehr funktionstüchtig ist.
Bei dieser Funktionsweise reicht natürlich das ursprüngliche Script nicht. Es gilt also eine Lösung zu finden, mit der festgestellt werden kann, ob fdfmngr.exe noch aktiv (z.B. Netzwerkverbindungen, Prozesseigenschaften etc.) ist oder sich bereits aufgehängt hat und dann entsprechend darauf zu reagieren.
Gruß
Undertaker
@robbie17
>> Für mich hört sich das so an
>> daß sich hier ein programm selbst überschreibt
>> während es die daten dafür noch über ein netzwerk lädt
>> aber ich würde zuerst laden
>> und danach überschreiben
nun ist mir auch Deine erste Antwort verständlich...
Juergen (oder Yul) schrieb ja bereits, das die Administratoren noch an dem Programm fdfmngr.exe modifizieren. Deshalb wird es sich höchstwahrscheinlich um eine Eigenentwicklung handeln.
Außerdem schreibt er von "unsere System-Administratoren", weshalb ich davon ausgehe, das er selbst nicht zur Gruppe der Administratoren gehört und somit wahrscheinlich auch keinen Einfluß auf die Funktionsweise von fdfmngr.exe hat.
Das Problem ist nun, das fdfmngr.exe zusätzlich zur primären Aufgabe (was das auch immer sein mag) ein Update seiner selbst (wie das auch immer gelöst wurde) ausführt.
Nun ist es so, das fdfmngr.exe anscheinend zuerst, aber eben nicht immer, das Update ausführt und sich im weiteren Programmablauf u.U. aufhängt. Im Fall des Updates wird der Prozess während des Updates vom Script gekillt, wodurch fdfmngr.exe nicht mehr funktionstüchtig ist.
Bei dieser Funktionsweise reicht natürlich das ursprüngliche Script nicht. Es gilt also eine Lösung zu finden, mit der festgestellt werden kann, ob fdfmngr.exe noch aktiv (z.B. Netzwerkverbindungen, Prozesseigenschaften etc.) ist oder sich bereits aufgehängt hat und dann entsprechend darauf zu reagieren.
Gruß
Undertaker
Antwort 6 von robbie17
@undertaker
daß meine antworten manchmal nicht verständlich sind
ist ein problem das meinen entwicklern bekannt ist
ob es ein update geben wird
das dieses problem behebt
ist noch ungewiß
falls ja wird dies allerdings erst vollständig
in ein temporäres verzeichnis geladen werden
bevor eine aktualisierung erfolgt :)
daß meine antworten manchmal nicht verständlich sind
ist ein problem das meinen entwicklern bekannt ist
ob es ein update geben wird
das dieses problem behebt
ist noch ungewiß
falls ja wird dies allerdings erst vollständig
in ein temporäres verzeichnis geladen werden
bevor eine aktualisierung erfolgt :)
Antwort 7 von Juergenn
Hallo Undertaker,
ja genau, du hast alles noch einmal perfekt zusammengefasst. Der FDF-Manager ist eine Eigenentwicklung einer externen Firma.
Ich habe gerade mit einem unserer IT-ler gesprochen. Der sagt dass der FDF-Manager, der lokal auf der Platte liegt nach dem Aufruf selbständig erkennt, dass er nicht mehr aktuell ist. Er gibt dann einen Rückgabewert zurueck, ruft den gleichnamigen FDF-Manager auf dem Server auf und aktualisiert sich dann.
Wenn genau zu diesem Zeitpunkt der Killer zuschlaegt, passiert das Disaster.
Mit den PS-Tools kann ich beobachten, dass sich beim zweiten Aufruf des fdf-managers die PID aendert.
Aber warte mal. Das koennte doch eigentlich schon die Loesung sein. Der Killer darf nur den Prozess Killen, den er beim ersten Aufruf ueberwachen mussste.
Jetzt gibt es aber schon wieder zwei Klippen zu umschiffen. Wie finde ich die PID des ersten Prozesses raus und kann der Killer PIDs killen ohne den Namen des Prozesses zu haben ?
Hast Du vielleicht noch eine Idee ?
Ach ja uebrigens. Wo schreibt das Tool von Foundstone seine Ergebnisse hin ? In das Dos-Fenster offensichtlich nicht. Oder kann man das etwas verkehrt machen ?
Gruss
ja genau, du hast alles noch einmal perfekt zusammengefasst. Der FDF-Manager ist eine Eigenentwicklung einer externen Firma.
Ich habe gerade mit einem unserer IT-ler gesprochen. Der sagt dass der FDF-Manager, der lokal auf der Platte liegt nach dem Aufruf selbständig erkennt, dass er nicht mehr aktuell ist. Er gibt dann einen Rückgabewert zurueck, ruft den gleichnamigen FDF-Manager auf dem Server auf und aktualisiert sich dann.
Wenn genau zu diesem Zeitpunkt der Killer zuschlaegt, passiert das Disaster.
Mit den PS-Tools kann ich beobachten, dass sich beim zweiten Aufruf des fdf-managers die PID aendert.
Aber warte mal. Das koennte doch eigentlich schon die Loesung sein. Der Killer darf nur den Prozess Killen, den er beim ersten Aufruf ueberwachen mussste.
Jetzt gibt es aber schon wieder zwei Klippen zu umschiffen. Wie finde ich die PID des ersten Prozesses raus und kann der Killer PIDs killen ohne den Namen des Prozesses zu haben ?
Hast Du vielleicht noch eine Idee ?
Ach ja uebrigens. Wo schreibt das Tool von Foundstone seine Ergebnisse hin ? In das Dos-Fenster offensichtlich nicht. Oder kann man das etwas verkehrt machen ?
Gruss
Antwort 8 von Undertaker
Hi,
>> Wo schreibt das Tool von Foundstone seine Ergebnisse hin?
Eigentlich schreibt FPORT in den Standard Ausgabekanal CON: (Konsole).
Bei meinem Rechner war es auch schon mal so, das FPORT plötzlich nichts mehr ausgegeben hat. Ich weiß nicht mehr, welches Update/SP ich installiert habe, oder ob ich den IE reparieren lies, aber irgendwann funktionierte die Ausgabe wieder...
>> Wie finde ich die PID des ersten Prozesses raus
Schau Dir das Beispiel an. Zuerst wird das Script gestartet. Danach der Prozess.
Das Script wartet solange in der ersten Schleife, bis der Prozess gefunden wurde. Wenn der Prozess langsam genug ist, kann das Script vielleicht noch eine Wartezeit von 1 Sekunde in die Schleife einfügen, um nicht so viel Prozesszeit werden
>> und kann der Killer PIDs killen ohne den Namen des Prozesses zu haben?
pskill kann Prozesse anhand des Namens oder der PID beenden.
>> Das koennte doch eigentlich schon die Loesung sein.
>> Der Killer darf nur den Prozess Killen,
>> den er beim ersten Aufruf ueberwachen mussste.
Und was ist, wenn sich der FDF-Manager nach dem Update aufhängt?
Ich habe noch zwei Fragen an Dich:
a) Kannst Du bitte mal mit PSLIST testen, ob sich die Estimate Time des Prozesses noch ändert, wenn sich der FDF-Manager aufgehängt hat?
Und b), wie lange dauert es ca., bis sich der FDF-Manager aktualisiert hat?
Sollte die Estimate Time nach dem Aufhängen des Prozesses sich nicht mehr ändern, würde ich vorschlagen das Script so zu schreiben, das in einer kurzen Zeitschleife die PID und Estimate Time geprüft wird. Sollte sich die PID des Prozesses ändern, sollte das Script eine gewisse Zeit warten, in der das Update erfahrungsgemäß abgeschlossen wird. Dannach sollte in die Zeitschleife zurückgesprungen werden. Ist der Prozess nicht mehr vorhanden, endet das Script. Ändert sich die Estimate Time mehrfach nicht mehr, wird erst der Prozess und anschließend das Script beendet.
Ich stelle mir das Script dann wie folgt vor:
Gruß
Undertaker
>> Wo schreibt das Tool von Foundstone seine Ergebnisse hin?
Eigentlich schreibt FPORT in den Standard Ausgabekanal CON: (Konsole).
Bei meinem Rechner war es auch schon mal so, das FPORT plötzlich nichts mehr ausgegeben hat. Ich weiß nicht mehr, welches Update/SP ich installiert habe, oder ob ich den IE reparieren lies, aber irgendwann funktionierte die Ausgabe wieder...
>> Wie finde ich die PID des ersten Prozesses raus
Schau Dir das Beispiel an. Zuerst wird das Script gestartet. Danach der Prozess.
Das Script wartet solange in der ersten Schleife, bis der Prozess gefunden wurde. Wenn der Prozess langsam genug ist, kann das Script vielleicht noch eine Wartezeit von 1 Sekunde in die Schleife einfügen, um nicht so viel Prozesszeit werden
>> und kann der Killer PIDs killen ohne den Namen des Prozesses zu haben?
pskill kann Prozesse anhand des Namens oder der PID beenden.
>> Das koennte doch eigentlich schon die Loesung sein.
>> Der Killer darf nur den Prozess Killen,
>> den er beim ersten Aufruf ueberwachen mussste.
Und was ist, wenn sich der FDF-Manager nach dem Update aufhängt?
Ich habe noch zwei Fragen an Dich:
a) Kannst Du bitte mal mit PSLIST testen, ob sich die Estimate Time des Prozesses noch ändert, wenn sich der FDF-Manager aufgehängt hat?
Und b), wie lange dauert es ca., bis sich der FDF-Manager aktualisiert hat?
Sollte die Estimate Time nach dem Aufhängen des Prozesses sich nicht mehr ändern, würde ich vorschlagen das Script so zu schreiben, das in einer kurzen Zeitschleife die PID und Estimate Time geprüft wird. Sollte sich die PID des Prozesses ändern, sollte das Script eine gewisse Zeit warten, in der das Update erfahrungsgemäß abgeschlossen wird. Dannach sollte in die Zeitschleife zurückgesprungen werden. Ist der Prozess nicht mehr vorhanden, endet das Script. Ändert sich die Estimate Time mehrfach nicht mehr, wird erst der Prozess und anschließend das Script beendet.
Ich stelle mir das Script dann wie folgt vor:
@ECHO OFF
SET PNAME=fdfmngr
SET WAITATUPDATE=20
SET /A COUNT=0
SET /A MAXCOUNT=3
:: PID und Estimate Time erstmals auslesen
:: Das Script kann vor dem Start des FDF-Managers gestartet werden
:: da auf den Prozess gewartet wird
:WAITTOPROCESS
FOR /F "tokens=2,9" %%a in ('pslist ^| findstr "%PNAME%"') do SET PIDFIRST=%%a && SET ETIMEFIRST=%%b
IF (%PIDFIRST%) EQU () GOTO WAITTOPROCESS
:START
:: Zeitschleife - Warte 2 Sekunden
sleep 2
:: PID und Estimate Time auslesen
FOR /F "tokens=2,9" %%a in ('pslist ^| findstr "%PNAME%"') do SET PIDNOW=%%a && SET ETIMENOW=%%b
:: PID hat sich geändert (Update) => Prozess genug Zeit für Update geben
IF (%PIDNOW%) NEQ (%PIDFIRST%) (
SET PIDFIRST=%PIDNOW%
sleep %WAITATUPDATE%
GOTO START
)
:: Estimate Time prüfen
:: Estimate Time muß %MAXCOUNT% mal identisch sein
:: Andernfalls wird %COUNT% zurückgesetzt
IF (%ETIMENOW%) EQU (%ETIMEFIRST%) (
SET /A COUNT=%COUNT%+1
IF %COUNT% EQU %MAXCOUNT% GOTO KILLPROCESS
GOTO START
) ELSE (
SET /A COUNT=0
)
:: Script beenden, wenn Prozess nicht mehr existiert
IF (%ETIMENOW%) EQU () (
GOTO ENDE
)
:: Schleife erneut beginnen
GOTO START
:KILLPROCESS
pslist %PIDNOW%
:ENDEGruß
Undertaker
Antwort 9 von Juergenn
Hallo Undertaker,
danke für die wertvollen Tipps. Das Aufhängen des FDF-Managers kann ich nur schwer simulieren. Mal sehen, ob mir da was einfällt.
Ich bin morgen in Urlaub und kann erst am Freitag wieder weitermachen.
Ich melde mich dann wieder.
Danke erst einmal.
Gruss
Juergen
danke für die wertvollen Tipps. Das Aufhängen des FDF-Managers kann ich nur schwer simulieren. Mal sehen, ob mir da was einfällt.
Ich bin morgen in Urlaub und kann erst am Freitag wieder weitermachen.
Ich melde mich dann wieder.
Danke erst einmal.
Gruss
Juergen
Antwort 10 von Undertaker
Hi,
Jürgen hatte einige Fehler bemerkt, daher poste ich auch hier die Korrektur:
Gruß
Undertaker
Jürgen hatte einige Fehler bemerkt, daher poste ich auch hier die Korrektur:
Gruß
Undertaker
@ECHO ON
SET PNAME=fdfmngr
SET PIDFIRST=0
SET ETIMEFIRST=0
SET WAITATUPDATE=20
SET /A COUNT=0
SET /A MAXCOUNT=3
:: PID und Estimate Time erstmals auslesen
:: Das Script kann vor dem Start des FDF-Managers gestartet werden
:: da auf den Prozess gewartet wird
:WAITTOPROCESS
FOR /F "tokens=2,8" %%a in ('pslist ^| findstr "%PNAME%"') do SET PIDFIRST=%%a && SET ETIMEFIRST=%%b
IF "%PIDFIRST%" EQU "0" sleep 1 && GOTO WAITTOPROCESS
:START
:: Zeitschleife - Warte 2 Sekunden
sleep 2
:: PID und Estimate Time auslesen
SET PIDNOW=0
SET ETIMENOW=0
FOR /F "tokens=2,8" %%a in ('pslist ^| findstr "%PNAME%"') do SET PIDNOW=%%a && SET ETIMENOW=%%b
:: Script beenden, wenn Prozess nicht mehr existiert
IF "%ETIMENOW%" EQU "0" GOTO ENDE
:: PID hat sich geändert (Update) => Prozess genug Zeit für Update geben
IF "%PIDNOW%" NEQ "%PIDFIRST%" (
SET PIDFIRST=%PIDNOW%
sleep %WAITATUPDATE%
GOTO START
)
:: Estimate Time prüfen
:: Estimate Time muß %MAXCOUNT% mal identisch sein
:: Andernfalls wird %COUNT% zurückgesetzt
IF "%ETIMENOW%" EQU "%ETIMEFIRST%" (
SET /A COUNT=%COUNT%+1
IF %COUNT% EQU %MAXCOUNT% GOTO KILLPROCESS
GOTO START
) ELSE (
SET /A COUNT=0
)
:: Schleife erneut beginnen
GOTO START
:KILLPROCESS
pslist %PIDNOW%
:ENDE