Naprawa nieuruchomionego zadania cron ownCloud: Skonfiguruj niezawodny timer systemd

Otwierasz stronę administracyjną ownCloud i widzisz, że zadania w tle nie były ostatnio uruchamiane lub że zadania związane z czyszczeniem, aktywnością, pamięcią zewnętrzną i innymi zadaniami w kolejce wydają się opóźnione. Częstą reakcją jest edycja cron.phplub dodanie kolejnego wpisu crontab. W aktualnej dokumentacji serwera ownCloud nie jest to najlepszy punkt wyjścia: ownCloud zaleca tryb tła cron i polecenie occ system:cron. Timer systemd może zapewnić warstwę planowania zamiast tradycyjnego crontab na hoście Linux.

Ten przewodnik koncentruje się na pakiecie lub instalacji w stylu bare-metal, gdzie ownCloud znajduje się w ścieżce takiej jak /var/www/owncloud. Jeśli używasz oficjalnego obrazu Docker ownCloud, zatrzymaj się przed utworzeniem timera hosta: ownCloud dokumentuje, że obraz konfiguruje już wewnętrznie cron, kontrolowany przez zmienne takie jak OWNCLOUD_CROND_ENABLEDi OWNCLOUD_CROND_SCHEDULE. Zobacz aktualną dokumentację zadań w tle ownCloud .

Co jest weryfikowane, co zależy od serwera, a co nadal wymaga sprawdzenia

• Zweryfikowano: ownCloud zaleca użycie Crona zamiast AJAX w celu zapewnienia niezawodnego wykonywania zadań w tle i dokumentuje je occ system:cronjako polecenie wykonywania zadań w tle oczekujących w kolejce.
• Zależy to od instalacji: katalogu ownCloud, pliku binarnego PHP, konta na serwerze WWW, środowiska PHP oraz tego, czy uruchamiasz instalację pakietu, kontenera, urządzenia czy wdrożenia niestandardowego.
• Nie da się tego ustalić z ogólnego przewodnika: dlaczego Twoje bieżące zadanie się nie powiodło. Może to być problem z harmonogramem, ale może to być również problem z uprawnieniami, nieprawidłową ścieżką, inną konfiguracją PHP CLI, łącznością z bazą danych, blokowaniem plików lub niepowodzeniem zadania w tle na poziomie aplikacji.

Działanie: nie twórz timera, dopóki dokładne polecenie ownCloud nie zostanie wykonane ręcznie na tym samym koncie, którego będzie używał timer.

Krok 1: Potwierdź tryb Cron i przetestuj ownCloud ręcznie

W przypadku typowej instalacji w stylu Apache/Debian, użytkownik sieciowy to www-data. Zastąp zarówno użytkownika, jak i ścieżkę, jeśli Twoje środowisko jest inne.

sudo -u www-data /var/www/owncloud/occ background:cron
sudo -u www-data /var/www/owncloud/occ system:cron

Pierwsze polecenie wybiera tryb zadań w tle crona ownCloud. Drugie faktycznie uruchamia zadania w tle w kolejce. Dokumentacja polecenia occ ownCloud podaje, że system:cronjest ono przeznaczone do zaplanowanego wykonywania i że wyjście postępu nie powinno być włączane w harmonogramie nieinteraktywnym.

Powszechne nieporozumienie: „tryb cron” w ownCloud nie oznacza, że ​​musisz używać crondemona w konkretnym przypadku. Oznacza to, że ownCloud oczekuje, że zewnętrzny harmonogram wywoła swój program uruchamiający zadania w tle. Takim harmonogramem może być timer systemd.

Działanie: jeśli polecenie ręczne się nie powiedzie, najpierw napraw ten błąd. Timer będzie powtarzał ten sam błąd tylko zgodnie z harmonogramem.

Krok 2: Znajdź prawidłowe ścieżki PHP i ownCloud

Niektóre instalacje są occbezpośrednio wykonywalne; inne są bardziej przewidywalne po wywołaniu za pomocą pliku binarnego PHP CLI. Potwierdź oba:

command -v php
readlink -f /var/www/owncloud/occ
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ system:cron

Dokumentacja ownCloud wyraźnie ostrzega, że ​​zaplanowane zadania muszą znaleźć PHP i dlatego w przykładach cron wyświetla pełne ścieżki. Ma to równie duże znaczenie w przypadku systemd, ponieważ usługi otrzymują kontrolowane środowisko, a nie interaktywne środowisko powłoki.

Działanie: w pozostałych przykładach zastąp /usr/bin/php, /var/www/owncloud, i www-datawartościami, które działały na Twoim hoście.

Krok 3: Utwórz usługę systemd typu oneshot

Tworzyć /etc/systemd/system/owncloud-cron.service:

[Unit]
Description=Run ownCloud background jobs
After=network.target

[Service]
Type=oneshot
User=www-data
Group=www-data
WorkingDirectory=/var/www/owncloud
ExecStart=/usr/bin/php -f /var/www/owncloud/occ system:cron

Zazwyczaj nie potrzebujesz [Install]sekcji dla usługi, ponieważ aktywuje ją timer. Zachowanie usługi jako takiej Type=oneshotułatwia również interpretację jej cyklu życia: usługa uruchamia się, raz uruchamia polecenie, kończy działanie i ponownie staje się nieaktywna.

Częste nieporozumienie: nieaktywna usługa jednorazowa nie jest automatycznie zepsuta. Po pomyślnym uruchomieniu usługa jednorazowa RemainAfterExit=yeszazwyczaj staje się nieaktywna.

Działanie: oceniaj sukces na podstawie kodu wyjścia i dziennika, a nie oczekując, że usługa pozostanie „działająca”.

Krok 4: Utwórz timer systemd

Tworzyć /etc/systemd/system/owncloud-cron.timer:

[Unit]
Description=Run ownCloud background jobs every 15 minutes

[Timer]
OnCalendar=*:0/15
Persistent=true
Unit=owncloud-cron.service

[Install]
WantedBy=timers.target

Dokumentacja hosta cron ownCloud zaleca harmonogram 15-minutowy. Powyższy timer jest zgodny z tym rytmem. Persistent=trueJest on przydatny z OnCalendartimerem, ponieważ Systemd może wywołać pominiętą aktywację kalendarza po ponownym udostępnieniu maszyny. Dokładne zachowanie nadal zależy od wersji Systemd i czasu wyłączenia maszyny.

Działanie: jeśli celowo potrzebujesz innego interwału, zmień go celowo, zamiast kopiować wartość z innego serwera. Częstsze wykonywanie może zwiększyć obciążenie w tle; rzadsze wykonywanie może opóźnić pracę w kolejce.

Krok 5: Przeładuj systemd i włącz timer

sudo systemctl daemon-reload
sudo systemctl enable --now owncloud-cron.timer
sudo systemctl status owncloud-cron.timer

daemon-reloadpowoduje, że systemd ponownie odczytuje pliki jednostek. enable --nowWłącza licznik czasu dla przyszłych uruchomień i uruchamia go natychmiast.

Działanie: jeśli licznik czasu nie jest aktywny, sprawdź to systemctl status owncloud-cron.timerprzed ponowną zmianą konfiguracji ownCloud.

Krok 6: Sprawdź następny i poprzedni przebieg timera

systemctl list-timers owncloud-cron.timer
systemctl list-timers --all | grep owncloud-cron

list-timersTo najszybszy sposób na potwierdzenie, że systemd zaplanował kolejną aktywację i sprawdzenie, kiedy timer ostatnio zadziałał. To odróżnia sytuację „timer nigdy nie został uruchomiony” od sytuacji „timer został uruchomiony, ale ownCloud uległ awarii w usłudze”.

Działanie: jeśli brakuje opcji NEXT lub timer nie jest wymieniony, sprawdź ponownie nazwę pliku timera, [Install]sekcję oraz to, czy urządzenie zostało włączone.

Krok 7: Sprawdź dziennik serwisowy, a nie tylko licznik czasu

Systemd rejestruje dane wyjściowe usługi w dzienniku, chyba że celowo przekierujesz je gdzie indziej. Oficjalna dokumentacja journalctl opisuje filtrowanie wpisów w dzienniku według jednostki systemd.

sudo journalctl -u owncloud-cron.service --since today
sudo journalctl -u owncloud-cron.service -n 100 --no-pager

Częste nieporozumienie: „Timer jest aktywny, więc polecenie cron ownCloud działa”. Aktywny timer jedynie dowodzi, że harmonogram oczekuje na uruchomienie. Nadal potrzebne jest pomyślne wywołanie usługi.

Działanie: poszukaj błędów PHP, komunikatów o odmowie uprawnień, brakujących plików, błędów bazy danych lub kodu wyjścia innego niż zero. Napraw pierwszy konkretny błąd, zamiast wielokrotnie restartować licznik.

Krok 8: Uruchom jedno uruchomienie na żądanie i zweryfikuj ownCloud

Nie musisz czekać 15 minut na test końcowy:

sudo systemctl start owncloud-cron.service
sudo systemctl status owncloud-cron.service
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ status

Po pomyślnym uruchomieniu jednorazowego polecenia, systemctl statususługa może zostać uznana za nieaktywną, wyświetlając jednocześnie komunikat „ status=0/SUCCESS. Ważnym rezultatem jest pomyślne zakończenie polecenia.

Działanie: po pomyślnym teście ręcznej obsługi należy odczekać co najmniej jedną aktywację zaplanowanego timera i potwierdzić, czy nowy wpis w dzienniku pojawi się bez ręcznej interwencji.

Jeśli nadal nie działa: rozwiąż problem na podstawie warstwy

Uwaga dotycząca pliku cron.php i starszych przewodników

Starsze instrukcje dotyczące ownCloud często wywołują cron.phpbezpośrednio. Aktualna dokumentacja ownCloud zaleca migrację occ system:cron, a informacje o wydaniu ownCloud wyjaśniają migrację ze starszego, bezpośredniego cron.phppodejścia. Zobacz informacje o wydaniu serwera ownCloud .

Działanie: jeśli odziedziczyłeś stary plik crontab lub jednostkę systemd, która uruchamia cron.php, porównaj go z dokumentacją zainstalowanej wersji ownCloud przed jego zachowaniem.

Ostateczna lista kontrolna weryfikacji

• ownCloud jest skonfigurowany do wykonywania zadań Cron w tle.
• Dokładne occ system:cronpolecenie zostanie wykonane na zamierzonym koncie serwera WWW.
• owncloud-cron.timerjest włączony i active (waiting).
• systemctl list-timerspokazuje poprzednią i następną aktywację po upływie określonego czasu.
• journalctl -u owncloud-cron.servicepokazuje pomyślne zaplanowane wykonania.
• Konfiguracja ta nie duplikuje crona już dostarczonego przez oficjalny obraz ownCloud Docker lub inny harmonogram.

Jeśli wszystkie te sprawdzenia zakończą się sukcesem, potwierdziłeś coś więcej niż tylko „istnienie licznika”: pokazałeś, że systemd planuje zadanie, wywołuje ownCloud na właściwym koncie i pomyślnie kończy działanie faktycznego zadania w tle.