Syndrom 95 Zgłoś post Napisano Grudzień 29, 2015 Witam, Miał ktoś problem z systemd, w logu mam: systemd[1]: Too many concurrent connections, refusing Nie wiem zupełnie jak do tego podejść. Udostępnij ten post Link to postu Udostępnij na innych stronach
kafi 2425 Zgłoś post Napisano Grudzień 29, 2015 To jest vps czy dedyk? Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Grudzień 29, 2015 To jest vps czy dedyk? Dedyk, Debian 8 64bit Udostępnij ten post Link to postu Udostępnij na innych stronach
Gość patrys Zgłoś post Napisano Grudzień 30, 2015 System aktualny ? Zobacz limity plików: ulimit -n cat /etc/security/limits.conf Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Grudzień 30, 2015 Limity nie zmieniane, ale to nie ma wpływu. Host z problemem: Dec 30 10:24:50 X systemd[1]: Too many concurrent connections, refusing # lsof |wc -l 456553 # ps -ef|wc -l 3320 # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 516317 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 516317 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # cat /etc/debian_version 8.2 Taka sama konfiguracja, host nie ma problemu: # lsof |wc -l 923374 # ps -ef|wc -l 1633 # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 516317 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 516317 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # cat /etc/debian_version 8.2 Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Grudzień 30, 2015 (edytowany) Systemd działa spod roota, a roota user limity nie dotyczą. Generalnie limit wynosi 4096 concurrent połączeń do dbusa, albo 512 w starszych wersjach systemd. Twój problem wskazuje raczej na problem z softwarem z którego korzystasz, a nie z samym systemd - nigdy nie powinno być aż tylu połączeń do dbusa. Nie mam pojęcia jak Ci pomóc poza sugestią sprawdzenia co generuje tyle połączeń, a nawet tego nie wiem jak na dobre sprawdzić. Edytowano Grudzień 30, 2015 przez Archi (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Grudzień 30, 2015 Dzięki to już zawsze wiem gdzie szukać, a strace na dbusa raczej nie zapodam. Może ktoś jeszcze miał podobne rzeczy. Dodam, że stoją tam lxc/docker kontenery Udostępnij ten post Link to postu Udostępnij na innych stronach
kafi 2425 Zgłoś post Napisano Grudzień 31, 2015 Czyli jednak coś związanego z wirtualizacją, tylko jak się okazało, troszkę z innej strony. 1. Czy z wewnątrz kontenerów lxc też obserwujesz te problemy? 2. Ile masz uruchomionych kontenerów na pierwszym (nie działającym), a ile na drugim (działającym)? 3. Czy po wyłączeniu kilku kontenerów problem nie "ustąpi"? Przy LXC wszystkie kontenery współdzielą dbus, więc może po prostu wszystkie razem przekraczają 512 połączeń? @Archi - obecna w Debianie Stable wersja DBUS ma limit 512 połączeń. Dopiero w stretch i sid poprawili to do 4k. http://sources.debian.net/src/systemd/215-17%2Bdeb8u2/src/core/dbus.c/ vs http://sources.debian.net/src/systemd/227-2/src/core/dbus.c/ Więc jeżeli po zamknięciu kilku kontenerów będzie działać, to jedyne, co autorowi pozostanie, to albo ręcznie przekompilować systemd/dbus, albo spróbować aktualizacji do testowego stretcha. Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Grudzień 31, 2015 (edytowany) @kafi - dzięki Ad1) jest ok Ad2) na nie działającym np: 235, 158, 146 Na działającym np: 149 138 Ad3) Zatrzymałem około 19 konetnerów i efekt bez zmian, czyli dalej sieje. Podejrzewam, że w jakiś sposób nie zwalnia zasobów, bo restartcie przez jakiś czas jest ok a potem znowu dzieję się dziwne rzeczy. Sprawdzę jeszcze korelację z prockami. Edytowano Grudzień 31, 2015 przez Syndrom (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Grudzień 31, 2015 Jak na moje to coś cieknie, połączenia są otwierane i nie są zamykane, aż po pewnym czasie osiągają limit (patrz 512) i system staje dęba. Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Styczeń 3, 2016 (edytowany) Zrobiłem test. Wyłączyłem wszystkie kontenery i włączyłem. Niestety problem nie znikł. Póki co killall systemd rozwiązuje problem. Wszystko się przeładowuje Edytowano Styczeń 3, 2016 przez Syndrom (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Sierpień 20, 2016 Odgrzebię kotleta, ale mam nowy trop. Na serwerze z problemem jest otwartych streamów do pliku dużo: # netstat -a|grep '/run/systemd/private' |wc -l 513 a zawsze jest tylko jeden. Udostępnij ten post Link to postu Udostępnij na innych stronach