eRIZ

Jeśli to to, co myślę, to rozwiązanie jest dość prozaiczne - niech ten plik wypluwa cokolwiek do przeglądarki przed upłynięciem tego timeoutu. Z mojego doświadczenia - serwer wypluwa coś takiego, jeśli interpreter nie zwraca serwerowi zawartości przez podany czas w konfiguracji FastCGI. Możliwe również, że jakaś wtyczka zwyczajnie wykonuje swoje zadanie za długo.

Ew. round-robin, ale pozostaje jeszcze kwestia synchronizacji zbiorów na maszynach, które nie są w tym samym DC, jak w tym przypadku.

Nie kopiowałem w to samo, tylko w ogólnodostępne (binarka nie odwołuje się wewnętrznie do ścieżek bezwzględnych). Problemem było cache'owanie bibliotek przez php-fpm (nie przeładowywałem po dodaniu bibliotek), ale nie wpadłbym na to, gdybyś mnie nie nakierował na przetestowanie via chroot. [: Problem rozwiązany.

Nie do końca. Z tego, co wiem, to w przypadku papierowych dokumentów, musisz je przechowywać przez rok, natomiast elektroniczne - 5 lat. Dlatego firmy "terroryzują" papierami.

Na przeglądarkach bez akceleracji GPU tnie się niemiłosiernie. [;

Nie wysyłaj tego w formularzu. Zrób sobie tabelę z transakcjami i trzymaj to wszystko na serwerze potem się odwołując do odpowiedniego księgowania. Sesja będzie mało istotna, bo ID transakcji (parametr kontrolny też) będzie przesłany przez DotPaya.

Postawiłem sobie środowisko z PHP na FreeBSD via php-fpm z chrootowaniem do katalogu użytkownika. Skompilowałem z obsługą imagick. I tu zaczynają się problemy, bo wykonanie nawet najprostszego kodu: try{ $img = new Imagick('img.jpg'); }catch(ImagickException $ex){ var_dump($ex); } Wysypuje mi całość: object(ImagickException)#2 (7) { ["message":protected]=> string(87) "NoDecodeDelegateForThisImageFormat `magick-VO6fZKY8' @ error/constitute.c/ReadImage/532" ["string":"Exception":private]=> string(0) "" ["code":protected]=> int(1) ["file":protected]=> string(23) "/chroot/script.php" ["line":protected]=> int(8) ["trace":"Exception":private]=> array(1) { [0]=> array(6) { ["file"]=> string(23) "/chroot/script.php" ["line"]=> int(8) ["function"]=> string(11) "__construct" ["class"]=> string(7) "Imagick" ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> string(11) "img.jpg" } } } ["previous":"Exception":private]=> NULL } Ok, myślę sobie, brak odpowiednich libów. ldd na imagick.so, kopiuję biblioteki do /lib względem katalogu "więziennego": cp /usr/local/lib/libMagickWand.so.5 libMagickWand.so.5 cp /usr/local/lib/libMagickCore.so.5 libMagickCore.so.5 cp /lib/libthr.so.3 libthr.so.3 cp /lib/libc.so.7 libc.so.7 cp /usr/local/lib/liblcms2.so.2 liblcms2.so.2 cp /usr/local/lib/libtiff.so.4 libtiff.so.4 cp /usr/lib/liblzma.so.5 liblzma.so.5 cp /usr/local/lib/libjbig.so.1 libjbig.so.1 cp /usr/local/lib/libjpeg.so.11 libjpeg.so.11 cp /usr/local/lib/liblqr-1.so.3 liblqr-1.so.3 cp /usr/local/lib/libglib-2.0.so.0 libglib-2.0.so.0 cp /usr/local/lib/libintl.so.8 libintl.so.8 cp /usr/local/lib/libiconv.so.3 libiconv.so.3 cp /usr/local/lib/libpcre.so.0 libpcre.so.0 cp /usr/local/lib/libfftw3.so.6 libfftw3.so.6 cp /usr/local/lib/libfontconfig.so.1 libfontconfig.so.1 cp /usr/local/lib/libfreetype.so.9 libfreetype.so.9 cp /usr/local/lib/libexpat.so.6 libexpat.so.6 cp /usr/lib/libbz2.so.4 libbz2.so.4 cp /lib/libz.so.5 libz.so.5 cp /usr/local/lib/libltdl.so.7 libltdl.so.7 cp /lib/libm.so.5 libm.so.5 Niestety, skutek jest identyczny - wysypuje wyjątek, choć wszystkie biblioteki są (a przynajmniej powinny być) dostępne. Poguglałem, niestety - nic interesującego nie znalazłem, a mi pomysły się już skończyły. -- edit: ścieżki do obrazka, ale w rzeczywistym środowisku są ok.

Jaki silnik bazy? Która wersja MySQL? Próbowałeś zdumpować bazy do SQL, wyczyścić dane demona i je ponownie zaimportować?

Ale dzisiaj mamy (jeszcze) poniedziałek. ;p Na moje oko, to kontynuacja tego, co miało miejsce w ostatnich dniach - chyba że masowy pad kart sieciowych na ostatnich węzłach, ale jakoś mi to nie pasi w kontekście powyższego. -- edit: Maszyny odżyły.

Z tego pingi mi mówią, to chyba znowu DDoS: 2 1 ms 1 ms 1 ms 192.168.10.1 3 1 ms 1 ms 1 ms 192.168.252.1 4 1 ms 1 ms 1 ms gw1.rz.izeto.pl [91.192.165.129] 5 1 ms 1 ms 1 ms main-gw.rz.izeto.pl [91.192.165.1] 6 17 ms 17 ms 17 ms TKPSA.plix.pl [195.182.218.29] 7 17 ms 17 ms 17 ms kat-jor-r1.3s.pl [85.14.102.77] 8 2003 ms 2003 ms 1993 ms unix-storm-r.3s.pl [85.14.85.238] 9 1956 ms * * k3.unixstorm.org [91.227.122.8] 10 1973 ms 1986 ms * k3.unixstorm.org [91.227.122.8] 11 1970 ms * * k3.unixstorm.org [91.227.122.8] 12 * * * Request timed out. 13 1974 ms * * k3.unixstorm.org [91.227.122.8] 14 1980 ms * * k3.unixstorm.org [91.227.122.8] 15 2008 ms * * k3.unixstorm.org [91.227.122.8] 16 2037 ms * 2030 ms k3.unixstorm.org [91.227.122.8] 2 1 ms 1 ms 1 ms 192.168.10.1 3 1 ms 1 ms 1 ms 192.168.252.1 4 1 ms 1 ms 1 ms gw1.rz.izeto.pl [91.192.165.129] 5 1 ms 1 ms 1 ms main-gw.rz.izeto.pl [91.192.165.1] 6 17 ms 17 ms 17 ms TKPSA.plix.pl [195.182.218.29] 7 17 ms 17 ms 17 ms kat-jor-r1.3s.pl [85.14.102.77] 8 * * * Request timed out. 9 * * * Request timed out. 10 2059 ms 2062 ms 2052 ms k3.unixstorm.org [91.227.122.8]

Niestety, też leżała. Hmm, pamiętam że wczoraj też miałem problemy w godzinach popołudniowych... k3 wstał.

Potwierdzam, zdechł. Wczoraj działo się to samo, w identycznych godzinach. DDoS? Z Crowleya gubi większość pakietów, z OVH w Bordeaux to samo.

Powiedzenie, że ilość kodu powodująca problem jest odwrotnie proporcjonalna do jego powagi jednak jest istotne. Znalazłem przyczynę - po 5 dniach walki i 3 grzebania w źródłach. Problemem był chroot i ścieżka bezwzględna jako SCRIPT_FILENAME miast względem chrootowanego katalogu. Dzięki za poświęcony czas.

Kolejny dzień roztrzaskiwania mojego mózgu o dziwny problem. Do czego udało mi się dotrzeć. W pliku fpm_main.c jest odwołanie do: /* path_translated exists, we can continue ! */ if (php_fopen_primary_script(&file_handle TSRMLS_CC) == FAILURE) { Owszem, zwraca failure. Ale najciekawszy jest powód błędu: zlog(ZLOG_NOTICE, "WTF: %d", errno); zlog, to wbudowana funkcja do rzucania błędami do konsoli, jeśli php-fpm ma wyłączone w konfiguracji daemonize. Po wykonaniu żądania dla wyłączonego cgi.fix_pathinfo ta zmienna ma wartość errno = 2. Wyczytałem w Sieci, że taki kod jest zwracany, gdy poszukiwany plik nie istnieje (nie żaden brak uprawnień, czy coś; po prostu nie istnieje). Idąc dalej php_fopen_primary_script siedzi w fopen_wrappers.c i zwraca status FAILURE w kilku przypadkach. W moim przypadku sypie z tego powodu: if (filename) { resolved_path = zend_resolve_path(filename, strlen(filename) TSRMLS_CC); } resolved_path jest po prostu... puste. Co powoduje wysypanie następującego warunku: f (!resolved_path) { if (SG(request_info).path_translated != filename) { STR_FREE(filename); } /* we have to free SG(request_info).path_translated here because * php_destroy_request_info assumes that it will get * freed when the include_names hash is emptied, but * we're not adding it in this case */ STR_FREE(SG(request_info).path_translated); SG(request_info).path_translated = NULL; fprintf(stderr, "plecy3\n"); return FAILURE; } Dobierając się dalej: zend_resolve_path to tak naprawdę łańcuszek do php_resolve_path. Namierzyłem dziwny punkt: if ((*filename == '.' && (IS_SLASH(filename[1]) || ((filename[1] == '.') && IS_SLASH(filename[2])))) || IS_ABSOLUTE_PATH(filename, filename_length) || !path || !*path) { if (tsrm_realpath(filename, resolved_path TSRMLS_CC)) { return estrdup(resolved_path); } else { fprintf(stderr, "resolve plecy4: TSRM: %s, resolved_path: %s\n", tsrm_realpath(filename, resolved_path TSRMLS_CC), resolved_path); return NULL; } } Thread Safe Resource Manager - nie wiem, po kiego grzyba coś takiego, ale niech będzie; w pliku TSRM/tsrm_virtual_cwd.c siedzi to dziadostwo. Jest stałą debugująca, która pozwala na dumpowanie do stderr każdego etapu wyciągania. Po jej włączeniu i przekompilowaniu interpretera na starcie otrzymuję: cwd = path = /usr/local/sbin/php-fpm virtual_file_ex() = /root/php5.3-201108181230/sapi/fpm/php-fpm cwd = path = /usr/local/etc/php.ini virtual_file_ex() = /usr/local/etc/php.ini a dla plików puszczonych via FCGI: cwd = path = /sciezka/index.php Czyli powinno to coś działać. Ale nie działa. Funkcja tsrm_realpath stopuje na: if (virtual_file_ex(&new_state, path, NULL, CWD_REALPATH)) { free(new_state.cwd); return NULL; } Tylko nie wiem, dlaczego... Przecież ścieżka jest prawidłowa i dostępna...

Znalazłem coś takiego: if (!ptr) { /* * if we stripped out all the '/' and still didn't find * a valid path... we will fail, badly. of course we would * have failed anyway... we output 'no input file' now. */ if (orig_script_filename) { _sapi_cgibin_putenv("ORIG_SCRIPT_FILENAME", orig_script_filename TSRMLS_CC); } script_path_translated = _sapi_cgibin_putenv("SCRIPT_FILENAME", NULL TSRMLS_CC); SG(sapi_headers).http_response_code = 404; } Dobrze kopię?