RE: crash in slurpd when slave not present (ITS#2810)

[hyc@symas.com]

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of ocmer@home.nl

> Full_Name: ocmer
> Version: 2.1.23
> OS: Linux 2.4.20-13.7smp #1 SMP Mon May 12 12:31:27 EDT
> 2003 i686 unknown
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (217.120.171.59)
>
>
> When running OpenLDAP 2.1.23 (using the BDB backend), on a HP
> DL380 (using 2
> hyperthreaded Xeon
> processors), a crash occured in slurpd.
>
> OpenLDAP's slapd was put under load with 50 parallel
> connections, where 12
> connections were performing 1000 reads,
> 2 modify's, and 1 write action per connection, and 38 connections were
> performing reads only for a period of 24 hours.
> Replication was configured for one slave and slurpd was
> started. The slave which
> should recieve the data from the slurpd was (intentionally)
> not started.
> After 2 hours of starting the test, the crash in slurpd occured.

The short answer - don't do this.

slurpd keeps a copy of the replog in memory when it runs. More precisely, it
keeps a queue of pending changes. If you accumulate a large replog and its
volume exceeds your available system memory, slurpd will simply crash. When
you have a planned outage of a slave, you should just stop the slurpd and let
the slapd.replog fill up until the slave returns online.

This may be a design flaw in slurpd, and it is unlikely to be fixed. There's
been very little interest in maintaining slurpd for quite a long time, and
anything beyond trivial updates generally won't happen unless someone commits
to overhauling this code. Overall, the syncrepl support in OpenLDAP 2.2 is
the solution to slurpd's flaws.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support