Strona nie działa, cron się nie wykonuje, mail się nie wysyła… Jak żyć?!

Nie od dziś wiadomo, że im większa precyzja wykonywanej pracy, w zderzeniu z ludzką niedoskonałością, tym większa szansa, że coś przestanie działać. „Niezawodne” algorytmy, serwisy i systemy, również stawiają nas developerów często pod ścianą płaczu. Z perspektywy czasu jednak uważam, że trudniej jest odpowiedzieć na pytanie dlaczego coś działa, niż dlaczego nie działa. Inwestygacja problemu wygląda jednak podobnie.

Strona nie działa!

Często właśnie tak określa się większość błędów i nie ważne czy problem jest sieciowy, brakło internetu czy wystąpił błąd aplikacji. Strona po prostu nie działa i już. Zdarzyła mi się sytuacja, w której ogólnie strona działała ale wczytywała się wolno a momentami wręcz zgłaszała brak dostępności. Więcej informacji na ten temat przyniosło poniższe polecenie, które służy do analizowania ruchu sieciowego:

mtr example.com

Dzięki niemu dowiedziałam się, że 80% pakietów zwyczajnie się zagubiła po drodze. i taką też informację przekazałam do działu hostingu.

Dość często bywają problemy z dostępnością strony w trakcie i po migracji. Nie od dziś wiadomo, że migracja strony pomiędzy serwerami trwa, nawet do 48h, w przypadku zmiany dns lub ip domeny. Poniższe polecenia mogą nam pomóc, w sprawdzaniu statusu propagacji względem lokalnego i konkretnego serwera dns.

Aby sprawdzić jaki rekord IP zwraca lokalny dns
```
nslookup example.com
```
Aby sprawdzić jaki rekord IP zwraca zdefiniowany dns
```
nslookup example.com 8.8.8.8
```
Aby sprawdzić gdzie jest domena zaparkowana
```
whois example.com
```

Cron się nie wykonuje 🙁

Oooo ile to razy zastanawiałam się, czemu jakieś dane nie zostały przetworzone. I tu również powody bywają różne, a najczęstsze z nich to zawieszony proces lub błąd aplikacji. Załóżmy jednak, że nasza aplikacja jest OK – co wtedy?

Dobrze sprawdzić czy zadanie nie wisi:
```
ps aux | grep plik.php
```
Jeśli wisi to:
```
kill [numer procesu]
```
Informacje czy w ogóle cron się odpala znajdziesz w: /var/log/cron.log
Jakie zadania są zdefiniowane znajdziemy w:
crontab -e
(w przypadku magento definiowane są w config.xml modułów)

Mail nie wysyła się?

Tak najczęściej użytkownicy / operatorzy określają fakt, że np. klient sklepu nie otrzymał powiadomienia. Pytanie tylko czy mail faktycznie nie wysłał się czy może nie dotarł. Jeśli to pierwsze to raczej błąd leży po stronie aplikacji, jednak co jeśli to drugie ?

Informacje na temat przesyłki maili najczęściej znajdziemy w np. w poniższych logach:

/var/log/mail.log
/var/log/exim4/mainlog

Znajdziemy tam np. informacje, że serwer mógł odrzucić e-mail z uwagi na fakt, że wylądowaliśmy na czarnej liście i systemy antyspamowe uznają nas za spamerów. Nie musieliśmy sami doprowadzić do takiej sytuacji. W przypadku serwerów współdzielonych mógł taki stan rzeczy spowodować nasz sąsiad na wirtualce obok ;-( i niestety nie jesteśmy wstanie się przed tym zabezpieczyć. Jeśli się taka sytuacja przytrafi, zostaje zgłosić sprawę administratorom hostingu i niestety cierpliwie czekać.

Co jeśli e-maile w ogóle nie wychodzą ? Założyć można, że to jakiś błąd aplikacji i nim sięgniemy po xdebug, warto najpierw sprawdzić logi systemowe aplikacji, np w magento będą to:

var/report
var/log/system.log
var/log/exception

oraz logi servera http:

error.log
access.log

Mam nadzieję, że ten wpis pomoże Wam w pracy 🙂