Howard Chu wrote:
Peter Mogensen wrote:
Hi,
This issue has been bugging me for a while, but I can't find anything about it when googling.
I have a slapd 2.3.x server which has been taking longer and longer to start. Lately it has ben 45 min. for a restart. With strace you can just see it waiting for a futex:
Process 22740 attached - interrupt to quit futex(0x56274bd8, FUTEX_WAIT, 22742, NULL
... then suddenly it starts to listen and answer queries.
What can slapd be waiting for?
Use gdb and find out.
Unfortunately that's a bit hard for me until I get new hardware, since I'm running on a 32 bit system on a 64 bit kernel and it seems that combination have a bug with gdb debuggen multithreaded applicattions for 2.6.18).
Anyway... strace on one of the threads which seems to be doing syncrepl reveals:
write(19, "\27\3\1\3\2710\202\3\241\2\1\2d\202\3c\4\uuid=ef556050-8"..., 958) = 708 write(19, "09Z0i\4\7entryDN1^\4\uuid=ef556050-8"..., 250) = -1 EAGAIN (Resource temporarily unavailable) epoll_ctl(7, EPOLL_CTL_MOD, 19, {EPOLLIN|EPOLLOUT, {u32=1437773908, u64=1437773908}}) = 0 write(6, "0"..., 1) = 1 futex(0x55cd2178, FUTEX_WAIT, 51, NULL) = 0 futex(0x55cd215c, FUTEX_WAKE, 1) = 0 write(19, "09Z0i\4\7entryDN1^\4\uuid=ef556050-8"..., 250) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) @ 0 (0) --- epoll_ctl(7, EPOLL_CTL_MOD, 19, {0, {u32=1437773908, u64=1437773908}}) = 0 futex(0x8165960, FUTEX_WAKE, 1) = 0
So somehow the syncrepl connection from server 2 to server 1 is closed (again and again) for the main database. But the connection for the cn=config database seems to persist.
/Peter