On Thu, 2008-05-08 at 22:13 +0200, Arthur de Jong wrote: > On Thu, 2008-05-08 at 19:30 +0200, Petter Reinholdtsen wrote: > > After stopping ntpd, running ntpdate adserver and restarting ntpd, > > nslcd no longer worked. The command 'getent passwd knownuser' did not > > return any entry, and it was impossible to log in. > > > > Is nslcd unable to handle time going backwards? > > This could very well be the case. I'll have to go over the code and see > if any of it can't handle time going back. Some parts of the code have > timeout handling that e.g. calculate time to sleep based on the time > difference. That may fail (or sleep for an unreasonably long time) when > the clock is moved back.
I went over the code and found two possible problems where a very long sleep would be done or a very long select(). The first sleep would only be a problem if there are running retries going on while the time is moved and would only completely lock nslcd if there were 5 searches going on at the time step. The second one is even less likely as 5 connections from the NSS library need to hang and the time shift happens exactly at the right (wrong) time in all 5 threads. Anyway, these have been fixed (r738) but will likely not fix this problem because the race conditions were very unlikely to hit all 5 threads simultaneously (unless you have less threads configured). Is the problem reproducible in your environment (some testing in mine couldn't trigger the bug)? If you can reproduce this, can you run strace -p <pidofnslcd> on some of the threads? You need to pass the -L option to ps to show the threads. Also stracing other processes could provide more information (nscd maybe?). -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
