Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - piter_sk

Stran: 1 [2]
16
Server / Re:Apache čeká na gracefully finishing
« 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 . 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.

17
Server / Re:Apache čeká na gracefully finishing
« kdy: 26. 09. 2014, 12:16:19 »
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?

18
Server / Re:Apache čeká na gracefully finishing
« kdy: 26. 09. 2014, 08:32:21 »
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.

19
Server / Re:Apache čeká na gracefully finishing
« kdy: 24. 09. 2014, 20:27:42 »
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.

20
Server / Re:GracefulShutdownTimeout
« kdy: 24. 09. 2014, 19:42:12 »
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.

21
Server / Apache čeká na gracefully finishing
« kdy: 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.

22
Sítě / Re:IDS/IPS/FW řešení pro hosting
« kdy: 23. 04. 2013, 13:19:37 »
Cisco vnimam ako "isty pich", akurat mam strach presne z toho co pises, ze sa nebude dat nakonfigurovat a okrem toho scriptovanie z dola (z lokalnych firewallov) je o dost zlozitejsie podla toho co mi vypravaju.
Co sa tyka toho checkpointu, zaradili sme ho do vyberu, uvidime ako dopadne pri priamom porovnani s ostatnymi (ostatni su watchguard, juniper, aj ked ten je len do poctu, fortinet, cisco a zoznam rastie), kontakt na miestneho obchodnika si vyhladame sami, jelikoz som v zahranici ;)
dakujem za rady.

23
Sítě / Re:IDS/IPS/FW řešení pro hosting
« kdy: 22. 04. 2013, 16:44:18 »
checkpoint vyzera zaujimavo, posuvam dalej. Ale na druhu stranu mam tiez strach z all-in-one rieseni - hlavne koli impaktu pokazeneho hardwaru. Vyatta je zaujimava, ale po pokusoch s linuxami na x86 cpu uz asi taketo riesenie neprejde. beztak to kuknem a pohladam feedback , ze co na to ostatny.
vdaka.

24
Sítě / Re:IDS/IPS/FW
« kdy: 22. 04. 2013, 15:12:38 »
mrkni sa na Sourcefire NGIPS
zaujimave, mrknem to. vdaka

25
Sítě / IDS/IPS/FW řešení pro hosting
« kdy: 22. 04. 2013, 10:20:28 »
Zdravim,

potreboval by som odporucit riesenie ids/ips/firewall pre hostingovu firmu. Datovy objem ktorym manipulujeme sa pohybuje okolo 1Gbps, puntualne 2Gbps a mame dobre nasliapnute na rast. Dost nam zalezi na pps, v beznej premavke sa pohybujeme okolo 150Kpps rozdelenych medzi 4 FW, ale cim dalej tym castejsie nas trapia utoky, ktore by sme chceli zastavit, alebo aspon uregulovat tymto systemom. Zacali sme pozerat produkty cisco, juniper, fortinet, watchguard etc..., ale z jednania s obchodnymi zastupcami moc mudry niesom, kazdy chvali svoje, malokto mi povie na rovinu kolko pps znesie ten ktory system atd. Urcite budeme testovat zapozicane kusy od roznych vyrobcov, ale skusenosti z praxe su to co nam neda ani testovanie, ani obchodni zastupcovia...

vdaka

26
Sítě / Re:IPtables a omezení počtu spojení na IP
« kdy: 25. 02. 2013, 22:48:09 »
nevim co mas za problem s connlimit

Citace
   connlimit
       Allows you to restrict the number of parallel connections to a server per client IP address (or client address block).

       --connlimit-upto n
              Match if the number of existing connections is below or equal n.

       --connlimit-above n
              Match if the number of existing connections is above n.

       --connlimit-mask prefix_length
              Group hosts using the prefix length. For IPv4, this must be a number between (including) 0 and 32. For IPv6, between 0 and 128. If not specified, the maximum prefix length for the applicable protocol is used.

       --connlimit-saddr
              Apply the limit onto the source group. This is the default if --connlimit-daddr is not specified.

       --connlimit-daddr
              Apply the limit onto the destination group.
Samozrejme mas pravdu, uz som si to vsimol. blbo som to testoval, chybicka sa vludila...

27
Sítě / IPtables a omezení počtu spojení na IP
« kdy: 25. 02. 2013, 16:55:06 »
Zdravim,
skusil som hladat v tomto fore, ale nenasiel som nic, tak sa pytam...
poznate niekto sposob ako v iptables limitovat pocet aktivnych spojeni podla zdrojovej ip adresy? viem ze existuje connlimit, ale ten limituje len spojenia podla cielovej IP (alebo podsiete). V openBSD by to bolo max-src-conn 100.
vdaka

28
Software / ftpbox?
« kdy: 04. 10. 2011, 10:18:10 »
a co ftpbox? data su na vlastnom serveri, pre widle funguje podobne ako dropbox a mal by byt aj pre android. este som to neskusal, ale z toho co som nasiel sa mi to zda byt asi najlepsia alternativa.

Stran: 1 [2]