My bind9 simply stopped working all of a sudden. It worked perfectly and
then following a reboot of the VZ container it would segfault on start.
The first event coincided with the latetst security update. I installed
the update and it did start again. However, now using still the same
code, it segfaults on every start. I tried to reinstall the package
without any change. I also rebooted the VZ container to get around
resource leakage, but the issue persists. I'd think that it is quite
unlikely that bind9 uses the same physical memory page after rebooting
the container.
To get around it, I installed a new bind9 into a new VZ container,
copied my zone files and it runs like a charm. So configuration
problems in the zone files are probably not the major cause.
Kernel: 2.6.26-2-openvz-amd64 #1 SMP Thu Nov 5 03:06:00 UTC 2009 x86_64
GNU/Linux
Version: bind9 1:9.5.1.dfsg.P3-1+lenny1
I straced named once before reboot and once after: strace -f -o
bind2.trc named -u bind -fg -d 9999 . Apart from PID and memory
addresses these two traces apparently are identical and contain 437
lines. The following is the tail of both logs:
432 setuid(102) = 0
432 prctl(0x4, 0x1, 0, 0, 0) = 0
432 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
432 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
432 capget(0x20080522, 0, {0,
CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
0}) = 0
432 getuid() = 102
432 capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE,
CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE, 0}) = 0
432 mmap(NULL, 266240, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f04ff1f0000
432 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
432 +++ killed by SIGSEGV +++
The other log has address 0x7fc1309f8000 as the mmap() result.
Apparently, the segfault happens quite immediately following the
privilege dropping.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
