Rozwiązywanie problemów

Problemy występujące podczas uruchamiania Ayakaleaf Pro za pomocą Docker Desktop w macOS i sposoby ich sprawdzania.

​

Inicjalizacja kończy się błędem invalid command code

bin/init zgłasza sed: ... invalid command code, gdy trafi na BSD sed z macOS. Umieść GNU sed w PATH zgodnie z krokiem 1. Pobierz Toolkit i sprawdź sed --version.

Nieudana inicjalizacja może pozostawić wszystkie trzy pliki w config/ z pustym OVERLEAF_INVITE_TOKEN_SECRET. Ponowne uruchomienie bin/init zgłasza wtedy Config files already exist. W przypadku nowej instalacji, która nigdy nie została uruchomiona, przenieś te trzy pliki do katalogu kopii zapasowej i uruchom bin/init ponownie. W przypadku istniejącej instancji zachowaj jej konfigurację i sekrety i nie usuwaj jej plików tylko po to, aby bin/init uruchomił się ponownie.

​

MongoDB ciągle się restartuje

Odczytaj logi MongoDB i wersję jądra maszyny wirtualnej Dockera:

bin/docker-compose logs --tail=100 mongo
docker info --format '{{.KernelVersion}}'

Jeśli log wskazuje na niezgodność z jądrem Linux, wykonaj krok Sprawdź jądro Linux maszyny wirtualnej Dockera i ponownie uruchom bin/up -d. Sam kod wyjścia 137 nie dowodzi, że MongoDB zabrakło pamięci: sprawdź stan kontenera i logi. Starszy problem z MongoDB w Docker Desktop opisano też w sekcji Rozwiązywanie problemów.

​

Nie można połączyć się z demonem Dockera

Uruchom Docker Desktop i sprawdź wybrany kontekst Dockera, zobacz 0. Instalacja Docker Desktop. Jeśli docker info działa, ale kompilacje nie mogą dotrzeć do Dockera, sprawdź ustawienia gniazda w config/overleaf.rc i przeczytaj logi clsi. Działający Docker CLI na Macu nie dowodzi, że montowanie gniazda w aplikacji jest poprawne.

​

Strona się otwiera, ale kompilacje kończą się błędem

Sprawdź, czy obraz TeX Live istnieje lokalnie i czy odpowiada architekturze silnika Dockera:

docker image inspect ghcr.io/ayaka-notes/texlive-full:2026.1 \
  --format '{{.Os}}/{{.Architecture}}'
bin/logs -f clsi

Na komputerach z Apple silicon obraz powinien mieć postać linux/arm64. Sprawdź, czy SERVER_PRO i SIBLING_CONTAINERS_ENABLED mają wartość true, a następnie zastosuj zmiany poleceniem bin/up -d. Jeśli logi zgłaszają brakujący katalog kompilacji, sprawdź udostępnianie plików w Docker Desktop i lokalizację OVERLEAF_DATA_PATH. Nie wyłączaj kompilacji w piaskownicy, aby ukryć błąd montowania.

​

Not a directory lub brakujący bind mount

Plik hosta montowany przez nadpisanie mógł zostać usunięty albo Docker mógł utworzyć katalog w miejscu, w którym powinien być plik. Sprawdź ścieżkę źródłową na hoście oraz to, czy montowanie oczekuje pliku, czy katalogu. Przywróć plik konfiguracyjny, zanim odtworzysz kontener. Instalacja w /tmp może napotkać ten problem, gdy macOS usunie pliki tymczasowe.

​

Konflikty portów lub nazw kontenerów

Jeśli port 8080 jest zajęty, wybierz inny port w config/overleaf.rc, odpowiednio ustaw OVERLEAF_SITE_URL i ponownie uruchom bin/up -d.

Toolkit nadaje swoim kontenerom stałe nazwy, takie jak sharelatex, mongo i redis. Sama zmiana PROJECT_NAME nie uniezależnia od siebie dwóch instalacji Toolkit. Przed uruchomieniem drugiej instancji sprawdź docker ps -a i użyj innych nazw kontenerów w nadpisaniu Compose, innego portu oraz osobnych katalogów danych. Nie usuwaj kontenerów ani danych istniejącego wdrożenia, aby rozwiązać konflikt nazw.

​

Instancja po pewnym czasie jest niedostępna

Mac prawdopodobnie przeszedł w stan uśpienia albo Docker Desktop został zamknięty. Zobacz Utrzymywanie dostępności instancji.

​

bin/doctor informuje, że to nie jest Linux, lub prosi o logowanie do Quay

Oba ostrzeżenia są w macOS z publicznym obrazem oczekiwane, zobacz 2. Poznaj Toolkit. Zamiast tego sprawdź pobieranie obrazów, stan usług i wyniki kompilacji i nie ignoruj innych błędów w raporcie.