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 :)
Citace od: Mirek Prýmek kdy 24. 09. 2014, 18:21:30
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.
Citace od: piter_sk kdy 24. 09. 2014, 19:42:12
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.
Citace od: piter_sk kdy 24. 09. 2014, 20:27:42
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...
Citace od: piter_sk kdy 24. 09. 2014, 20:27:42
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.
Citace od: to_je_jedno kdy 25. 09. 2014, 21:40:18
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.
Citace od: piter_sk kdy 26. 09. 2014, 08:32:21
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?
Citace od: piter_sk kdy 26. 09. 2014, 12:16:19
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 :)
Citace od: Mirek Prýmek kdy 26. 09. 2014, 12:55:57
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.
Citace od: Lol Phirae kdy 26. 09. 2014, 13:06:05
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.
Citace od: Lol Phirae kdy 26. 09. 2014, 13:20:43
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.
Citace od: piter_sk kdy 26. 09. 2014, 17:25:18
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. >:(
Citace od: piter_sk kdy 26. 09. 2014, 17:25:18
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.
Citace od: Mirek Prýmek kdy 26. 09. 2014, 18:21:25
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.