Re: Slurpd causes kernel panic due to huge replog file?

[matthew sporleder <msporleder@gmail.com>]

I've run replog files for a pretty long time and never seen slurpd
grow very much in memory usage while it processed it.  Your kernel
panic is obviously a linux problem and it seems odd that a  2.6 kernel
would be running on a filesystem with a 2gb limit.  However, it should
be pretty easy to just engineer a fake replog file to see if you can
reproduce the problem while tracing/debugging slurpd.

On 11/25/05, Jukka Hienola <jukka.hienola@helsinki.fi> wrote:
> Hi!
>
> A couple of days ago my master LDAP server's IP address changed. After
> the change I forgot to open ports on my firewall to allow replication of
> my LDAP directory with my slave LDAP server. Due to this, requests to
> slave server were written to master server's LDAP directory, but
> replication of master server's directory to slave server didn't succeed.
> As a result, my replog file size did grow until reached it's maximum
> size on my master server's filesystem. After I noticed that replication
> doesn't work, I located the problem to firewall sttings and fixed that.
> I restarted my slapd and slurpd daemons, and I saw replication requests
> processed until all memory vere consumed on my master system and system
> crashed with kernel panic. Several times.
>
> I'm not sure, but I assume that the size of replog file was too big and
> my system has not enough memory (1GB RAM + 1GB swap). The memory were
> consumed little by little as replication proceeded, until I run out of
> memory.
>
> Next I backed up replog file and splitted the original file into smaller
> bits, which I successfully replicated on my slave server's LDAP
> directory with slurpd.
>
> So, my question is, if anyone has encounter similar situation? Could the
> reason really be the size of replog file, or corrupted replog file?
> That's all I could think of. If so, is there any way to split replog
> file into smaller slices of some maximum size (depending of your
> filesystem limitations) if needed, e.g. slapd.replog.0, slapd.replog.1,
> ... slapd.replog.n, which could be replicated one after another (e.g.
> *.0,*.1, ..., *.n)?
>
> I've tried to find something like that from OpenLDAP documentation, but
> to be honest, I found it very concise.
>
> In fact, I suppose it wouldn't be very difficult to make such a changed
> to OpenLDAP code... maybe I'll try.
>
> ... and I'm using RHEL4 on both master and slave servers (kernel
> 2.6.9-22) and OepnLDAP 2.2.13-4.
>
> Jukka Hienola
>
> --
> IT Services Administrator, Department of Physical Sciences,
> University of Helsinki, firstname.lastname (a) helsinki.fi,
> tel. +358 (0)9 191 50713, fax. +358 (0)9 191 50610
>