From pld w sojka.co Wed Sep 16 21:29:16 2015 From: pld w sojka.co (=?ISO-8859-2?Q?Grzegorz_S=F3jka?=) Date: Wed, 16 Sep 2015 21:29:16 +0200 Subject: Can't open display Message-ID: <55F9C30C.7010404@sojka.co> Witam serdecznie, Od jakiegoś czasu mam problem ze zdalnym odpalaniem aplikacji X'owych. W skrócie: $ export DISPLAY=localhost:0.0 $ xhost +localhost $ xterm xterm: Xt error: Can't open display: localhost:0.0 Ma ktoś jakieś pomysły? -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa. From adwol w zonk.pl Wed Sep 16 22:09:31 2015 From: adwol w zonk.pl (Adam Osuchowski) Date: Wed, 16 Sep 2015 22:09:31 +0200 Subject: Can't open display In-Reply-To: <55F9C30C.7010404@sojka.co> References: <55F9C30C.7010404@sojka.co> Message-ID: <20150916200931.6b8b4567@zonk.pl> Grzegorz Sójka wrote: > Od jakiegoś czasu mam problem ze zdalnym odpalaniem aplikacji X'owych. W > skrócie: > > $ export DISPLAY=localhost:0.0 > $ xhost +localhost > $ xterm > xterm: Xt error: Can't open display: localhost:0.0 > > Ma ktoś jakieś pomysły? A działa Ci z DISPLAY=:0.0 ? Może nie masz serwera Xów odpalonego na sockecie inetowym (np. odpalasz go z opcją `-nolisten tcp'). Puść strace'a i zobacz czy w ogóle się łączy: $ strace -e trace=connect -E DISPLAY=localhost:0.0 xterm From bszx-pld w bszx.eu Mon Sep 21 11:04:22 2015 From: bszx-pld w bszx.eu (Bartek Szady) Date: Mon, 21 Sep 2015 11:04:22 +0200 Subject: Nie =?UTF-8?B?c3RhcnR1asSFY3kgbnRwZA==?= Message-ID: <55FFC816.7000407@bszx.eu> Witam Po ostatnim upgrade do aktualnych wersji (+kernel 4.1.7, własna kompilacja) przestał startować ntpd. Dzieje się tak z ntpd-4.2.8-4 i ntpd-4.2.8p3-2. Według strace ntpd ginie z powodu braku pamięci. Ustawia limit na 32MB i alokuje więcej. Zaczął działać po przekompilowaniu z --with-memlock=256 Pozdrawiam Bartek From josiecki w silvercube.pl Mon Sep 21 15:42:30 2015 From: josiecki w silvercube.pl (Jacek Osiecki) Date: Mon, 21 Sep 2015 15:42:30 +0200 Subject: =?utf-8?Q?Re=3A_php55-fpm_-_kiedy_b=C4=99dzie_dzia=C5=82a=C4=87?= =?utf-8?Q?=3F?= In-Reply-To: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> References: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> Message-ID: Witam, Albo nie widzę, albo faktycznie nikt nie odpisał. Czy w ogóle nikt tutaj nie używa php-fpm? Świeżo stworzony vserver, wrzucone do niego php55, w tym php55-fpm. Uruchomienie vservera wygląda tak: Starting PHP FastCGI Process Manager (php55-fpm) service......................................................................................................................................[ BUSY ]*** Error in `/usr/sbin/php55-fpm': free(): invalid pointer: 0x00007f15187e8060 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7226e)[0x7f151629926e] /lib64/libc.so.6(+0x7774e)[0x7f151629e74e] /lib64/libc.so.6(+0x77f2b)[0x7f151629ef2b] /usr/lib64/libphp_common-5.5.28.so(php_shutdown_config+0x21)[0x7f15181e53c1] /usr/lib64/libphp_common-5.5.28.so(php_module_shutdown+0x3e)[0x7f15181de9de] /usr/sbin/php55-fpm[0x4121a9] /usr/sbin/php55-fpm(fpm_cleanups_run+0x56)[0x40b396] /usr/sbin/php55-fpm(fpm_unix_init_main+0x621)[0x418041] /usr/sbin/php55-fpm(fpm_init+0x6c)[0x40a5dc] /usr/sbin/php55-fpm(main+0x6a4)[0x407204] /lib64/libc.so.6(__libc_start_main+0xf0)[0x7f1516247860] /usr/sbin/php55-fpm(_start+0x29)[0x408509] ======= Memory map: ======== 00400000-00424000 r-xp 00000000 09:04 257794 /usr/sbin/php55-fpm 00623000-00626000 rw-p 00023000 09:04 257794 /usr/sbin/php55-fpm 01a4e000-01ce3000 rw-p 00000000 00:00 0 [heap] 7f1505029000-7f1505034000 r-xp 00000000 09:04 254457 /lib64/libnss_files-2.21.so 7f1505034000-7f1505234000 ---p 0000b000 09:04 254457 /lib64/libnss_files-2.21.so 7f1505234000-7f1505235000 r--p 0000b000 09:04 254457 /lib64/libnss_files-2.21.so 7f1505235000-7f1505236000 rw-p 0000c000 09:04 254457 /lib64/libnss_files-2.21.so 7f1508fe6000-7f1508fed000 r-xp 00000000 09:04 255358 /usr/lib64/libffi.so.6.0.4 7f1508fed000-7f15091ed000 ---p 00007000 09:04 255358 /usr/lib64/libffi.so.6.0.4 7f15091ed000-7f15091ee000 r--p 00007000 09:04 255358 /usr/lib64/libffi.so.6.0.4 7f15091ee000-7f15091ef000 rw-p 00008000 09:04 255358 /usr/lib64/libffi.so.6.0.4 7f150ad30000-7f150ad7f000 r-xp 00000000 09:04 257581 /usr/lib64/libgobject-2.0.so.0.4400.1 7f150ad7f000-7f150af7f000 ---p 0004f000 09:04 257581 /usr/lib64/libgobject-2.0.so.0.4400.1 7f150af7f000-7f150af80000 r--p 0004f000 09:04 257581 /usr/lib64/libgobject-2.0.so.0.4400.1 7f150af80000-7f150af81000 rw-p 00050000 09:04 257581 /usr/lib64/libgobject-2.0.so.0.4400.1 7f1510443000-7f151054e000 r-xp 00000000 09:04 257579 /usr/lib64/libglib-2.0.so.0.4400.1 7f151054e000-7f151074d000 ---p 0010b000 09:04 257579 /usr/lib64/libglib-2.0.so.0.4400.1 7f151074d000-7f151074e000 r--p 0010a000 09:04 257579 /usr/lib64/libglib-2.0.so.0.4400.1 7f151074e000-7f151074f000 rw-p 0010b000 09:04 257579 /usr/lib64/libglib-2.0.so.0.4400.1 7f151074f000-7f1510750000 rw-p 00000000 00:00 0 7f1515d91000-7f1515d96000 rw-p 00000000 00:00 0 7f1515d96000-7f1515dac000 r-xp 00000000 09:04 257216 /lib64/libgcc_s.so.1 7f1515dac000-7f1515fab000 ---p 00016000 09:04 257216 /lib64/libgcc_s.so.1 7f1515fab000-7f1515fac000 rw-p 00015000 09:04 257216 /lib64/libgcc_s.so.1 7f1515fac000-7f1516021000 r-xp 00000000 09:04 255019 /lib64/libfreebl3.so 7f1516021000-7f1516221000 ---p 00075000 09:04 255019 /lib64/libfreebl3.so 7f1516221000-7f1516223000 rw-p 00075000 09:04 255019 /lib64/libfreebl3.so 7f1516223000-7f1516227000 rw-p 00000000 00:00 0 7f1516227000-7f15163c3000 r-xp 00000000 09:04 254443 /lib64/libc-2.21.so 7f15163c3000-7f15165c3000 ---p 0019c000 09:04 254443 /lib64/libc-2.21.so 7f15165c3000-7f15165c7000 r--p 0019c000 09:04 254443 /lib64/libc-2.21.so 7f15165c7000-7f15165c9000 rw-p 001a0000 09:04 254443 /lib64/libc-2.21.so 7f15165c9000-7f15165cd000 rw-p 00000000 00:00 0 7f15165cd000-7f15165e5000 r-xp 00000000 09:04 254459 /lib64/libpthread-2.21.so 7f15165e5000-7f15167e4000 ---p 00018000 09:04 254459 /lib64/libpthread-2.21.so 7f15167e4000-7f15167e5000 r--p 00017000 09:04 254459 /lib64/libpthread-2.21.so 7f15167e5000-7f15167e6000 rw-p 00018000 09:04 254459 /lib64/libpthread-2.21.so 7f15167e6000-7f15167eb000 rw-p 00000000 00:00 0 7f15167eb000-7f1516800000 r-xp 00000000 09:04 254918 /lib64/libz.so.1.2.8 7f1516800000-7f15169ff000 ---p 00015000 09:04 254918 /lib64/libz.so.1.2.8 7f15169ff000-7f1516a00000 rw-p 00014000 09:04 254918 /lib64/libz.so.1.2.8 7f1516a00000-7f1516a24000 r-xp 00000000 09:04 254969 /lib64/liblzma.so.5.2.1 7f1516a24000-7f1516c24000 ---p 00024000 09:04 254969 /lib64/liblzma.so.5.2.1 7f1516c24000-7f1516c25000 r--p 00024000 09:04 254969 /lib64/liblzma.so.5.2.1 7f1516c25000-7f1516c26000 rw-p 00025000 09:04 254969 /lib64/liblzma.so.5.2.1 7f1516c26000-7f1516d7e000 r-xp 00000000 09:04 257212 /usr/lib64/libxml2.so.2.9.2 7f1516d7e000-7f1516f7e000 ---p 00158000 09:04 257212 /usr/lib64/libxml2.so.2.9.2 7f1516f7e000-7f1516f87000 r--p 00158000 09:04 257212 /usr/lib64/libxml2.so.2.9.2 7f1516f87000-7f1516f89000 rw-p 00161000 09:04 257212 /usr/lib64/libxml2.so.2.9.2 7f1516f89000-7f1516f8b000 rw-p 00000000 00:00 0 7f1516f8b000-7f1516f92000 r-xp 00000000 09:04 254463 /lib64/librt-2.21.so 7f1516f92000-7f1517191000 ---p 00007000 09:04 254463 /lib64/librt-2.21.so 7f1517191000-7f1517192000 r--p 00006000 09:04 254463 /lib64/librt-2.21.so 7f1517192000-7f1517193000 rw-p 00007000 09:04 254463 /lib64/librt-2.21.so 7f1517193000-7f1517280000 r-xp 00000000 09:04 257350 /usr/lib64/libstdc++.so.6.0.20 7f1517280000-7f151747f000 ---p 000ed000 09:04 257350 /usr/lib64/libstdc++.so.6.0.20 7f151747f000-7f1517487000 r--p 000ec000 09:04 257350 /usr/lib64/libstdc++.so.6.0.20 7f1517487000-7f1517489000 rw-p 000f4000 09:04 257350 /usr/lib64/libstdc++.so.6.0.20 7f1517489000-7f151749e000 rw-p 00000000 00:00 0 7f151749e000-7f15174b2000 r-xp 00000000 09:04 254461 /lib64/libresolv-2.21.so 7f15174b2000-7f15176b1000 ---p 00014000 09:04 254461 /lib64/libresolv-2.21.so 7f15176b1000-7f15176b3000 r--p 00013000 09:04 254461 /lib64/libresolv-2.21.so 7f15176b3000-7f15176b4000 rw-p 00015000 09:04 254461 /lib64/libresolv-2.21.so 7f15176b4000-7f15176b6000 rw-p 00000000 00:00 0 7f15176b6000-7f1517724000 r-xp 00000000 09:04 254402 /lib64/libpcre.so.1.2.5 7f1517724000-7f1517923000 ---p 0006e000 09:04 254402 /lib64/libpcre.so.1.2.5 7f1517923000-7f1517925000 r--p 0006d000 09:04 254402 /lib64/libpcre.so.1.2.5 7f1517925000-7f1517926000 rw-p 0006f000 09:04 254402 /lib64/libpcre.so.1.2.5 7f1517926000-7f1517928000 r-xp 00000000 09:04 254447 /lib64/libdl-2.21.so 7f1517928000-7f1517b28000 ---p 00002000 09:04 254447 /lib64/libdl-2.21.so 7f1517b28000-7f1517b29000 r--p 00002000 09:04 254447 /lib64/libdl-2.21.so 7f1517b29000-7f1517b2a000 rw-p 00003000 09:04 254447 /lib64/libdl-2.21.so 7f1517b2a000-7f1517c2e000 r-xp 00000000 09:04 254449 /lib64/libm-2.21.so 7f1517c2e000-7f1517e2d000 ---p 00104000 09:04 254449 /lib64/libm-2.21.so 7f1517e2d000-7f1517e2e000 r--p 00103000 09:04 254449 /lib64/libm-2.21.so 7f1517e2e000-7f1517e2f000 rw-p 00104000 09:04 254449 /lib64/libm-2.21.so 7f1517e2f000-7f1517e3a000 r-xp 00000000 09:04 255578 /lib64/libcrypt-2.21.so 7f1517e3a000-7f1518039000 ---p 0000b000 09:04 255578 /lib64/libcrypt-2.21.so 7f1518039000-7f151803a000 r--p 0000a000 09:04 255578 /lib64/libcrypt-2.21.so 7f151803a000-7f151803b000 rw-p 0000b000 09:04 255578 /lib64/libcrypt-2.21.so 7f151803b000-7f1518069000 rw-p 00000000 00:00 0 7f1518069000-7f1518374000 r-xp 00000000 09:04 257536 /usr/lib64/libphp_common-5.5.28.so 7f1518374000-7f1518574000 ---p 0030b000 09:04 257536 /usr/lib64/libphp_common-5.5.28.so 7f1518574000-7f15185f6000 rw-p 0030b000 09:04 257536 /usr/lib64/libphp_common-5.5.28.so 7f15185f6000-7f151860f000 rw-p 00000000 00:00 0 7f151860f000-7f1518631000 r-xp 00000000 09:04 254436 /lib64/ld-2.21.so 7f1518696000-7f15186e5000 rw-p 00000000 00:00 0 7f15187e6000-7f151882b000 rw-p 00000000 00:00 0 7f151882e000-7f1518830000 rw-p 00000000 00:00 0 7f1518830000-7f1518831000 r--p 00021000 09:04 254436 /lib64/ld-2.21.so 7f1518831000-7f1518832000 rw-p 00022000 09:04 254436 /lib64/ld-2.21.so 7f1518832000-7f1518833000 rw-p 00000000 00:00 0 7fffc5da6000-7fffc5dc7000 rw-p 00000000 00:00 0 [stack] 7fffc5dcd000-7fffc5dce000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] [ FAIL ] Starting nginx (standard) service.............................................................................................................................................................[ DONE ] Wszystko aktualne. Jakieś sugestie? Pozdrawiam, -- Jacek Osiecki josiecki w silvercube.pl Silvercube s.c. ul. Makuszynskiego 4 31-752 Kraków +48 (12) 684 21 00 From adwol w zonk.pl Mon Sep 21 15:59:21 2015 From: adwol w zonk.pl (Adam Osuchowski) Date: Mon, 21 Sep 2015 15:59:21 +0200 Subject: php55-fpm - kiedy =?iso-8859-2?B?Yupk?= =?iso-8859-2?B?emllIGR6aWGzYeY/?= In-Reply-To: References: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> Message-ID: <20150921135921.6b8b4567@zonk.pl> Jacek Osiecki wrote: > Albo nie widzę, albo faktycznie nikt nie odpisał. > Czy w ogóle nikt tutaj nie używa php-fpm? > Świeżo stworzony vserver, wrzucone do niego php55, w tym php55-fpm. Problem jest też z PHP 5.6 i chyba jest powiązany z grsecurity w kernelu (chyba, że u Ciebie występuje na nie-grsecowym). Mnie pomaga patch (w załączniku), którego sobie sam wystrugałem na własne potrzeby ale nie wiem czy należałoby go pchać do repozytorium. Co do problemu, to wg mnie wygląda to tak. Pamięć, która jest zwalniana przez to zakomentowane free() jest alokowana przez emalloc() (wewnętrzna funkcja php do zarządzania pamięcią). Powinna więc być zwolniona przez efree() ponieważ te funkcje emalloc(), efree, estrdup() itd. dodają sobie swoje własne sygnatury alokowanych kawałków i trzymają je dodatkowo w jakimś drzewie. Użycie free() w tym miejscu jest chyba pomyłką. Ale pomimo zmiany tego na efree() nadal nic to nie pomogło. Przeanalizowałem jeszcze trochę kodu ale w końcu skończyła mi się cierpliwość i czas i to zakomentowałem w całości. Wiem, że w ten sposób powataje memory leak ale IMHO jest niegroźny gdyż to jest wołane w funkcji php_shutdown_config(), która jest z kolei wołana przy kończeniu się procesu php. Memory leak jest więc w zasadzie czysto teoretyczny i tylko podczas kończenia działania, a nie podczas normalnej pracy. Jeżeli nie ma przeciwwskazań do zaaplikowania takiego bądź co bądź partyzanckiego patcha to mogę go wsadzić do repozytorium. -------------- następna część --------- diff -ruNp php-5.6.13.orig/main/php_ini.c php-5.6.13/main/php_ini.c --- php-5.6.13.orig/main/php_ini.c 2015-09-03 02:02:45.000000000 +0200 +++ php-5.6.13/main/php_ini.c 2015-09-18 12:55:56.454284557 +0200 @@ -726,7 +726,7 @@ int php_shutdown_config(void) { zend_hash_destroy(&configuration_hash); if (php_ini_opened_path) { - free(php_ini_opened_path); +// free(php_ini_opened_path); php_ini_opened_path = NULL; } if (php_ini_scanned_files) { From admin w xbtmusic.org Mon Sep 21 16:07:51 2015 From: admin w xbtmusic.org (pedro) Date: Mon, 21 Sep 2015 16:07:51 +0200 Subject: =?UTF-8?Q?Re:_php55-fpm_-_kiedy_b=c4=99dzie_dzia=c5=82a=c4=87=3f?= In-Reply-To: References: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> Message-ID: <56000F37.7010606@xbtmusic.org> W dniu 2015-09-21 o 15:42, Jacek Osiecki pisze: > Witam, > > Albo nie widzę, albo faktycznie nikt nie odpisał. > Czy w ogóle nikt tutaj nie używa php-fpm? > Świeżo stworzony vserver, wrzucone do niego php55, w tym php55-fpm. > Uruchomienie vservera wygląda tak: > > .......... > Wszystko aktualne. > > Jakieś sugestie? Brak :p > > Pozdrawiam, > Ja przez to jestem zmuszony używać ostatniego działającego (przynajmniej więcej nie szukałem) z nginxem, czyli 5.5.21-3.x86_64... Pozdrawiam From josiecki w silvercube.pl Mon Sep 21 16:25:15 2015 From: josiecki w silvercube.pl (Jacek Osiecki) Date: Mon, 21 Sep 2015 16:25:15 +0200 Subject: =?windows-1250?Q?Re=3A_php55-fpm_-_kiedy_b=EAdzie_dzia=B3a=E6=3F?= In-Reply-To: <56000F37.7010606@xbtmusic.org> References: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> <56000F37.7010606@xbtmusic.org> Message-ID: <28683894-9A48-455C-9C85-01C7DB639FE0@silvercube.pl> Wiadomość napisana przez pedro w dniu 21 wrz 2015, o godz. 16:07: >> Jakieś sugestie? > > Brak :p > > Ja przez to jestem zmuszony używać ostatniego działającego (przynajmniej > więcej nie szukałem) z nginxem, czyli 5.5.21-3.x86_64? O, to chyba najlepszy trop. Tylko mam problem przy instalacji - krzyczy mi o libicudata.so.54 - tymczasem widzę że na FTP jest libicu55, natomiast wersji wcześniejszej? ani śladu na archive :( Możesz sprawdzić skąd pochodzi u Ciebie ta biblioteka? Pozdrawiam, -- Jacek Osiecki josiecki w silvercube.pl Silvercube s.c. ul. Makuszynskiego 4 31-752 Kraków +48 (12) 684 21 00 From admin w xbtmusic.org Mon Sep 21 17:04:23 2015 From: admin w xbtmusic.org (pedro) Date: Mon, 21 Sep 2015 17:04:23 +0200 Subject: =?UTF-8?Q?Re:_php55-fpm_-_kiedy_b=c4=99dzie_dzia=c5=82a=c4=87=3f?= In-Reply-To: <28683894-9A48-455C-9C85-01C7DB639FE0@silvercube.pl> References: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> <56000F37.7010606@xbtmusic.org> <28683894-9A48-455C-9C85-01C7DB639FE0@silvercube.pl> Message-ID: <56001C77.3000805@xbtmusic.org> Hmmm, interesujące: [root w mel /]# rpm -qf /usr/lib64/libicudata* libicu-devel-55.1-1.x86_64 libicu-55.1-1.x86_64 libicu-55.1-1.x86_64 Nic nie było robione na siłę, po prostu php nie było apdejtowane cały czas, jest tak na 2 maszynach. Więc ciekawostka :P W dniu 2015-09-21 o 16:25, Jacek Osiecki pisze: > Wiadomość napisana przez pedro w dniu 21 wrz 2015, o godz. 16:07: > >>> Jakieś sugestie? >> >> Brak :p >> >> Ja przez to jestem zmuszony używać ostatniego działającego (przynajmniej >> więcej nie szukałem) z nginxem, czyli 5.5.21-3.x86_64? > > O, to chyba najlepszy trop. > Tylko mam problem przy instalacji - krzyczy mi o libicudata.so.54 - tymczasem widzę że na FTP > jest libicu55, natomiast wersji wcześniejszej? ani śladu na archive :( > Możesz sprawdzić skąd pochodzi u Ciebie ta biblioteka? > > Pozdrawiam, > From josiecki w silvercube.pl Mon Sep 21 17:25:01 2015 From: josiecki w silvercube.pl (Jacek Osiecki) Date: Mon, 21 Sep 2015 17:25:01 +0200 Subject: =?windows-1250?Q?Re=3A_php55-fpm_-_kiedy_b=EAdzie_dzia=B3a=E6=3F?= In-Reply-To: <56001C77.3000805@xbtmusic.org> References: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> <56000F37.7010606@xbtmusic.org> <28683894-9A48-455C-9C85-01C7DB639FE0@silvercube.pl> <56001C77.3000805@xbtmusic.org> Message-ID: > Wiadomość napisana przez pedro w dniu 21 wrz 2015, o godz. 17:04: > > Hmmm, interesujące: > > [root w mel /]# rpm -qf /usr/lib64/libicudata* > libicu-devel-55.1-1.x86_64 > libicu-55.1-1.x86_64 > libicu-55.1-1.x86_64 No to teraz zgłupiałem: libicudata.so.54()(64bit) jest wymagany przez php55-intl-5.5.21-3.x86_64 A tam jest zainstalowane libicu-55.1-1, w nim zaś tylko libicudata.so.55 Co Ci pokazuje: rpm -qi --requires php55-intl-5.5.21-3 rpm -V php55-intl-5.5.21-3 Bo coś tu jest mocno nie tak :( Pozdrawiam, -- Jacek Osiecki josiecki w silvercube.pl Silvercube s.c. ul. Makuszynskiego 4 31-752 Kraków +48 (12) 684 21 00 From admin w xbtmusic.org Mon Sep 21 18:22:01 2015 From: admin w xbtmusic.org (pedro) Date: Mon, 21 Sep 2015 18:22:01 +0200 Subject: =?UTF-8?Q?Re:_php55-fpm_-_kiedy_b=c4=99dzie_dzia=c5=82a=c4=87=3f?= In-Reply-To: References: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> <56000F37.7010606@xbtmusic.org> <28683894-9A48-455C-9C85-01C7DB639FE0@silvercube.pl> <56001C77.3000805@xbtmusic.org> Message-ID: <56002EA9.1000204@xbtmusic.org> W dniu 2015-09-21 o 17:25, Jacek Osiecki pisze: >> Wiadomość napisana przez pedro w dniu 21 wrz 2015, o godz. 17:04: >> >> Hmmm, interesujące: >> >> [root w mel /]# rpm -qf /usr/lib64/libicudata* >> libicu-devel-55.1-1.x86_64 >> libicu-55.1-1.x86_64 >> libicu-55.1-1.x86_64 > > No to teraz zgłupiałem: > > libicudata.so.54()(64bit) jest wymagany przez php55-intl-5.5.21-3.x86_64 > > A tam jest zainstalowane libicu-55.1-1, w nim zaś tylko libicudata.so.55 > > Co Ci pokazuje: > > rpm -qi --requires php55-intl-5.5.21-3 > rpm -V php55-intl-5.5.21-3 > > Bo coś tu jest mocno nie tak :( > > Pozdrawiam, > Ja nie mam w ogóle zainstalowanego php55-intl-5.5.21-3 Pewnie dlatego. Pozdrawiam From josiecki w silvercube.pl Mon Sep 21 18:30:47 2015 From: josiecki w silvercube.pl (Jacek Osiecki) Date: Mon, 21 Sep 2015 18:30:47 +0200 Subject: =?iso-8859-2?Q?Re=3A_php55-fpm_-_kiedy_b=EAdzie_dzia=B3a=E6=3F?= In-Reply-To: References: <09A6A687-7AF3-4D57-8368-79944D516D44@silvercube.pl> <56000F37.7010606@xbtmusic.org> <28683894-9A48-455C-9C85-01C7DB639FE0@silvercube.pl> <56001C77.3000805@xbtmusic.org> Message-ID: <5D359BE2-2F32-4EAB-89BE-B2A2F73034B2@silvercube.pl> Wiadomość napisana przez Jacek Osiecki w dniu 21 wrz 2015, o godz. 17:25: > >> Wiadomość napisana przez pedro w dniu 21 wrz 2015, o godz. 17:04: >> >> Hmmm, interesujące: >> >> [root w mel /]# rpm -qf /usr/lib64/libicudata* >> libicu-devel-55.1-1.x86_64 >> libicu-55.1-1.x86_64 >> libicu-55.1-1.x86_64 > > No to teraz zgłupiałem: > > libicudata.so.54()(64bit) jest wymagany przez php55-intl-5.5.21-3.x86_64 > > A tam jest zainstalowane libicu-55.1-1, w nim zaś tylko libicudata.so.55 > > Co Ci pokazuje: > > rpm -qi --requires php55-intl-5.5.21-3 > rpm -V php55-intl-5.5.21-3 > > Bo coś tu jest mocno nie tak :( Mam wrażenie że generalnie .archive się popsuło i nie wpadają tam pakiety :( Widzę gdzieś na starych serwerach libicu-52, na ftp jest libicu-55, niestety libicu-54 ani śladu :( Ma ktoś, może podrzucić? Pozdrawiam, -- Jacek Osiecki josiecki w silvercube.pl Silvercube s.c. ul. Makuszynskiego 4 31-752 Kraków +48 (12) 684 21 00 From fvk w net-arena.pl Tue Sep 22 12:12:04 2015 From: fvk w net-arena.pl (Radek Pilawka) Date: Tue, 22 Sep 2015 12:12:04 +0200 Subject: exim tls problem Message-ID: <76d7afec1be922518e9f473c0bea8319@interarena.pl> Witam. Po upgrade do wersji exim-4.86-1 przestał wysyłać pocztę. W logach: T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x7f00: exit code 127 /var/log/exim/main.log:2015-09-22 11:59:02 1ZeKLm-0000oP-7Q Frozen W trybie debug: /usr/bin/exim: symbol lookup error: /usr/bin/exim: undefined symbol: X509_check_host Pozdrawiam -- Radek Pilawka From arekm w maven.pl Tue Sep 22 12:25:44 2015 From: arekm w maven.pl (Arkadiusz =?iso-8859-2?q?Mi=B6kiewicz?=) Date: Tue, 22 Sep 2015 12:25:44 +0200 Subject: exim tls problem In-Reply-To: <76d7afec1be922518e9f473c0bea8319@interarena.pl> References: <76d7afec1be922518e9f473c0bea8319@interarena.pl> Message-ID: <201509221225.44512.arekm@maven.pl> On Tuesday 22 of September 2015, Radek Pilawka wrote: > Witam. > > Po upgrade do wersji exim-4.86-1 przestał wysyłać pocztę. > W logach: > > T=remote_smtp defer (-1): smtp transport process returned non-zero > status 0x7f00: exit code 127 > /var/log/exim/main.log:2015-09-22 11:59:02 1ZeKLm-0000oP-7Q Frozen > > W trybie debug: > > /usr/bin/exim: symbol lookup error: /usr/bin/exim: undefined symbol: > X509_check_host upgradnij openssl Trzeba by dać zależność chyba... -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) From pld w sojka.co Wed Sep 23 17:50:42 2015 From: pld w sojka.co (=?ISO-8859-2?Q?Grzegorz_S=F3jka?=) Date: Wed, 23 Sep 2015 17:50:42 +0200 Subject: Can't open display In-Reply-To: <20150916200931.6b8b4567@zonk.pl> References: <55F9C30C.7010404@sojka.co> <20150916200931.6b8b4567@zonk.pl> Message-ID: <5602CA52.7080904@sojka.co> On 09/16/15 22:09, Adam Osuchowski wrote: > Grzegorz Sójka wrote: >> Od jakiegoś czasu mam problem ze zdalnym odpalaniem aplikacji X'owych. W >> skrócie: >> >> $ export DISPLAY=localhost:0.0 >> $ xhost +localhost >> $ xterm >> xterm: Xt error: Can't open display: localhost:0.0 >> >> Ma ktoś jakieś pomysły? > > A działa Ci z DISPLAY=:0.0 ? Może nie masz serwera Xów odpalonego na > sockecie inetowym (np. odpalasz go z opcją `-nolisten tcp'). Puść Trafiony! Teraz domyślnie Xserwer nie nasłuchuje po TCP. Jak odpalę startx -- -listen tcp to wszystko jest ok. Da się to jakoś w configi wpisać (nie mam żadnego *DM'a, w zasadzie tylko xorg.conf)?? -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa. From baggins w pld-linux.org Fri Sep 25 08:25:57 2015 From: baggins w pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Fri, 25 Sep 2015 08:25:57 +0200 Subject: Kernel 3.4 removal Message-ID: <20150925062557.GA3861@home.lan> The 3.4 longterm kernel line has reached the end of maintainablity and usability for us. I will not update it, and I will remove it from Th-main soon. Old packages will be available in th-archive. -- Jan Rękorajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From masko w ipipan.waw.pl Mon Sep 28 14:33:19 2015 From: masko w ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=) Date: Mon, 28 Sep 2015 14:33:19 +0200 Subject: Po aktualizacji systemd do 221-7 nie =?UTF-8?B?ZHppYcWCYSBvYnPFgnVnYSBkeXNrw7N3?= po etykietach Message-ID: <2361571.OGRkPm6xn0@geralt> Witam. Po ostatniej aktualizacji systemd do wersji 221-7 (i686) system przestał mi obsługiwać na starcie partycje podane przez etykiety. W fstab miałem label=root zamiast /dev/sda2 i działało. A teraz już nie. Przy starcie wykłada usługa systemd-fsck w dev-disk-by/x2dlabel-temp.service, co widać w zrzucie z journala (przepraszam, że w takiej wersji, było mi łatwiej zrobić) https://www.dropbox.com/s/rvorw61n80bu241/20150925_135625.jpg?dl=0 Potem same partycje nie są montowane, bo fsck się nie udało. W /dev/disk/by- label wpisy są poprawne. Zmieniłem etykiety na nazwy partycji w fstab i dzięki temu system wstaje, ale to tylko obejście problemu. Czy teraz tak już ma być, czy też jakiś błąd w systemd (dziwi mnie ten ciąg /x2d w nazwie usługi, jakby w którymś miejscu w jakimś skrypcie był błąd). -- Łukasz Maśko _o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V