Red Hat Bugzilla – Full Text Bug Listing
|Summary:||389 DS deadlocks when mass-adding users from multiple processes|
|Product:||[Fedora] Fedora||Reporter:||Stephen Gallagher <sgallagh>|
|Component:||389-ds-base||Assignee:||Rich Megginson <rmeggins>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||edewata, nalin, nhosoi, nkinder, rmeggins|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
Virtual Machine (8 CPUs) running Fedora 14 i686
|Last Closed:||2011-04-11 21:04:23 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Stephen Gallagher 2011-03-31 12:40:39 EDT
Description of problem: I needed to add fifty thousand users to my DS for testing purposes. I generated five separate LDIF files with ten thousand users in each and ran ldapmodify from separate processes on the localhost. (This was intended to take advantage of more processors, as I had eight available) This worked for a few hundred users before 389 DS became completely unresponsive. None of the five processes reported users being added, and the error_log had nothing to say. I straced the dirsrv process and saw what appeared to be a tight-loop calling poll(). I had to kill -9 the server in order to get it back. 'service dirsrv restart' hung as well. Version-Release number of selected component (if applicable): 389-ds-base-1.2.8-0.2.a2.fc14.i686 How reproducible: Irregular Steps to Reproduce: See description Actual results: Directory server was hung. Expected results: All fifty thousand users should have been added Additional info:
Comment 2 Stephen Gallagher 2011-04-11 21:04:23 EDT
Yes, I believe it is. *** This bug has been marked as a duplicate of bug 692690 ***
Comment 3 Nalin Dahyabhai 2011-04-12 09:10:31 EDT
Are you sure? Bug #692690 isn't a deadlock so much as a a-server-thread's-really-busy-right-now which happens to last a long time.
Comment 4 Stephen Gallagher 2011-04-12 09:15:51 EDT
Well, I suppose it could be considered a separate issue that slapi-nis taking forever in one thread is causing all other threads to block would be a separate issue. So yeah, I guess we should reopen this.
Comment 5 Rich Megginson 2011-04-12 10:39:16 EDT
(In reply to comment #4) > Well, I suppose it could be considered a separate issue that slapi-nis taking > forever in one thread is causing all other threads to block would be a separate > issue. > > So yeah, I guess we should reopen this. Does it cause all operations to block?
Comment 6 Stephen Gallagher 2011-04-12 10:40:33 EDT
(In reply to comment #5) > (In reply to comment #4) > > Well, I suppose it could be considered a separate issue that slapi-nis taking > > forever in one thread is causing all other threads to block would be a separate > > issue. > > > > So yeah, I guess we should reopen this. > > Does it cause all operations to block? Yes. Once I was in the state described by bug 692690 I could not perform any search, modify, etc.