IT Blog

Taaaak kolejny dzień kolejna nowość.

Ja tu sobie Gadu-gadu a tu klient coś takiego podsyła.

No to myślę sobie (24)Too many open files: Jasne limit open files. Sprawdzam ulimit -a i faktycznie open files ma na 1024, plików w domlogs 86000, nie zadziała. Myślę sobie ok /etc/security/limits.conf, faktycznie brak tam było ustawionych limitów. No to cały szczęśliwy, że rozwiązałem problem robie # service httpd restart , a tu ZONK (24)Too many open files: – taa zabawne.

Szukałem wszędzie, nieznalazłem nic, a rozwiązanie wpadło przez przypadek. Pomyślałem, że jak nie tak to dam ulimit -n 100000 w /etc/init.d/httpd otwieram plik a tu DING DONG trzy linijki

ulimit -n 1024

ulimit -n 2048

ulimit -n 16000

Widać Cpanel już coś tu kombinował, ku mej radości zakomentowałem 3 cudowne linijki, dałem

ulimit -n 100000

voila

Działa. Uff, a już myślałem, że apache pobiera limity z kosmosu 🙂

Ostatnio zgłosił się do mnie klient z problemem – dosyć denerwującym – nie moge zmienić DNS na swój serwer. Pomyślałem, że to jest jakiś żart albo zajęcie na 15 minut. Na systemie Cpanel i co nie można zmienić DNS 😐 jakieś jaja już sobie ludzie robią czy co ?

Z parą w ustach loguje się na serwer, piszę

dig domena.pl @localhost

A tam gnojek mi daje SERVFAIL – co ??????????? jak ????????? No bez jaj. No to ryjemy dalej bind-9.3 no ok ujdzie. Patrze w config, hmm nic szczególnego. Co jest do cholery. Z 15 minut zrobiła się godzina ale w końcu znalazło się rozwiązanie, okazało się że wspaniały wynalazek VIEW w bindzie się po prostu nie sprawdza. Niektórzy powiedzą, że wszystko jest ok ale dziwnym trafem na tej konfiguracji po całkowitym wywaleniu view „external”, view „local” i usunięciu tagów view „internal” na dig zobaczyłem NO ERRORS.

No i siada człowiek na 4 literach i myśli co do cholery. Do dzisiaj nie zrozumiem po co wprowadzać VIEW skoro nie wszędzie to działa.

Notabene prawie na każdym serwerze query-source port jest ustawione na 53, ehhh zakomentować zapomnieć, czemu ? Poczytajcie o dziurze cache w dns to na pewno nie pomaga 🙂

Kurcze, dlaczego to tak jest, że mam bazy w MyISAM na MySQL i nie ma problemów, a to dobre i kochane InnoDB zawsze grymasi ?

No dobra a teraz do konkretów, jak się okazuje jedynym dobrym sposobem żeby uszkodzoną bazę w InnoDB przywrócić jest …….. usunięcie jej i utworzenie na nowo -0 chore ale co poradzić.

Kroki są proste:

1) W my.cnf dajemy innodb_force_recovery = 4 – wartość 4 jest używana przeze mnie, natomiast mysql.com bardziej dokładnie definiuje co jak i dlaczego.

2) Dla cpanela service mysql restart, dla innych po prostu restart MySql

3) Dla ludzi kochających Cpanel polecam bloknąć konto na czas recovery czyli – /scripts/suspendacct nazwa_konta

4) Linia komend mysqldump baza tabela > plik.sql albo mysqldump baza > plik.sql

5) Dropujemy tabelę lub bazę

6) Dajemy # przed innodb_force_recovery w my.cnf

7) Restartujemy MySQL

8) Wrzucamy dumpa [root] # mysql nazwa_bazy < plik.sql

I pomyśleć cholera, że w MyISAM wystarczy dać REPAIR TABLE, bleh ale cóż 🙂