On 09/03/2013 15:31, Jan Kadlec wrote:
Hello and thanks for all the valuable feedback.
Debugging messages
might not help you in this case, because they tend to generate a lot of
data, especially when Knot is loading 16G worth of zones, so it could
take a lot of time until the issue occurs. If you could attach a
debugger to knotd process when it gets stuck and let us know what is
doing at the moment. Perhaps using Poor Man's Profiler might be the best
option. Thanks again for your feedback. Best regards, Jan.
Hi Jan,
I ran the non-debug version of the server, and when it shot up to 100%
and stopped logging, I attached to it with strace:
# strace -p 20919
Process 20919 attached - interrupt to quit
pselect6(83, [82], NULL, NULL, NULL, {NULL, 8}
That's all it gave. Nothing more.
Then I sent the process a TERM signal from another terminal, and it got
unwedged:
# strace -p 20919
Process 20919 attached - interrupt to quit
pselect6(83, [82], NULL, NULL, NULL, {NULL, 8}) = ? ERESTARTNOHAND (To
be restarted)
--- SIGTERM (Terminated) @ 0 (0) ---
rt_sigreturn(0xf) = -1 EINTR (Interrupted system call)
rt_sigprocmask(SIG_BLOCK, [], NULL, 8) = 0
write(6, "\0", 1) = 1
close(6) = 0
write(9, "\0", 1) = 1
close(9) = 0
write(12, "\0", 1) = 1
close(12) = 0
write(14, "2013-03-09T15:25:46.939857-00:00"..., 52) = 52
The server continued writing into the log file, and continued to XFR
zones. I expected it to shutdown with a TERM signal, but it appeared to
ignore the signal and continue working. It only stopped with a second
TERM signal.
Regards,
Anand