Bug 433226 - slurpd hangs on service start, uses a lot of CPU
slurpd hangs on service start, uses a lot of CPU
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
8
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jan Safranek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-17 15:32 EST by Jari Turkia
Modified: 2008-10-30 09:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-22 03:09:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jari Turkia 2008-02-17 15:32:09 EST
Description of problem:
If LDAP replication is used, slurpd is started on service ldap start. However,
slurpd does not start, but hangs indefinetly and uses 100% CPU all the time.

Version-Release number of selected component (if applicable):
openldap-2.3.39-3.fc8

How reproducible:
Fails every time

Steps to Reproduce:
1. Configure OpenLDAP to use replication
2. start ldap
3. Observe high CPU load by slurpd
  
Actual results:
LDAP replication not working

Expected results:
Low CPU utilization by slurpd, working replication.

Additional info:

command line used:
/usr/sbin/slurpd -r /var/lib/ldap/replica

last lines of strace are:
clone(child_stack=0x410011c0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x410019e0, tls=0x41001950, child_tidptr=0x410019e0) = 20403
futex(0x408009e0, FUTEX_WAIT, 20402, NULL <unfinished ...>
Comment 1 Tom "spot" Callaway 2008-02-18 02:09:42 EST
Reassigning to correct component.
Comment 2 Jan Safranek 2008-02-18 10:26:51 EST
I cannot reproduce the bug. Could you please specify precisely the "Configure
OpenLDAP to use replication" step? I just used the default slapd.conf file and
added:
replogfile /var/lib/ldap/openldap-master-replog
replica host=f8:389 binddn="cn=Manager,dc=my-domain,dc=com" bindmethod=simple
credentials=secret

F8 is another Fedora 8 machine, running slapd. Everything works out of the box
and my data gets replicated to F8.

Please attach (without any passwords!):
- slapd.conf on "master"
- slapd.conf on "slave" (I assume it's another Fedora 8, right?)
- ldif export of your database, if possible
- log from master, slave and slurpd on master (beware, they can contain
passwords, use some dummy ones)

How to get a log:
on master:
    service ldap stop
    slapd -d -1 &>master.log
    slurpd -d -1 &>slurpd.log

on slave:
    service ldap stop
    slapd -d -1 >slave.log
Comment 3 Jan Safranek 2008-07-22 03:09:43 EDT
Closing the bug, the reporter failed to provide requested log files.
Comment 4 Jari Turkia 2008-10-29 02:57:56 EDT
The requested log files were empty and thus useless.

Finally the reason was found. If the slurpd replog file is a directory, this condition is not properly detected and the daemon hogs all available CPU-time.
Comment 5 Jan Safranek 2008-10-30 09:51:56 EDT
(In reply to comment #4)
> Finally the reason was found. If the slurpd replog file is a directory, this
> condition is not properly detected and the daemon hogs all available CPU-time.

The upstream (OpenLDAP 2.4.x) does not use slurpd anymore, I guess it does not make much sense to fix it. Use Fedora 9/10 or use configuration files with proper replog file :).

Note You need to log in before you can comment on or make changes to this bug.