Bug 433226 - slurpd hangs on service start, uses a lot of CPU
Summary: slurpd hangs on service start, uses a lot of CPU
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap   
(Show other bugs)
Version: 8
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jan Safranek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-17 20:32 UTC by Jari Turkia
Modified: 2008-10-30 13:51 UTC (History)
0 users

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


Attachments (Terms of Use)

Description Jari Turkia 2008-02-17 20:32:09 UTC
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 07:09:42 UTC
Reassigning to correct component.

Comment 2 Jan Safranek 2008-02-18 15:26:51 UTC
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 07:09:43 UTC
Closing the bug, the reporter failed to provide requested log files.

Comment 4 Jari Turkia 2008-10-29 06:57:56 UTC
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 13:51:56 UTC
(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.