Apache čeká na gracefully finishing

[piter_sk]

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.

[Reklama]

[Mirek Prýmek]

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

[piter_sk]

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.

[Mirek Prýmek]

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

[piter_sk]

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.

[Reklama]

[Mirek Prýmek]

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.

[to_je_jedno]

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.

[piter_sk]

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 ) 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.

[Mirek Prýmek]

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...

[to_je_jedno]

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ě".

[to_je_jedno]

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.

[piter_sk]

takto vyzera strace -p PID pred, pocas a po "apache2ctl graceful"

Kód: [Vybrat]

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?

[Mirek Prýmek]

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:

Kód: [Vybrat]

# 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

[Lol Phirae]

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.

[Mirek Prýmek]

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