Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
cvsnt-bounces at cvsnt.org wrote on 06/02/2008 08:41:34 AM: > > > Nsswitch.conf appears to be good on our system, but the > > problem has gone > > into hibernation since Thursday (until this Tuesday afternoon?) I > > reasonably expect it's going to occur again, and don't know > > where to start > > in troubleshooting the CVSROOT\group file not being read when > > it starts > > again, Arthur, > When does the time get sync'ed on this server? Our time is synched every few minutes from a single reliable source. I'd be very surprised if this were our problem. My PC and the server are accurate within 1 second as far as my naked eye can tell. > Try running in :local: mode and doing an strace (on the server), ie: > strace cvsnt -tttt -d :local:/path/to/repo co module Here's one line from our successful run of RedHat's strace substitute, autrace. If our problem recurs tomorrow, we will run this command again and diff the two logs for clues. type=EXECVE msg=audit(1212436983.644:7): argv[0]="/usr/bin/cvsnt" argv[1]="-ttt" argv[2]="-d" argv[3]=":local:/usr/local/cvs/caf" argv[4]="co" argv[5]="suites/loadforcast" I am concerned when I look at the (6mb!) log that there is no evidence of logging related to CVS internal group handling. I don't see a call to the group file at all. The word "group" never appears in the trace. > You could also try switching systemauth off and seeing how that affects > it. Our users are coming in via Samba/winbind authentication against Active Directory, so these are not local users at all. Each user's shell = bin/false. Given that, turning systemauth off should not have any effect according to my Linux experts. ============ We actually had one user receive an error one time that was similar to "Unable to read 'group' file. Failing." How does CVSNT handle an error situation in which it cannot read its group file? Could such a condition be cached? Could such a cache extend across reboots (since we did reboot the server and did not correct anything.) Could we reproduce such an error condition? We do have an identitical test server. Thank you again, Kevin