EN
Artykuły / 7.2 Utrzymanie terminala
Utrzymanie terminalaszkic

Aktualizator MT5 i okno UAC: 101 procesów w nocy

14.11.20263 min czytania

W skrócie: 26 października 2026 nocny wsad testów rano zastał komputer z 101 procesami terminala, około 10 GB zajętej pamięci i 97 oknami UAC czekającymi na kliknięcie. Wyszedł nowy build MT5, a terminal, który miał uruchomić test, zamiast tego odpalał aktualizator. Skrypt nie wiedział, że test się nie rozpoczął, i startował kolejny.

Co się stało

Wsad uruchamiał jeden test po drugim: start terminala, czekanie na raport, zamknięcie, następny. Ten schemat zakłada, że start terminala daje test. Po pojawieniu się nowego buildu pierwsze uruchomienie terminala zaczyna od aktualizacji. Aktualizator prosi system o podniesienie uprawnień i czeka na człowieka. Raport nie powstaje, skrypt po limicie czasu przechodzi do kolejnego przebiegu i uruchamia następny proces. Każdy z nich wisi na swoim oknie UAC.

Bez nadzoru nic tego nie zatrzymuje. Rano jest ponad setka procesów i ekran pełen identycznych okien.

Dlaczego to nie jest zwykły błąd skryptu

Przyczyna leży w założeniu o stanie środowiska. Skrypt sprawdzał, czy raport powstał, ale nie czy terminal w ogóle jest gotowy do testu. Aktualizacja buildu to zdarzenie spoza skryptu: producent wypuszcza wersję, a pierwszy start po tym fakcie wygląda inaczej niż każdy poprzedni. Dobrze by było pamiętać o tym, kiedy planuję nocne przebiegi: rano w dniu wydania nowego buildu wsad jest najbardziej narażony.

Zasada, którą przyjąłem: automatyzacja z nadzorem człowieka na początku jest w porządku, bez nadzoru musi sama rozpoznawać stan, w którym nie wolno kontynuować.

Jak się zabezpieczam

  1. Sprawdzenie konta po starcie terminala. Po uruchomieniu testu skrypt weryfikuje, że terminal faktycznie jest zalogowany na konto testowe i działa Tester. Brak = przerwanie wsadu, a nie przejście do następnego przebiegu.
  2. Czyszczenie logów przed startem, żeby wynik poprzedniego przebiegu nie udawał bieżącego.
  3. Plik flagi aktualizacji. Gdy wykryję nowy build, tworzę plik, który blokuje starty testów do czasu ręcznej aktualizacji terminala. Plik znika sam, gdy zmieni się build.
  4. Limit czasu i zabicie własnego procesu. Skrypt kończy tylko proces, który sam uruchomił, nigdy cudzy.
  5. Ochrona wspólna dla wszystkich skryptów Testera, żeby nowy skrypt dostawał ją automatycznie, a nie od zera.

Wystarczyło jedno wywołanie sprawdzające, czy terminal ma poprawną wersję, i jedno sprawdzające konto. Reszta to dyscyplina.

Czego nie robię

  • Nie zamykam masowo wszystkich procesów MT5 w panice. Procesy z kontami, na których coś handluje, muszę zostawić. Zabijam tylko te, które uruchomił wsad.
  • Nie klikam seryjnie “Tak” w każdym oknie UAC. Najpierw ustalam, co je spowodowało.
  • Nie planuję nocnego wsadu bezpośrednio po wyjściu nowego buildu, jeśli terminal testowy nie został wcześniej ręcznie zaktualizowany.

[DO UZUPEŁNIENIA: ile godzin testów przepadło i jak ustaliłeś, że to aktualizator, jeśli chcesz to dopisać]

Checklista

  • Przed nocnym wsadem terminal testowy ma najnowszy build.
  • Skrypt sprawdza po starcie, że działa Tester i konto jest zalogowane.
  • Brak raportu po limicie czasu przerywa wsad, a nie uruchamia kolejnego przebiegu.
  • Skrypt zabija tylko własne procesy.
  • Jest flaga blokująca testy do ręcznej aktualizacji.

Powiązane

Ostrzeżenie: handel CFD i forex wiąże się z wysokim ryzykiem utraty kapitału. Artykuł ma charakter edukacyjny i nie jest rekomendacją inwestycyjną.