Created attachment 320205 [details] don't call getpwent after first NULL is returned Description of problem: When trying to do a 'useradd -r ...' and nsswitch.conf contains 'passwd: files ldap', the command hangs in an infinite loop. Version-Release number of selected component (if applicable): shadow-utils-4.1.1-4.fc9.i386 How reproducible: Always Steps to Reproduce: 1. useradd -r -s /some/shell -d /some/dir -M -g some_group some_user Actual results: Infinite loop Expected results: User added Additional info: The reason seems to be that getpwent() returns NULL once, and then restarts delivery of results from the LDAP database.
Actually, it doesn't enter an infinite loop. It only loops through the LDAP database once for each entry in the local password database, due to the fact that in the following loop the first time getpwent returns NULL, pw_next returns the first local entry, then on the next iteration getpwent restarts reading the LDAP database. while ( ((pwd = getpwent ()) != NULL) || ((pwd = pw_next ()) != NULL)) { but with 30 machines trying to add the same user, a local passwd with 50 users and a LDAP database with 12000 users, it all boiled down to 30 * 50 * 12000 = 18000000 LDAP lookups, which takes a very long time.
Filed bug against upstream libnss_ldap as well: http://bugzilla.padl.com/show_bug.cgi?id=376
Upstream bug has been closed. Is this still an issue for the reporter?
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can see the same trouble with FC11 final. Trying to install the akmods package from RpmFusion, the package sits forever and does not install. I could look into the package seeing it was blocked at the %pre step : useradd -r -g akmods -d /var/cache/akmods/ -s /sbin/nologin -c 'User is used by akmods to build akmod packages' akmods I also have a Ldap server for authentication.
this can be seen too when trying to install the package "partimage-server" the following is involved : D: install: %pre(partimage-server-0.6.7-7.fc11.i586) execv(/bin/sh) pid 21938 + /usr/sbin/useradd -M -r -s /sbin/nologin -d /var/partimaged -c 'Partition imaging utility' partimag
I got additional infos, using strace I have 'listened' to what happens to the useradd command and it showed me this : # strace useradd -r -g akmods -d /var/cache/akmods/ -s /sbin/nologin -c 'User is used by akmods to build akmod packages' akmods then we can see that useradd tries to browse THE WHOLE ldap directory *extract* rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0 gettimeofday({1246276038, 201210}, NULL) = 0 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "0\202\1\214\2\1\3d"..., 8) = 8 read(4, "\202\1\205\4%uid=anedroum,ou=User,dc=devi"..., 392) = 392 time(NULL) = 1246276038 rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0 gettimeofday({1246276038, 201877}, NULL) = 0 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "0\202\1\210\2\1\3d"..., 8) = 8 read(4, "\202\1\201\4$uid=abaghor,ou=User,dc=devin"..., 388) = 388 time(NULL) = 1246276038 rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0 gettimeofday({1246276038, 202563}, NULL) = 0 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "0\202\1\204\2\1\3d"..., 8) = 8 read(4, "\202\1}\4#uid=bbalan,ou=User,dc=devinc"..., 384) = 384 time(NULL) = 1246276038 rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0 gettimeofday({1246276038, 203231}, NULL) = 0 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "0\202\1\214\2\1\3d"..., 8) = 8 read(4, "\202\1\205\4%uid=hbouichm,ou=User,dc=devi"..., 392) = 392 time(NULL) = 1246276038 rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0 gettimeofday({1246276038, 203883}, NULL) = 0 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "0\202\1\214\2\1\3d"..., 8) = 8 read(4, "\202\1\205\4%uid=hbounekt,ou=User,dc=devi"..., 392) = 392 time(NULL) = 1246276038 rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0 gettimeofday({1246276038, 204537}, NULL) = 0 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "0\202\1\214\2\1\3d"..., 8) = 8 read(4, "\202\1\205\4%uid=lcouliba,ou=User,dc=devi"..., 392) = 392 time(NULL) = 1246276038 rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x1, [], 0}, {SIG_DFL, [], 0}, 8) = 0 gettimeofday({1246276038, 205199}, NULL) = 0 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "0\202\1\210\2\1\3d"..., 8) = 8 read(4, "\202\1\201\4$uid=scourty,ou=User,dc=devin"..., 388) = 388 time(NULL) = 1246276038 *extract* of course doing so can be very long... this behaviour should be fixed
as a reminder, the problem I describe in comment #5 #6 #7 are in Fedora Core 11 So this is an ACTUAL problem, not a end-of-life distro. This bug should be re-qualified as actual too
since relevant infos are provided
loop mentioned in comment #1 is not present in shadow-utils >= F11. Q. is what you want to fix. useradd has to iterate thru LDAP. man page: "You may not add a user to a NIS or LDAP group. This must be performed on the corresponding server. Similarly, if the username already exists in an external user database such as NIS or LDAP, useradd will deny the user account creation request."
(In reply to comment #10) I don't get your question, if it is one. So to you it is perfectly normal that you have to wait for several minutes for a simple "useradd", or a RPM installation that creates a user account in its 'pre' commands ? for the record, our LDAP server only has accounts with UID number over 5 digits to not mix with 3 digits system ones. So logicaly it should find very fast an available UID number right after looking into /etc/password, not spending aeons to browse a identification server with very high,therefore not interesting, numbers.
Unfortunately, it's not that easy, because: 1. getpwent() doesn't return entries in chronology example: UID: 1 4 3 100 2. in case of user accounts it's always looking for for max first unused values example: UIDs: 1 4 3 100 -> 101 is the one But there is a possibility to change alg. a bit. in a way that getpwuid() is used for system accounts. Let me ask upstream what they think about it. This could solve the problem at least for system accounts. :)
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.