Orbiter — Znane błędy i rozwiązania

Błędy instalacji

Błąd: „Run via SSH: php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php" Skrypt po instalacji nie mógł uruchomić się automatycznie. Połącz się przez SSH jako root i uruchom polecenie ręcznie:

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

Błąd: „install-deps failed" Instalacja zależności systemowych zakończyła się niepowodzeniem. Uruchom jako root:

bash /opt/psa/admin/plib/modules/orbiter/scripts/install-all.sh

Sprawdź, czy serwer ma dostęp do internetu oraz czy menedżer pakietów (apt/yum) działa normalnie.

Błąd: „Dockerfile not found" Pliki budowania Docker nie zostały poprawnie skopiowane podczas instalacji. Uruchom ponownie skrypt po instalacji lub przeinstaluj rozszerzenie z menedżera rozszerzeń Plesk.

Błąd: „Default nginx template not found" Brakuje szablonu proxy Nginx. Uruchom ponownie:

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

Błędy budowania obrazu Docker

Budowanie nie powiodło się / „Build failed" w interfejsie Sprawdź logi budowania wyświetlane pod paskiem postępu. Częste przyczyny:

• Brak dostępu do internetu, aby pobrać obrazy bazowe
• Niewystarczające miejsce na dysku (minimum 20 GB zalecane)
• Demon Docker nie działa: systemctl start docker

„docker run failed" / Kontener się nie uruchamia Sprawdź, czy:

1. Docker działa: systemctl status docker
2. Dostępna jest wystarczająca ilość RAM (minimum 2 GB łącznie)
3. Nie ma konfliktów portów: sprawdź w logach port already in use

„Web volume mount failed. Check that the path exists" Ścieżka katalogu głównego dokumentów (document root) domeny nie istnieje lub jest niedostępna. Sprawdź w Plesk, czy ścieżka plików domeny jest poprawna oraz czy katalog istnieje na dysku.

Błędy tworzenia kontenera

„Error creating" / Kontener utknął w stanie „creating" Poprzednia operacja tworzenia mogła pozostawić plik blokady. Sprawdź:

ls /opt/psa/var/modules/orbiter/locks/

Jeśli dla domeny istnieje plik .lock, a żadna operacja nie jest w toku, usuń go:

rm /opt/psa/var/modules/orbiter/locks/<domain>.lock

„Container is delete-locked. Unlock it first, or use force=1" Kontener ma włączoną blokadę przed usunięciem. Przejdź do sekcji Kontener w panelu akcji, przełącz blokadę na Odblokowany, a następnie ponów operację.

„Failed to apply network limit" Nie udało się zastosować limitu sieciowego Docker. Zazwyczaj nie jest to krytyczne — kontener działa, ale bez ograniczenia prędkości sieci. Sprawdź zgodność wersji Docker.

„Quota exceeded" Klient Plesk osiągnął przyznany przez administratora limit kontenerów, RAM lub baz danych. Skontaktuj się z administratorem serwera, aby zwiększyć limit, lub najpierw usuń istniejący kontener.

„Failed to enable nginx PHP mode" Nie udało się skonfigurować Nginx do przekazywania żądań PHP do kontenera. Uruchom:

plesk repair web -y

Błędy MariaDB

„MariaDB is starting, please wait a few seconds..." MariaDB nadal inicjalizuje się wewnątrz kontenera. Odczekaj 10–15 sekund i odśwież. Jeśli problem utrzymuje się powyżej 60 sekund, zrestartuj kontener.

„Dump failed. Check that MariaDB is running" MariaDB nie działa wewnątrz kontenera. Przejdź do panelu Baza danych i kliknij „Uruchom MariaDB" lub zrestartuj cały kontener. Jeśli niepowodzenie pojawia się cyklicznie w logu nocnej kopii zapasowej (/opt/psa/var/modules/orbiter/logs/orbiter.log z wpisem [Cron] FAIL ALL: Dump failed), usługa MariaDB wewnątrz kontenera prawdopodobnie utknęła w stanie FATAL. Sprawdź to poleceniem:

docker exec php-fpm-<domain> supervisorctl status mariadb

Jeśli zgłasza FATAL Exited too quickly, zobacz Stan FATAL MariaDB (Can't initialize timers) poniżej.

Stan FATAL MariaDB (Can't initialize timers) — zbyt niski PidsLimit MariaDB potrzebuje do uruchomienia kilku wewnętrznych wątków (timery, obsługa sygnałów, procesy robocze InnoDB). Jeśli pids.max w cgroup kontenera jest poniżej wymagań MariaDB, mariadbd przerywa działanie natychmiast przy starcie z komunikatem:

Can't initialize timers
[ERROR] Aborting

Supervisord ponawia próbę 3 razy, a następnie oznacza usługę jako FATAL. Kontener pozostaje uruchomiony — martwa jest tylko MariaDB w jego wnętrzu — a nocne kopie zapasowe zawodzą po cichu każdej nocy.

Jak wykryć. Sprawdź limity kontenera:

docker inspect php-fpm-<domain> --format '{{.HostConfig.PidsLimit}}'

Jeśli zwraca 100 lub mniej, a kontener ma włączoną MariaDB, znalazłeś przyczynę.

Jak naprawić. Podnieś limit cgroup na żywo (bez potrzeby ponownego tworzenia) i zrestartuj usługę:

docker update --pids-limit=512 php-fpm-<domain>
docker exec php-fpm-<domain> supervisorctl restart mariadb

Następnie zweryfikuj: docker exec php-fpm-<domain> supervisorctl status mariadb powinno teraz pokazywać RUNNING. Nocna kopia zapasowa wznowi się samoczynnie.

Zapobieganie. Orbiter stosuje minimum dla MariaDB wynoszące 150 PID, gdy silnik jest włączany w momencie tworzenia kontenera, ale kontener utworzony przed tym zabezpieczeniem (lub taki, w którym limit obniżono ręcznie przez okno Limity) może znaleźć się poniżej progu. Po włączeniu + MariaDB upewnij się, że limit PID kontenera nie jest pozostałością po presecie Konserwatywnym (Conservative). Z poziomu interfejsu okno Limity wyszarza teraz wartości PID poniżej 150, gdy MariaDB jest na tej samej witrynie.

MariaDB ulega awarii natychmiast po uruchomieniu kontenera (błąd io_uring) Dotyczy hostów, gdzie io_uring_disabled=2 lub libaio jest niedostępne. Poprawka jest stosowana automatycznie od Orbiter 1.5.4. Jeśli używasz starszej wersji, uruchom:

php /opt/psa/admin/plib/modules/orbiter/scripts/post-install.php

To uzupełnia konfigurację innodb_use_native_aio=0 we wszystkich uruchomionych kontenerach MariaDB.

„MySQL error" podczas tworzenia użytkownika / nadawania uprawnień (grant) Hasło root MariaDB mogło ulec zmianie lub kontener wymaga restartu. Spróbuj zrestartować MariaDB z panelu Baza danych, a następnie ponów operację.

phpMyAdmin „Failed to set session cookie" Występuje po migracji sluga phpMyAdmin, gdy vhost nginx oraz wewnętrzny plik config.inc.php nie są zsynchronizowane. Naprawione w Orbiter 1.5.3. Zaktualizuj do najnowszej wersji lub utwórz ponownie kontener.

Import bazy danych zawodzi z błędem składni Importowany plik SQL może zawierać instrukcje na poziomie systemowym, które zostały odfiltrowane. Orbiter automatycznie usuwa niebezpieczne instrukcje. Jeśli import zawodzi całkowicie, sprawdź, czy plik jest prawidłowym SQL (a nie jednowierszowym plikiem tekstowym) i czy nie jest uszkodzony.

Błędy Nginx / serwera WWW

„Failed to write proxy configuration" Orbiter nie mógł zapisać konfiguracji proxy Nginx dla domeny. Sprawdź miejsce na dysku oraz uprawnienia do /etc/nginx/. Uruchom plesk repair web -y, aby zresetować konfigurację nginx.

Witryna zwraca 502 Bad Gateway po utworzeniu kontenera Kontener może się jeszcze uruchamiać. Odczekaj 10–15 sekund i odśwież. Jeśli problem się utrzymuje:

1. Sprawdź, czy kontener działa w Orbiter
2. Sprawdź logi kontenera pod kątem błędów uruchamiania PHP-FPM
3. Spróbuj zrestartować kontener

Witryna zwraca 403 Forbidden na plikach PHP przy włączonym Shield To poprawne działanie Shield. Shield blokuje wykonywanie plików PHP w katalogach tylko do odczytu. Jeśli prawidłowy plik PHP jest blokowany, możesz:

• Dodać jego katalog nadrzędny do listy katalogów z prawem zapisu w ustawieniach Shield
• Lub tymczasowo wyłączyć Shield w celu testu

„Container is not starting correctly. Logs:" wraz z danymi wyjściowymi błędu Przeczytaj logi pokazane w błędzie. Częste przyczyny:

• Błąd konfiguracji PHP-FPM (sprawdź niestandardowy php.ini pod kątem błędów składni)
• Konflikt portów (inny proces używa przydzielonego portu)
• Niewystarczająca pamięć

Błędy cache

Czyszczenie cache zwraca „Permission denied" Nginx tworzy podkatalogi cache w trybie 700. Orbiter ustawia chmod -R 777 na podkatalogach cache automatycznie od wersji 1.5.0. Jeśli widzisz ten błąd w starszej wersji, zaktualizuj Orbiter lub uruchom:

chmod -R 777 /var/cache/orbiter/<domain>/

„Error during flush" Nie udało się opróżnić cache Nginx. Sprawdź, czy katalog cache istnieje i jest dostępny. Spróbuj wyczyścić z panelu Cache w interfejsie Orbiter.

Błędy CLI

--version zgłasza nieprawidłową wersję Naprawione w Orbiter 1.5.2. Zaktualizuj do najnowszej wersji. CLI odczytuje teraz meta.xml dynamicznie.

--db-export > dump.sql tworzy jednowierszowy plik tekstowy Naprawione w Orbiter 1.5.2. Zrzut SQL trafia teraz na stdout, a komunikat statusu na stderr. Zaktualizuj do najnowszej wersji.

WARNING: Error loading config file: open /root/.docker/config.json: permission denied To ostrzeżenie pojawiało się przy każdym poleceniu docker w wersjach przed 1.5.2. Ma charakter kosmetyczny i nie wpływa na funkcjonalność. Naprawione w Orbiter 1.5.2 poprzez ustawienie DOCKER_CONFIG=/nonexistent.

Błędy synchronizacji / kopii zapasowych

„Sync failed" / „Connection failed" Dla zewnętrznych lokalizacji kopii zapasowych (S3, SFTP, FTPS):

1. Zweryfikuj dane uwierzytelniające w konfiguracji lokalizacji kopii zapasowej
2. Użyj przycisku „Testuj połączenie", aby zdiagnozować problem
3. Sprawdź, czy serwer może dotrzeć do zdalnego hosta (zapora, DNS)

„Cannot read inventory file" Plik konfiguracyjny lokalizacji synchronizacji brakuje lub jest uszkodzony. Usuń lokalizację i dodaj ją ponownie z panelu Ustawienia → Kopie zapasowe.

Nocna kopia zapasowa wielokrotnie zgłasza FAIL ALL: Dump failed dla jednej domeny Usługa MariaDB wewnątrz tego kontenera utknęła w stanie FATAL. Zobacz Stan FATAL MariaDB (Can't initialize timers) w sekcji Błędy MariaDB powyżej, aby uzyskać diagnozę i rozwiązanie.

Błędy ogólne

„sysop returned invalid JSON" Wewnętrzny błąd komunikacji między kodem PHP Orbiter a uprzywilejowanym binarium sysop. Zazwyczaj przejściowy. Ponów operację. Jeśli problem jest trwały, sprawdź szczegóły w /var/lib/orbiter/orbiter.log.

„ConfigStore init failed, falling back to JSON" Nie udało się otworzyć bazy konfiguracji SQLite. Orbiter automatycznie przełącza się na przechowywanie w JSON, więc funkcjonalność jest zachowana. Sprawdź miejsce na dysku w /var/lib/orbiter/.

„Unknown error" przy dowolnej operacji Sprawdź szczegóły w pliku logu Orbiter:

tail -100 /var/lib/orbiter/orbiter.log

Sprawdź również log błędów Plesk:

tail -100 /var/log/plesk/panel.log