Fórum Root.cz
Hlavní témata => Server => Téma založeno: piter_sk 24. 09. 2014, 17:32:34
-
Zdravim,
mam problem s apache2 - casto a na vela serveroch (cisty odhad tak 10% zo vsetkych) mi ostavaju procesy v stave Gracefully finishing. apache2ctl graceful, /etc/init.d/apache2 reload ani service apache2 reload to nespravi. Popytal som sa googlu a nasiel som direktivu GracefulShutdownTimeout ktora mi tiez nefunguje. Skusal som menit aj KeepaliveTimeout (ten mam na 3 sekundy) a MaxKeepAliveRequests som zhodil na 100 (bolo 500) a nic.
Nerobi to na vsetkych serveroch, len na niektorych, aj ked konfiguraciu maju viac menej rovnaku, len vykon a zataz rozdielnu. Chvilu som podozrieval storage, ale nasiel som tu vadu aj na lokalnych masinach. Restart v logrotate beriem ako poslednu moznost (mam denny rotate).
Deje sa to na debianoch squeeze, apache 2.2.16. Mam tu aj FreeBSD, vytazene ci nie, na ziadnom z nich nemam tento problem. U debianu je jedno ci je server virtualny alebo fyzicky. Pouzivam prefork mpm (z roznych dovodov nemozem prejst na worker, teda aspon zatial)
stretol ste sa niekto s podobnym problemom? bol by som rad keby som to mohol riesit inac ako restartovanim sluzby kazdych 24h.
-
Pro zacatek bys mohl zkusit diagnostiku jako v tomhle dotazu: http://serverfault.com/questions/513357/apache2-hanging-on-sending-reply-gracefully-finishing
Na neco se ceka, neni od veci zjistit na co :)
-
Pro zacatek bys mohl zkusit diagnostiku jako v tomhle dotazu: http://serverfault.com/questions/513357/apache2-hanging-on-sending-reply-gracefully-finishing
Na neco se ceka, neni od veci zjistit na co :)
To mas pravdu. Zajtra to pozriem. Akurat mam pocit ze nebudem moct ovplyvnit na co caka - nad kodom ma kontrolu klient, nie ja. Chcel by som aby ten GracefulShutdownTimeout proste fungoval.
Kazdopadne dik za link.
-
nad kodom ma kontrolu klient, nie ja. Chcel by som aby ten GracefulShutdownTimeout proste fungoval.
Graceful shutdown ceka na dokonceni operaci. Pokud nektera z nich na neco nekonecne ceka (pripojeni k databazi nebo k cemukoli jinymu), tak proste ten shutdown fungovat nemuze a musis dat restart. Leda ze bys nasel presne, v cem je problem, a klienta na to slusne upozornil :)
P.S. na serveru má podle mě opodstatnění nastavit tcp keepalive na úrovni systému*. FreeBSD to má jako default, takže to by mohla být jedna z hypotetických příčin, proč se ti to tam neděje.
* http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html
-
Mal som za to ze GracefulShutdownTimeout existuje prave preto aby taketo operacie prerusil po X sekundach. Okrem toho som dnes pozrel jeden zo zavesenych procesov a ip adresa ktora poslala request nebola v netstate, co podla mna znamena ze spojenie uz bolo prerusene a mozno prave tym tcp_keepalive_time.
Zajtra sa k tomu vratim, skusim nejako zopakovat situaciu, hladat co maju spolocne servery s tymto problemom a tak.
-
Mal som za to ze GracefulShutdownTimeout existuje prave preto aby taketo operacie prerusil po X sekundach.
Jo, sorry, prehlidl jsem to slovo "Timeout" :) No kazdopadne rikas, ze to nefunguje, takze jsi tam, kde jsi byl...
Okrem toho som dnes pozrel jeden zo zavesenych procesov a ip adresa ktora poslala request nebola v netstate, co podla mna znamena ze spojenie uz bolo prerusene a mozno prave tym tcp_keepalive_time.
Jo, to by tomu asi nasvedcovalo. Pak to teda asi visi na nejake te databazi nebo tak neco... Chce to proste dal zkoumat.
-
hadam, ze mas problem kazdou nedeli rano v 5,00 hodin. proste jsem v logrotate.d hodil restart misto graceful. travit na tom vic nez 4 hodiny se mi nechtelo.
EDIT: Aha, ctu to znovu a ted vidim, ze je to skutecne logrotate, ale mas ho nastaveny casteji... No zkus kdyztak v tom google i kombinace "apache sunday morning". ja se sice rady nedobral, ale pro me potreby je to reseni dostatecne.
Resil jsem to i tady a nedosel reseni jineho nez restart.
-
hadam, ze mas problem kazdou nedeli rano v 5,00 hodin. proste jsem v logrotate.d hodil restart misto graceful. travit na tom vic nez 4 hodiny se mi nechtelo.
EDIT: Aha, ctu to znovu a ted vidim, ze je to skutecne logrotate, ale mas ho nastaveny casteji... No zkus kdyztak v tom google i kombinace "apache sunday morning". ja se sice rady nedobral, ale pro me potreby je to reseni dostatecne.
Resil jsem to i tady a nedosel reseni jineho nez restart.
Viem, cital som tvoje riesenie este predtym ako som sa pytal. Vcera som sa k tomu nedostal (platal som bash :D) a dnes sa k tomu asi zas nedostanem. Ale cosi som predsa len pozrel: Vsetky zavesene procesy pri graceful skusia zavriet subor ktory uz neexistuje, hodia error "invalid inode" alebo tak a vratia sa do predosleho stavu - nerestartuju sa. V ramci jednoho servera je to vzdy ten isty inode, tym padom si myslim, ze to bude log. Hned ako sa k tomu dostanem a pohnem s tym viac, dam vediet.
-
skusia zavriet subor ktory uz neexistuje, hodia error "invalid inode" alebo tak
Tak to je jeste o nekolik radu divnejsi. Zavirat soubor, ktery mezi tim nekdo smazal, je naprosto korektni operace, ktera sama o sobe zadnou chybu nezpusobi. Pokud by ti to opravdu hazelo "invaliv inode", tak by to spis vypadalo na poskozeni FS, takze poradny prozkoumani bych neodkladal...
-
No bylo by skvele kdyby jsi to dokazal VYRESIT. Ja tam mam v podstate obycejny cesky weby takze v nedeli v 5,00 rano je provoz ~ nulovy a nikdo z alienu by to primo nezaplatil tak co s nima... :-)
jinak mozna pro info: me se to deje na vpsfree.cz - OpenVZ, ZFS "nahoře", klasicke Ubuntu precise "u mě".
-
A jeste jedna zajimavost: v zadnych time limitech tam asi nebude problem. Kdyz jsem daval graceful ihned po sobe v terminalu tak to bylo tak 50:50 kdy weby jely a kdy ne. Takze to bylo treba po 10 sekundach ten graceful a vyslovene nahodne to padalo.
-
takto vyzera strace -p PID pred, pocas a po "apache2ctl graceful"
futex(0x7fcdd155ae40, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
close(4294967295) = -1 EBADF (Bad file descriptor)
close(4294967295) = -1 EBADF (Bad file descriptor)
rt_sigreturn(0) = -1 EINTR (Interrupted system call)
futex(0x7fcdd155ae40, FUTEX_WAIT_PRIVATE, 2, NULL
moze to byt poskodenie FS?
-
moze to byt poskodenie FS?
Ne, bad file descriptor obvykle znamena vnitrni chybu v aplikaci - bud se snazi zavrit soubor, ktery uz je zavreny, nebo proste pouzije jako FD nejake neplatne cislo.
U tebe je to ten druhej pripad - to cislo 4294967295 je -1 vypsany jako unsigned, muzes si to sam vyzkouset:
# cat >test.c <<EOF
#include <stdio.h>
int main() {
signed int i = -1;
printf("%u\n",i);
}
EOF
# make test
# ./test
4294967295
Takze jsi nasel chybu v Apachi - nekde oteviral nejakej soubor, dostal -1 (chyba) a nezkontroloval si to. Pokud tu chybu umis vyvolat, nemelo by byt zas tak tezky najit, kde vznika. A muzes hrde poslat patch :)
-
Takze jsi nasel chybu v Apachi - nekde oteviral nejakej soubor, dostal -1 (chyba) a nezkontroloval si to. Pokud tu chybu umis vyvolat, nemelo by byt zas tak tezky najit, kde vznika. A muzes hrde poslat patch :)
Myslím, že to nebude takový objev. Neschopnost se korektně zrestartovat jsem u indiánů pozoroval už před 10 lety a od té doby se nic zásadního nezměnilo.
-
Myslím, že to nebude takový objev. Neschopnost se korektně zrestartovat jsem u indiánů pozoroval už před 10 lety a od té doby se nic zásadního nezměnilo.
Najit chybu v Apachi zas takovy terno neni, to mas asi pravdu :)
Na druhou stranu pokud je to fakt tak, ze si nezkontroluje chybu v operaci s fd a v klidu s ni pracuje, tak je to docela velka chyba.
Jeste to ale neni uplne jisty, ještě by to mohlo být něco tohodle typu: http://bugs.python.org/issue6271
-
To je klidně taky možný... to byl jen takový komentář na doplnění. S tím, že si vzpomínám, že si na to stěžovala spousta lidí včetně balíčkářů z distribucí, ale žádnou nadšenou shanu o nápravu u upstreamu opravdu neprobudili.
-
To je klidně taky možný... to byl jen takový komentář na doplnění. S tím, že si vzpomínám, že si na to stěžovala spousta lidí včetně balíčkářů z distribucí, ale žádnou nadšenou shanu o nápravu u upstreamu opravdu neprobudili.
Tak problemy s restartovanim muzou byt zpusobeny kdecim, to jeste nutne nemusi byt tohle. Na Ubuntu mě třeba trápil init skript a bug roky nikoho nevzrušoval :) https://plus.google.com/109540561880466469418/posts/TAYTy8DHMLq
-
Tak ako som si myslel, dnes som sa k tomu uz nedostal. Ale pohladal som bugy a nasiel som jeden co sa podoba mojej situacii (https://issues.apache.org/bugzilla/show_bug.cgi?id=50261). Je z roku 2010 a oznaceny ako NEW :o . Buduci tyzden skusim zopakovat problem a ziskat kompletny strace a dodat apachu viac info (len pre klud v dusi, neverim ze s tym zacnu hybat koli mne, ak je to vobec ten isty poblem). Najjednoduchsie bude dat restart a posunut logrotate na hodinu s minimalnou prevadzkou.
Prijemny vikend.
-
Tak ako som si myslel, dnes som sa k tomu uz nedostal. Ale pohladal som bugy a nasiel som jeden co sa podoba mojej situacii (https://issues.apache.org/bugzilla/show_bug.cgi?id=50261). Je z roku 2010 a oznaceny ako NEW :o
Vidím, že se NIC nezměnilo... Může se za Apache. Ne ne ne, používáte špatnou verzi APR. A furt dokola. >:(
-
Tak ako som si myslel, dnes som sa k tomu uz nedostal. Ale pohladal som bugy a nasiel som jeden co sa podoba mojej situacii (https://issues.apache.org/bugzilla/show_bug.cgi?id=50261). Je z roku 2010 a oznaceny ako NEW :o .
Syndrom podobnej, ale trace mi neprijde byt v nicem podobnej. U tebe zatim vime jenom to, ze obsluha signalu se snazi zavrit nejaky nesmyslny deskriptory (-1) a potom se vrati do stejnyho cekani na mutex, misto aby proces skoncil.
-
P.S. jestli to jenom trochu jde, na celej Apache bych se vykaslal a presel na Nginx - s nim jsem zatim zadny problemy nezazil.
-
P.S. jestli to jenom trochu jde, na celej Apache bych se vykaslal a presel na Nginx - s nim jsem zatim zadny problemy nezazil.
Nemozne. Bohuzial. Je to webhostingove prostredie, vezmi klientom .htaccess a su strateni. Na systemy kde mam kontrolu nad kodom uz som nginx nasadil a mam rovnaku skusenost - ziaden problem.