padający apache

[Mich@ł 0]

Mam pewien problem, od około 2-3 dni codziennie co kilka godzin pada mi apache.

2009:10:27-00:14:03: Error restarting service httpd : uid 0 gid 0 : /etc/init.d/httpd restart >>/dev/null 2>>/dev/null

2009:10:27-00:14:03: httpd didn't restart properly, re-starting

2009:10:27-00:14:04: Error restarting service httpd : uid 0 gid 0 : /etc/init.d/httpd restart >>/dev/null 2>>/dev/null

2009:10:27-00:14:04: service httpd wasn't running, starting it

2009:10:27-00:14:04: Error starting service httpd : uid 0 gid 0 : /etc/init.d/httpd start >>/dev/null 2>>/dev/null

2009:10:27-00:14:14: service httpd didn't start, re-starting it

2009:10:27-00:14:14: Error restarting service httpd : uid 0 gid 0 : /etc/init.d/httpd restart >>/dev/null 2>>/dev/null

2009:10:27-00:15:01: service httpd wasn't running, starting it

2009:10:27-00:15:02: Error starting service httpd : uid 0 gid 0 : /etc/init.d/httpd start >>/dev/null 2>>/dev/null

2009:10:27-00:15:12: service httpd didn't start, re-starting it

 

Co może być przyczyną takiego zawieszania? Po zawieszeniu nie można go włączyć (dopieor po reboocie zaczyna śmigać). Z góry dzięki za pomoc.

[guziec 109]

Mam pewien problem, od około 2-3 dni codziennie co kilka godzin pada mi apache.

 

 

Co może być przyczyną takiego zawieszania? Po zawieszeniu nie można go włączyć (dopieor po reboocie zaczyna śmigać). Z góry dzięki za pomoc.

Nie masz logów?

[is_wm 287]

 

 

Jak padnie to sprawdź co zajmuje port 80 i wszystko ci się wyjaśni.

 

Czyli jak pada apache, to znaczy, że coś zajmuje port?

 

Propozycja dla ekipy WHT: trzeba ten post przykleić, przyda się wielu osobom...

[MasterNETpl 100]

Trochę tam informacji jest na ten temat..

[is_wm 287]

Nie, ale tak może być, jest to jedna z wielu przyczyn.

 

Więc czemu piszesz że WSZYSTKO się wyjaśni?

[Mich@ł 0]

Nie masz logów?

Logi errortaskq załączyłem w pierwszym poście. Jest to początek gdy zaczyna być problem z apache (dalsza część logów jest powieleniem tych powyższych).

 

No chyba że o innych logach myślisz :>?

 

Jeżeli chodzi o zajęcie portu 80 przez jakiś inny program to faktycznie coś w tym może być ponieważ nie dostaje komunikatów od OVH (brak łączności z portem 80) a więc port 80 odpowiada gdy apache "leży".

 

 

Na forum DA wyczytałem że exim może zajmować mi port i chyba w tym kierunku będę musiał poszukać przyczyny. W najgorszym wypadku całkowicie wyłączę exim

 

 

Jedyne co mnie ciekawi to fakt że nie robiłem ostatnio żadnych zmian na serwerze i nagle pojawił się taki problem

[guziec 109]

Logi errortaskq załączyłem w pierwszym poście. Jest to początek gdy zaczyna być problem z apache (dalsza część logów jest powieleniem tych powyższych).

 

No chyba że o innych logach myślisz :>?

 

Zgadza się - myślę o logach z apache'a, tych na które wskazuje dyrektywa ErroLog w jego pliku konfiguracyjnym. W

momencie kiedy pada usługa to się sprawdza w logach tej usługi - to chyba logiczne.

 

 

Jeżeli chodzi o zajęcie portu 80 przez jakiś inny program to faktycznie coś w tym może być ponieważ nie dostaje komunikatów od OVH (brak łączności z portem 80) a więc port 80 odpowiada gdy apache "leży".

 

 

Niekoniecznie, kiedy serwer padnie tak że wysyła "500 Internal Server Error" to też port 80 odpowiada. Zresztą to nie jest żaden problem z portem, apache nie padnie z tego powodu że coś mu się próbuje dostać na port 80, najwyżej się nie uruchomi jak tam coś będzie JUŻ siedziało.

 

Na forum DA wyczytałem że exim może zajmować mi port i chyba w tym kierunku będę musiał poszukać przyczyny. W najgorszym wypadku całkowicie wyłączę exim

 

Nonsens. Co ma exim do portu 80, przecież to serwer SMTP. Nie czytaj takich głupot.

To:

netstat -ntlp

Pokaże ci listę otwartych portów tcp wraz z daemonami które na nich słuchają.

 

Jedyne co mnie ciekawi to fakt że nie robiłem ostatnio żadnych zmian na serwerze i nagle pojawił się taki problem

 

W logach będzie pisało.

[Mich@ł 0]

Właśnie zauważyłem że na liście aktywnych procesów dość sporo zajmuje perl. A samego exim nie mogę wyłączyć poprzez exim stop.

 

 

Miałbym jeszcze pytanie a konkretnie jak sprawdzić jaki skrypt wykorzystuje tak nagminnie perl? Jak widzę 4 procesy perl'a wykorzystują około 60% mocy procesora.

[guziec 109]

Właśnie zauważyłem że na liście aktywnych procesów dość sporo zajmuje perl. A samego exim nie mogę wyłączyć poprzez exim stop.

 

 

Miałbym jeszcze pytanie a konkretnie jak sprawdzić jaki skrypt wykorzystuje tak nagminnie perl? Jak widzę 4 procesy perl'a wykorzystują około 60% mocy procesora.

 

ps faux |less

[Mich@ł 0]

Oki dzięki

 

No to powiedzmy że jestem już chyba bliski rozwiązaniu problemu

mam 4 procesy z perl'em:

7026 apache 20 0 11656 8804 1384 S 31 0.4 14:26.71 perl

7028 apache 20 0 8392 6264 1384 S 19 0.3 11:15.52 perl

7027 apache 20 0 7808 5876 1384 S 13 0.3 13:23.16 perl

7025 apache 20 0 7120 5212 1384 S 9 0.3 7:40.33 perl

i znalazłem również co wykonuje te procesy:

apache 7025 11.7 0.2 7120 5208 ? Ss 22:42 7:45 ./yzirfzaw.pl

apache 7026 22.1 0.4 11656 8804 ? Ss 22:42 14:37 ./yzirfzaw.pl

apache 7027 20.4 0.2 7628 5872 ? Ss 22:42 13:28 ./yzirfzaw.pl

apache 7028 17.2 0.2 7480 5700 ? Rs 22:42 11:20 ./yzirfzaw.pl

 

 

Tylko szczerze mówiąc nie bardzo coś mi to mówi z uwagi na to że jak widzę nawet takiego pliku nie mam na serwerze Da się sprawdzić skąd jest on dokładnie odpalany?

[xorg 693]

Zdaje się iż z domyślnego katalogu apache.

 

PS. Przeskanuj system.

[Mich@ł 0]

Jak widzę chyba ktoś sobie z mojego serwerka zrobił serwer pocztowy... Przynajmniej tak mi się wydaje... Zamiast httpd na porcie 80 pojawia się ten skrypt ./yzirfzaw.pl i jakoś procesów w exim jest troche (exim nie mogę wyłączyć tak jak by to ktoś zablokował).

 

No nic zapewne bez interwencji doświadczonej osoby się nie obejdzie

 

Dzięki wszystkim za pomoc

[xorg 693]

Miałam racje jak widać.

Rozumiem że to taki zaszczyt dla Ciebie że sobie na czole to wypiszesz

 

gdy odpalisz exim to zapcha ci znów.

Sugerujesz że to exim odpala ten skrypt ? :>

[guziec 109]

Miałam racje jak widać.

 

LOL. W którym miejscu?

 

Wyłącz exima z komendy wykonywanej na roocie bo z panelu to możesz klikać i Ci nic to nie da.

killall exim lub killall -9 exim

i włącz httpd... jest to rozwiązanie chwilowe bo zapewne gdy odpalisz exim to zapcha ci znów.

 

Świetna rada. Tylko wiesz, to z apachem jest problem, nie z eximem.

 

Oki dzięki

 

No to powiedzmy że jestem już chyba bliski rozwiązaniu problemu

mam 4 procesy z perl'em:

 

i znalazłem również co wykonuje te procesy:

 

 

 

Tylko szczerze mówiąc nie bardzo coś mi to mówi z uwagi na to że jak widzę nawet takiego pliku nie mam na serwerze Da się sprawdzić skąd jest on dokładnie odpalany?

 

Nosz kurna, ile można razy pisać? W LOGACH TO PISZE. Wystarczyłoby żebyś zajrzał do logów zamiast szukać eximów, perlów i innych pierdół. Ktoś ci podesłał skrypt na serwer przez dziurę w jakimś pewnie phpBB albo innym tego typu "świetnym" oprogramowaniu i w tej chwili robisz za serwer spamów, dlatego exim się nie wyrabia i pewnie jesteś już na wszystkich RBL-ach. Jak masz jakiś wstręt do logów, to wpisz:

 

apt-get install locate
updatedb
locate yzirfzaw.pl

 

Z tym że dalej będziesz miał dziurę w systemie i za chwilę ktoś podeśle ci tam inne gówno i roześle milion spamów.

[is_wm 287]

Miałam racje jak widać.

Wyłącz exima z komendy wykonywanej na roocie bo z panelu to możesz klikać i Ci nic to nie da.

killall exim lub killall -9 exim

i włącz httpd... jest to rozwiązanie chwilowe bo zapewne gdy odpalisz exim to zapcha ci znów.

 

Hahaha już rozgrzewam drukarkę i jazda w 150 kopiach, rozdam wszystkim na studiach

[Gość patrys]

DamianMiodek:

ROOTHosting.pl - Serwery Dedykowane - Kolokacja Serwerów - Administracja serwerami

hyh

 

 

Mich@ł: Znajdź kogoś kto Ci to ogarnie byś nagle nie dostał maila od ovh, że masz system dostępy via ftp, a Twój serwer rozsyłał spam.

 

Swoją drogą sprawdź katalog /tmp, a by znaleźć konkretny plik możesz użyć find.

[^^KaMaZZ~.^ 154]

Ktoś ci podesłał skrypt na serwer przez dziurę w jakimś pewnie phpBB albo innym tego typu "świetnym" oprogramowaniu

Co chciałeś pokazać wrzucając tutaj phpBB, swój brak wiedzy czy próbę przekazania dalej społeczności plotki: 'phpbb to shit, a przemo to już wogólel.' ?

[guziec 109]

Co chciałeś pokazać wrzucając tutaj phpBB, swój brak wiedzy czy próbę przekazania dalej społeczności plotki: 'phpbb to shit, a przemo to już wogólel.' ?

Ach przepraszam. Oczywiście phpbb to oprogramowanie pewne i stabilne niczym piramida Cheopsa. Aż dziwne że jeszcze amerykańska armia z niego nie korzysta.

http://dev.computerworld.pl/news/80828/ISP.zakazuja.phpBB.html

Źli ludzie zabronili korzystania, ale to pewnie brak wiedzy.

 

BTW, Google na frazę "Dziury w phpbb" zwraca 8230 wyników.

[xorg 693]

Lecz wszystko dotyczy starych wersji. Nie ma żadnej publicznej dziury na obecną wersję przema.

[guziec 109]

Lecz wszystko dotyczy starych wersji. Nie ma żadnej publicznej dziury na obecną wersję przema.

Po pierwsze nie "nie ma" tylko najwyżej "na razie o żadnej nie wiadomo". Kwestia czasu. Być może - nie jestem z tym na bierząco, dawno dałem sobie spokój ze wspieraniem tego shitu na którymkolwiek serwerze. Liczba bugów w przeszłości nie mówiąc już o kwestii obciążania bazy i liczbe zapytań generowanych przy każdym głupim odświeżeniu strony świadczy tylko o tym że ten soft pisali po prostu jacyś dyletanci. Jeśli nie zostało to napisane od początku na nowo to nie postawiłby na bezpieczeństwo czegoś takiego pięciu złotych.

[Miłosz 2311]

guziec ma racje, przemo to shit nieziemski. dzira na dziurze. słaba wydajność. w przemie była luka która pozwalała przejrzeć każdy plik w katalogu forum, m.in config.php. i tak znajomy pozbył się bazy z 100k postów a ciekawe o ilu podobnych lukach jeszcze nie wiadomo...

 

Mich@ł, udało Ci się znaleźć ten syf?

[www.ionic.pl 535]

w przemie była luka która pozwalała przejrzeć każdy plik w katalogu forum, m.in config.php. i tak znajomy pozbył się bazy z 100k postów

W przemie ? A nie kombinacja magic + brak o_b_d ?

[Mich@ł 0]

Mich@ł: Znajdź kogoś kto Ci to ogarnie byś nagle nie dostał maila od ovh, że masz system dostępy via ftp, a Twój serwer rozsyłał spam.

I właśnie dokładnie tak zrobiłem, można powiedzieć że od rana serwer śmiga już ładnie

 

Swoją drogą sprawdź katalog /tmp, a by znaleźć konkretny plik możesz użyć find.

Próbowałem znaleźć ten plik poprzez "znajdz" w mc i niestety nie wykryło mi go najprawdopodobniej coś zle ro biłem

 

 

Nosz kurna, ile można razy pisać? W LOGACH TO PISZE.

guziec, ale przecież w logach nie było dokładniej lokalizacji gdzie ten plik jest odpalony No chyba że masz na myśli jakieś konkretne logi

 

Mich@ł, udało Ci się znaleźć ten syf?

Tak, tyle że nie ja go znalazłem a wynajęta osoba która się zajęła usunięciem tego programiku

 

przemo to shit nieziemski. dzira na dziurze.

Jak dla mnie stanowczo przesadzasz Najbezpieczniejszy skrypt to:

<?

echo 'Bezpieczny skrypt';

?>

Przecież skrypty takie jak Joomla czy IPB też mają luki zwykle to tylko kwestia czasu aż zostaną wykryte Nie ma skryptu idealnego

 

 

Dzisiaj planuje przejrzeć część skryptów które są na dedyku i zobaczę który może być dziurawy (niektóre konta mają wyłączoną opcje safe_mode ponieważ wymagał tego skrypt).

[is_wm 287]

Moze warto zrobic osobnych userow + open_basedir ?

Bo to jednak niezbyt normalne, zeby ktos przez www mogl az tak namieszać, że ma to wpływ na jakas 'globalna' usluge.

[UnixStorm.org 327]

Akurat jeśli chodzi o exim na porcie 80 to P. Miodek był blisko problemu, bo taki też istnieje.

 

http://www.directadm...610&postcount=2

 

Sprawa jest od dawna zgłoszona na liście PHP, ale nikt problemu nie chce wziąć na siebie i każdy zrzuca winę na inną usługę. Sytuacja dotyczy tylko serwerów z mod_php i pojawia się najczęściej przy masowym mailingu przez mail(), następnie (np. po dodaniu domeny w DA) Apache jest restartowany, ale proces wywołany przez mail() wskakuje z eximem na port 80, tym samym restart Apache w tym momencie powoduje błąd. Konieczne jest wyłączenie exima, zrestartowanie Apache i ponowny start exima. Albo... rezygnacja z mod_php...