Crashe procesu named

[Maciej Kędzierski]

W dniu 18.03.2026 o 22:57, Jan Palus pisze:
> On 18.03.2026 20:02, Maciej Kędzierski wrote:
>> Wczoraj musiałem zrestartować usługę "named" na jednym z serwerów i się
>> zaczęło.
>> Crash co chwila.
>>
>> [17mar 20:14] [T10828] named[10828]: segfault at 0 ip 00000000 sp bfa23cfc
>> error 14 in named[8048000+e000]
>>
>> Co gorsza, to nie robiłem aktualizacji ostatnio, tylko w połowie lutego.
>> Wszystko działało normalnie, aż do wczorajszego restartu.
>> Za diabła nie mogłem namierzyć winnego, a działający serwer DNS był tak
>> niezbędny, że w ramach desperacji utworzyłem nową maszynę z serwerem DNS.
>> Zrobiłem świeżą aktualizację, ale też nić się nie zmieniło.
>>
>> Dziś zacząłem robić update na innej maszynie i czując pismo nosem, robiłem
>> aktualizację, po parę pakietów, restart named, i tak w kółko i BINGO, w
>> pewnym momencie crash.
>> Po przywróceniu paru pakietów okazało się, że winny jest 'libuv-1.52.0".
>> Przywrócenie do poprzedniej wersji i znowu działa. Potem w th-test znalazłem
>> libuv-1.52.1-1 i ten też działa.
>>
>> W Changelogu wersji 1.52.1 jest taka linijka:
>> * linux: fix crash if poll callback closes handle before `POLLERR` (Juan
>> José  Arboleda)
>>
>> Zapewne to to.
>>
>> Proszę przerzucie ten pakiet do głównego repozytorium, bo może innym
>> zaoszczędzi to czasu i nerwów, bo wczoraj na analizach i innych działaniach
>> spędziłem wiele godzin, zwłaszcza, że przestało działać z d..., bo
>> technicznie nic nie było robione na tej maszynie przez wiele dni i to mnie
>> całkowicie zmyliło.
> Dzięki za zidentyfikowanie problemu. Powiązane zgłoszenie:
>
> https://github.com/libuv/libuv/issues/5030
>
> Wygląda że najbardziej narażone były konfiguracje z "zone transfer".
>
> na przyszłość dobrze jest w takich sytuacjach zainstalować gdb i
> debuginfo:
>
> poldek -n th-debuginfo -iv bind-debuginfo bind-libs-debuginfo
>
> i odpalić np:
>
> gdb -batch -ex run -ex bt --args named -g ...
>
> lub jeżeli używasz systemd to po crashu w serwisie:
>
> coredumpctl debug --debugger-arguments="-batch -ex bt"
>
> I śmiało słać wynik na listę. Od razu byłoby widać, że najpewniej winnym
> jest libuv.
>

Człowiek uczy się całe życie.
Nigdy nie debugowałem programów, a tu takie ułatwienie, jak się już wie 
jak to zrobić.
Przetestowałem na podatnej wersji libuv-1.52.0 i w wyniku dostałem po 
chwili:

# gdb -batch -ex run -ex bt --args named -g -d 3 -u named -t 
/var/lib/named -c /etc/named.conf -4
:
:
:
Thread 4 "named" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb503ab00 (LWP 21915)]
0x00000000 in ?? ()
#0  0x00000000 in ?? ()
#1  0xb769b9bf in ?? () from /usr/lib/libuv.so.1
#2  0xb769beeb in ?? () from /usr/lib/libuv.so.1
#3  0xb768bf2c in ?? () from /usr/lib/libuv.so.1
#4  0xb769ef73 in ?? () from /usr/lib/libuv.so.1
#5  0xb768c104 in uv_run () from /usr/lib/libuv.so.1
#6  0xb7f652cf in loop_thread (arg=arg at entry=0xb66d6870) at loop.c:328
#7  0xb7f79c0e in thread_body (wrap=0x80d3830) at thread.c:85
#8  thread_run (wrap=0x80d3830) at thread.c:100
#9  0xb7366a27 in ?? () from /lib/libc.so.6
#10 0xb73fb348 in ?? () from /lib/libc.so.6

a za drugim razem

Thread 1 "named" received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
#0  0x00000000 in ?? ()
#1  0xb769b9bf in ?? () from /usr/lib/libuv.so.1
#2  0xb769beeb in ?? () from /usr/lib/libuv.so.1
#3  0xb768bf2c in ?? () from /usr/lib/libuv.so.1
#4  0xb769ef73 in ?? () from /usr/lib/libuv.so.1
#5  0xb768c104 in uv_run () from /usr/lib/libuv.so.1
#6  0xb7f652cf in loop_thread (arg=0xb66d6000) at loop.c:328
#7  0xb7f665ab in isc_loopmgr_run (loopmgr=0xb7fba460) at loop.c:514
#8  0x0805aba2 in main (argc=11, argv=0xbffff364) at main.c:1595

i wszystko jasne, widać podejrzanego :)

Rozumiem, że każdy debugowany program wymaga pakietów -debuginfo.


Pozdrawiam
M