+++ This bug was initially created as a clone of Bug #466794 +++

Created an attachment (id=320205)
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.

--- Additional comment from anders.blomdell.se on 2008-10-13 13:27:54 EDT ---

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.

--- Additional comment from anders.blomdell.se on 2008-10-14 08:30:15 EDT ---

Filed bug against upstream libnss_ldap as well:

http://bugzilla.padl.com/show_bug.cgi?id=376

--- Additional comment from lex.lists on 2009-03-03 19:12:33 EDT ---

Upstream bug has been closed.
Is this still an issue for the reporter?

--- Additional comment from fedora-triage-list on 2009-06-09 22:57:10 EDT ---


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

--- Additional comment from stephane.tranchemer on 2009-06-16 11:31:13 EDT ---

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.

--- Additional comment from stephane.tranchemer on 2009-06-18 05:59:02 EDT ---

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

--- Additional comment from stephane.tranchemer on 2009-06-29 07:49:41 EDT ---

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

--- Additional comment from stephane.tranchemer on 2009-06-29 07:52:30 EDT ---

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

--- Additional comment from stephane.tranchemer on 2009-06-29 07:53:14 EDT ---

since relevant infos are provided

--- Additional comment from pvrabec on 2009-06-30 05:11:32 EDT ---

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."

--- Additional comment from stephane.tranchemer on 2009-06-30 05:25:25 EDT ---

(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.

--- Additional comment from pvrabec on 2009-07-01 05:44:33 EDT ---

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. :)

--- Additional comment from fedora-triage-list on 2009-07-14 13:15:06 EDT ---


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.