[Date Prev][Date Next]
RE: slurpd blocking updates
--On Thursday, May 13, 2004 11:27 PM -0700 Howard Chu <email@example.com>
Well, it would look like to me then that this problem was introduced
between 2.2.6 and 2.2.11, and 2.1.25 and 2.1.29, since I have
not had any
problems on those earlier version, and I know changes were
made to slurpd
since then. Perhaps the out-of-order fix to slurpd impacted
it, I know
that was a major bug fix...
The diff's to slurpd from 2.1.25 to 2.1.29 are largely cosmetic, mostly in
comments and error message reporting. The out-of-order fix was a change to
how slapd generates the replog, not a code change in slurpd. Since the
slurpd code has not changed, and only the replog itself is different, one
would expect all of your replicas to behave identically since they're all
using the same replog.
Okay -- As I noted, I'm looking at 2.2.6 and 2.2.11 myself.
Probably you need a debug/non-optimized build of slurpd to track this down
and get some good stack traces. If the stack traces aren't telling
anything useful, that tends to imply that the stack itself is trashed.
(The trace you provide in ITS#3123 is conspicuous in that it only goes
back as far as libthread, and doesn't tell anything about the calling
Yeah, I've built a debugging version of slurpd with all its lovely symbols,
and that is what is running on our test master. The stack traces haven't
shown anything useful.
What I know is I see this constantly on my test servers (2.2.11), which
have very few updates and are particularly low volume. My production
master, on the other hand, running 2.2.6, has had 10,000 updates pushed
above its normal 1k or so updates a day pushed at it in the last 3 days,
and has not had a single issue.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html