Zadania systemowe – rozwiązywanie problemów

Artykuł pomaga administratorowi AMODIT znaleźć przyczynę, gdy zadania systemowe nie działają zgodnie z harmonogramem. Jak usługa wykonuje zadania, opisuje Wykonywanie zadań systemowych.

Zanim zaczniesz diagnozować

• Stan i wyniki zadań są na zakładce Zadania w Ustawieniach systemowych, a szczegóły błędów w Logach systemowych (ikona koła zębatego → Logi systemowe). Jak je czytać: Jak sprawdzić, czy zadania systemowe działają.
• Do diagnostyki potrzebna jest rola administratora systemu, a do sprawdzenia usługi – dostęp do serwera, na którym działa AMODAsynchronousService.
• Zmiana harmonogramu dociera do usługi w ciągu około minuty. Sprawdzaj skutek zmiany po tym czasie.

Objawy

Żadne zadanie się nie wykonuje

Typowe przyczyny

• Usługa AMODAsynchronousService jest zatrzymana albo nie uruchamia się.
• Po aktualizacji AMODIT nie zaktualizowano bazy danych.
• Organizacja nie należy do grupy organizacji, którą obsługuje usługa (instalacje z wieloma organizacjami).

Kroki diagnostyczne

1. Sprawdź na zakładce Zadania, czy wszystkie zadania mają Kolejny start w przeszłości i dawny Ostatni start. Jeśli tak, problem dotyczy usługi, a nie pojedynczego zadania.
2. Sprawdź na serwerze, czy usługa AMODAsynchronousService ma stan Uruchomiono. Jeśli nie, uruchom ją. Gdy nie chce się uruchomić, a log systemowy zawiera błąd ładowania pliku albo zestawu, zobacz Problemy po instalacji usługi AMODITAsynchronousService.
3. Poszukaj w logu systemowym wpisu Wrong DB schema. Usługa nie uruchamia zadań organizacji, której baza nie została zaktualizowana do wersji usługi. Wpis pojawia się raz po starcie usługi. Zaktualizuj bazę w AMODIT Database Admin; usługa wznowi zadania bez ponownego uruchomienia.
4. W instalacji z wieloma organizacjami sprawdź z instalatorem, czy ustawienie grupy serwerów w konfiguracji usługi obejmuje tę organizację.

Jedno zadanie się nie wykonuje

Typowe przyczyny

• Zadanie ma częstotliwość Zatrzymane. Po instalacji zatrzymanych jest m.in. LoadMails, Notifications, UserNotifications i SynchronizeWithAD.
• Zadanie ma częstotliwość Jednorazowo i już się wykonało, więc nie ma kolejnego terminu.
• Pierwszy start po zapisaniu harmonogramu wypada w kolejnej dobie, godzinie albo miesiącu.
• Zadanie wskazuje klasę, której nie ma w AMODIT, np. zadanie AutentiAuthorizationRefresh z listy po instalacji.

Kroki diagnostyczne

1. Włącz przełącznik Pokaż zatrzymane i sprawdź częstotliwość zadania.
2. Sprawdź Kolejny start. Niezaplanowane oznacza zadanie zatrzymane albo jednorazowe, które już się wykonało. Termin w przyszłości oznacza, że zadanie czeka na swój termin.
3. Sprawdź Ostatni start. Gdy jest pusty, choć Kolejny start dawno minął, włącz kolumnę Klasa i porównaj klasę z Katalogiem zadań systemowych. Zadanie z klasą, której nie ma w AMODIT, nie wykonuje się i nie ma wyniku w kolumnie Wynik.

Rozwiązanie

Ustaw właściwą częstotliwość albo klasę i zapisz zadanie. Nie poprawiaj klasy w zadaniu z listy po instalacji, np. AutentiAuthorizationRefresh: aktualizacja bazy przywraca w nim klasę z tej listy. Dodaj zamiast tego nowe zadanie o innej nazwie z właściwą klasą, a zadanie z listy po instalacji zatrzymaj. Żeby zadanie wykonało się w ciągu około dwóch minut (na serwerze innym niż preferowany – po 30 minutach), użyj Wykonaj teraz: Jak dodać i ustawić zadanie systemowe.

Zadanie wykonuje się rzadziej, niż mówi harmonogram

Typowe przyczyny

• Zadanie ma wpisany preferowany serwer, który nie działa. Inny serwer uruchamia wtedy zadanie 30 minut po każdym terminie.
• W polu Preferowany serwer jest nazwa, której nie ma żaden serwer, np. literówka albo kilka nazw. Wszystkie serwery czekają wtedy 30 minut.
• Pojedyncze wykonanie trwa dłużej niż odstęp w harmonogramie, więc kolejne startuje dopiero po zakończeniu poprzedniego.

Kroki diagnostyczne

1. Włącz kolumny Preferowany serwer i (Ostatni wynik) Serwer. Jeśli zadanie wykonuje inny serwer niż preferowany, sprawdź usługę na serwerze preferowanym albo wyczyść pole Preferowany serwer.
2. Porównaj Czas wykonania z odstępem w harmonogramie i poszukaj w logu systemowym wpisów Long running job z nazwą zadania.

Zadanie od dawna ma stan W trakcie

Typowe przyczyny

• Usługa albo serwer przestały działać w trakcie zadania. Zadanie zostało oznaczone jako wykonywane przez ten serwer.
• Zadanie naprawdę trwa długo, np. pierwsze indeksowanie dużej liczby spraw.

Kroki diagnostyczne

1. Sprawdź nazwę serwera w kolumnie Stan i to, czy ten serwer i jego usługa działają.
2. Jeśli serwer działa, przejrzyj log systemowy z ostatnich minut. Wpisy zadania oznaczają, że wciąż pracuje.
3. Ustal, czy poprzednie wykonanie zostało przerwane, czy zadanie nadal trwa. Sam brak nowych wpisów w logu nie potwierdza, że zadanie przestało pracować. Jeśli awaria wynikała z braku zasobów serwera, usuń tę przyczynę przed ponownym uruchomieniem usługi.

Rozwiązanie

Po potwierdzeniu, że poprzednie wykonanie zostało przerwane, uruchom ponownie usługę na serwerze z kolumny Stan. Tylko ten serwer może wznowić zadanie: wykona je przy najbliższym sprawdzeniu harmonogramu (jeśli nie jest serwerem preferowanym – po 30 minutach) i usunie oznaczenie. Ponowne uruchomienie usługi w czasie długiego zadania przerywa jego pracę. Inne serwery tego zadania nie przejmą, a zakładka Zadania nie ma akcji, która usuwa oznaczenie.

Po wznowieniu sprawdź Ostatni start, Ostatni wynik i nowe wpisy w logu systemowym, aby potwierdzić, że zadanie ponownie się wykonuje.

Kiedy eskalować

Gdy serwera z kolumny Stan już nie ma, np. po wymianie maszyny, albo zadanie nie wznawia się po uruchomieniu jego usługi, skontaktuj się z pomocą techniczną AMODIT. Ręczne odblokowanie zadania w bazie wymaga potwierdzenia, że nie wykonuje się ono na żadnym serwerze, i zatrzymania usług obsługujących tę organizację na czas interwencji. Po jej zakończeniu trzeba uruchomić usługi i sprawdzić kolejne wykonanie zadania.

Zadanie ma wynik Błąd

Typowe przyczyny

• Błąd konfiguracji funkcji, którą obsługuje zadanie, np. brak wymaganego parametru albo adresu usługi zewnętrznej.
• Usługa zewnętrzna albo zasób, z którego korzysta zadanie, jest niedostępny.

Kroki diagnostyczne

1. Kliknij Błąd w kolumnie Wynik i przeczytaj treść błędu.
2. Kliknij Przejdź do logów systemowych i przejrzyj wpisy z czasu wykonania zadania.
3. Sprawdź w Katalogu zadań systemowych, jakie parametry sterują zadaniem, i porównaj je z ustawieniami.

Zadanie ma wynik Zakończono, ale nie robi swojej pracy

Typowe przyczyny

• Zadanie samo obsłużyło błąd i zapisało go tylko w logu systemowym, np. błąd logowania do skrzynki pocztowej.
• Funkcja, którą obsługuje zadanie, jest wyłączona parametrem, np. FullTextSearch bez katalogu roboczego albo ProcedureIndexing bez UseExperimentalCaseIndexing.

Kroki diagnostyczne

1. Przejrzyj w Logach systemowych błędy i ostrzeżenia z czasu ostatniego wykonania zadania.
2. Sprawdź w Katalogu zadań systemowych parametry, które włączają funkcję zadania.

Maile nie wychodzą albo nie przychodzą powiadomienia zbiorcze

Typowe przyczyny

• Zadanie Notifications, które wysyła maile z kolejki, jest zatrzymane. Tak jest po instalacji.
• Zadanie UserNotifications jest zatrzymane. AMODIT nie zapisuje wtedy powiadomień zbiorczych, chyba że parametr AlwaysSaveUserNotificatons ma wartość true.
• Wysyłka przez serwer pocztowy kończy się błędem.

Kroki diagnostyczne

1. Włącz Pokaż zatrzymane i sprawdź częstotliwość zadań Notifications i UserNotifications.
2. Sprawdź w Logach systemowych kolejkę maili oczekujących na wysyłkę i błędy wysyłki.
3. Sprawdź konfigurację poczty wychodzącej: Jak działa wysyłanie maili w AMODIT.

Rozwiązanie

Włącz zatrzymane zadanie, ustawiając mu harmonogram. Po włączeniu UserNotifications AMODIT zaczyna zapisywać powiadomienia zbiorcze z opóźnieniem do około 20 minut. Powiadomień z czasu, gdy zadanie było zatrzymane, nie zapisał, więc nie zostaną wysłane.

Reguły okresowe nie działają albo działają za często

Typowe przyczyny

• Zadanie odpowiadające typowi reguły jest zatrzymane albo ma inny harmonogram niż zakładano.
• AMODIT sprawdza reguły godzinowe i dzienne przy każdym wykonaniu ich zadania, a nie raz na godzinę czy dobę. Po instalacji RulePeriodicHourly działa co 3 minuty, a RulePeriodicDaily co 5 minut.
• Reguła nie ma etapu, a parametr ExecuteTimeRulesWithoutStage jest wyłączony.

Kroki diagnostyczne

1. Ustal typ reguły i odpowiadające mu zadanie: Lista typów reguł procesu i opcji ich konfiguracji.
2. Sprawdź częstotliwość i Ostatni start tego zadania na zakładce Zadania.
3. Przejrzyj w Logach systemowych wpisy reguł z czasu ostatniego wykonania zadania.

Rozwiązanie

Ustaw harmonogram zadania tak, żeby odpowiadał oczekiwanej częstotliwości reguł. Zmiana dotyczy wszystkich reguł tego typu we wszystkich procesach: Jak dodać i ustawić zadanie systemowe.