From masko w ipipan.waw.pl Fri Sep 3 14:56:25 2021 From: masko w ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=) Date: Fri, 03 Sep 2021 14:56:25 +0200 Subject: Google-chrome =?UTF-8?B?b2Rtw7N3acWCIHdzcMOzxYJwcmFjeS4=?= In-Reply-To: <20210825105100.s5szlhqgkqkmqgxk@pine> References: <2825264.ktDbmJtnY2@laptok> <20210825105100.s5szlhqgkqkmqgxk@pine> Message-ID: <2077510.vHrt8AlqI9@laptok> Jakby co to pojawiła się wersja 93.0.4577.63 i ona działa poprawnie. -- Łukasz Maśko _o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające "Nie umiem zainstalować Debiana" From josiecki w silvercube.pl Tue Sep 7 12:36:49 2021 From: josiecki w silvercube.pl (Jacek Osiecki) Date: Tue, 7 Sep 2021 12:36:49 +0200 Subject: nginx i problemy z logrotate Message-ID: <2CAC4C54-D312-4980-BD64-12EB91C6DD09@silvercube.pl> Cześć, na jednym z vserverów mam dziwny problem z logami nginxa i logrotate. mam ustawione logrotate na daily, w cronie odpalany jest o 5 rano. I wszystko pięknie, idzie logrotate, logi trafiają do /var/log/archive/nginx/ z odpowiednią datą, tworzone są nowe logi. No i to tyle jeśli chodzi o ?pięknie? - bo nginx nic do tych nowych logów nie zapisuje. Ot tak, po prostu są sobie puste. Odpalenie ?service nginx reload? bez słowa magicznie przywraca nginxowi moc zapisywania do logów? no ale nie o to chyba chodzi :-/ Skrypt nginx dla logrotate jest praktycznie standardowy: /var/log/nginx/*.log { olddir /var/log/archive/nginx create 644 nginx nginx sharedscripts postrotate date >> /var/log/rotate.nginx.log /sbin/service nginx reopen-logs >> /var/log/rotate.nginx.log endscript } Specjalnie dodałem to rotate.nginx.logs żeby sprawdzić czy on czegoś nie wywala? ale nie - jest tam standard: Tue Sep 7 05:02:01 CEST 2021 Reopening nginx logs...............................................[ DONE ] Jakieś pomysły - jak to diagnozować, czego szukać? Nginx w najnowszej wersji, jakby co? Pozdrawiam, ? Jacek Osiecki From pmuch w zamek.szczecin.pl Tue Sep 7 13:22:11 2021 From: pmuch w zamek.szczecin.pl (Pawel Muszynski) Date: Tue, 7 Sep 2021 13:22:11 +0200 Subject: nginx i problemy z logrotate In-Reply-To: <2CAC4C54-D312-4980-BD64-12EB91C6DD09@silvercube.pl> References: <2CAC4C54-D312-4980-BD64-12EB91C6DD09@silvercube.pl> Message-ID: W dniu 07.09.2021 o 12:36, Jacek Osiecki pisze: > Cześć, > > na jednym z vserverów mam dziwny problem z logami nginxa i logrotate. > mam ustawione logrotate na daily, w cronie odpalany jest o 5 rano. > > I wszystko pięknie, idzie logrotate, logi trafiają do /var/log/archive/nginx/ z odpowiednią datą, tworzone są nowe logi. > No i to tyle jeśli chodzi o ?pięknie? - bo nginx nic do tych nowych logów nie zapisuje. Ot tak, po prostu są sobie puste. > > Odpalenie ?service nginx reload? bez słowa magicznie przywraca nginxowi moc zapisywania do logów? no ale nie o to chyba chodzi :-/ > > Skrypt nginx dla logrotate jest praktycznie standardowy: > > /var/log/nginx/*.log { > olddir /var/log/archive/nginx > create 644 nginx nginx > sharedscripts > postrotate > date >> /var/log/rotate.nginx.log > /sbin/service nginx reopen-logs >> /var/log/rotate.nginx.log > endscript > } > > Specjalnie dodałem to rotate.nginx.logs żeby sprawdzić czy on czegoś nie wywala? ale nie - jest tam standard: > > Tue Sep 7 05:02:01 CEST 2021 > Reopening nginx logs...............................................[ DONE ] > > Jakieś pomysły - jak to diagnozować, czego szukać? Nginx w najnowszej wersji, jakby co? To może zmienić skrypt na /sbin/service nginx reload Paweł From arekm w maven.pl Tue Sep 7 13:30:59 2021 From: arekm w maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=) Date: Tue, 7 Sep 2021 13:30:59 +0200 Subject: nginx i problemy z logrotate In-Reply-To: <2CAC4C54-D312-4980-BD64-12EB91C6DD09@silvercube.pl> References: <2CAC4C54-D312-4980-BD64-12EB91C6DD09@silvercube.pl> Message-ID: <5bc27044-aa2d-35ae-7b23-c68752c51bf8@maven.pl> W dniu 07.09.2021 o 12:36, Jacek Osiecki pisze: > Cześć, > > na jednym z vserverów mam dziwny problem z logami nginxa i logrotate. > mam ustawione logrotate na daily, w cronie odpalany jest o 5 rano. > > I wszystko pięknie, idzie logrotate, logi trafiają do /var/log/archive/nginx/ z odpowiednią datą, tworzone są nowe logi. > No i to tyle jeśli chodzi o ?pięknie? - bo nginx nic do tych nowych logów nie zapisuje. Ot tak, po prostu są sobie puste. > > Odpalenie ?service nginx reload? bez słowa magicznie przywraca nginxowi moc zapisywania do logów? no ale nie o to chyba chodzi :-/ > > Skrypt nginx dla logrotate jest praktycznie standardowy: > > /var/log/nginx/*.log { > olddir /var/log/archive/nginx > create 644 nginx nginx > sharedscripts > postrotate > date >> /var/log/rotate.nginx.log > /sbin/service nginx reopen-logs >> /var/log/rotate.nginx.log > endscript > } > > Specjalnie dodałem to rotate.nginx.logs żeby sprawdzić czy on czegoś nie wywala? ale nie - jest tam standard: > > Tue Sep 7 05:02:01 CEST 2021 > Reopening nginx logs...............................................[ DONE ] > > Jakieś pomysły - jak to diagnozować, czego szukać? Nginx w najnowszej wersji, jakby co? # Tell nginx to reopen logs # http://nginx.org/en/docs/control.html#logs reopen_logs() { local oldbin_pidfile="${pidfile}.oldbin" if [ -f $oldbin_pidfile ]; then show "Reopening $svname (oldbin) logs" killproc -p $oldbin_pidfile $prog -USR1 fi show "Reopening $svname logs" killproc -p $pidfile $prog -USR1 } czyli -USR1 na główny pid powinno wymusić reopen logów - działa puszczenie USR1 z palca? -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) From josiecki w silvercube.pl Thu Sep 23 11:40:05 2021 From: josiecki w silvercube.pl (Jacek Osiecki) Date: Thu, 23 Sep 2021 11:40:05 +0200 Subject: Konflikt syslog-ng i hc-cron Message-ID: <75853955-2DDF-48C1-839D-3FCBB0CBE261@silvercube.pl> Hej, próbowałem na jednej wirtualce wrzucić syslog-ng i taki kwiatek wyskoczył. Co z tym robić? hc-cron jest w aktualnej wersji... poldek:/all-avail> install syslog-ng- Przetwarzanie zależności... syslog-ng-3.29.1-3.x86_64 zaznaczył syslog-ng-libs-3.29.1-3.x86_64 (wł. /usr/share/syslog-ng) syslog-ng-libs-3.29.1-3.x86_64 zaznaczył libivykis-0.42.4-1.x86_64 (wł. libivykis.so.0()(64bit)) syslog-ng-3.29.1-3.x86_64 zaznaczył libnet-1.2-1.x86_64 (wł. libnet >= 1:1.1.2.1-7) syslog-ng-3.29.1-3.x86_64 zaznaczył net-snmp-libs-5.9-5.x86_64 (wł. libnetsnmp.so.40()(64bit)) Pakiet net-snmp-libs-5.9-5.x86_64 sugeruje instalację: 1. mibs-net-snmp Spróbować go zainstalować? [N/y] n syslog-ng-3.29.1-3.x86_64 zaznaczył rabbitmq-c-0.11.0-1.x86_64 (wł. librabbitmq.so.4()(64bit)) Jest 6 pakietów do instalacji (5 zaznaczonych pośrednio): I syslog-ng-3.29.1-3.x86_64 D libivykis-0.42.4-1.x86_64 libnet-1.2-1.x86_64 net-snmp-libs-5.9-5.x86_64 rabbitmq-c-0.11.0-1.x86_64 syslog-ng-libs-3.29.1-3.x86_64 This operation will use 13.6MB of disk space. Potrzeba pobrać 5.8MB archiwów (5.8MB do pobrania). Pobieranie [1/6] th::libivykis-0.42.4-1.x86_64.rpm... .............................. 100.0% [27.5K (27.5K/s)] Pobieranie [2/6] th::libnet-1.2-1.x86_64.rpm... .............................. 100.0% [53.3K (8.0K/s)] Pobieranie [3/6] th::net-snmp-libs-5.9-5.x86_64.rpm... .............................. 100.0% [238.3K (238.3K/s)] Pobieranie [4/6] th::rabbitmq-c-0.11.0-1.x86_64.rpm... .............................. 100.0% [43.5K (43.5K/s)] Pobieranie [5/6] th::syslog-ng-libs-3.29.1-3.x86_64.rpm... .............................. 100.0% [288.2K (73.5K/s)] Pobieranie [6/6] th::syslog-ng-3.29.1-3.x86_64.rpm... .............................. 100.0% [5.2M (5.2M/s)] ==> warning: tag 273 type(0x6) != implicit type(0x0) ==> warning: tag 273 type(0x6) != implicit type(0x0) ==> warning: tag 273 type(0x6) != implicit type(0x0) ==> warning: tag 273 type(0x6) != implicit type(0x0) Uruchamianie vrpm-preload --upgrade -vh --root /vservers/oi-python --define _check_dirname_deps 1... ==> warning: tag 273 type(0x6) != implicit type(0x0) ==> warning: tag 273 type(0x6) != implicit type(0x0) ==> warning: tag 273 type(0x6) != implicit type(0x0) ==> warning: tag 273 type(0x6) != implicit type(0x0) Przygotowywanie... ########################################### [100%] error: Problemy z instalacją/usuwaniem: plik /var/log/cron z instalacji syslog-ng-3.29.1-3.x86_64 jest w konflikcie z plikiem z pakietu hc-cron-0.14-28.x86_64 Wystąpiły błędy podczas instalacji poldek:/all-avail> Pozdrawiam, ? Jacek Osiecki