Jean-Noel, Did you see the same debug logs this time again? especially "smbrdr_netuse_alloc: table full" because the DTrace output doesn't show the problem.
Afshin Jean-Noel Filippi wrote: > Afshin, > > Attached is the output of the dtrace scipt. It stopped when I had to > restart smbd because the issue was happening. > > Let me know what you find. > > Thanks, > > Jean-Noel > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2008 11:58 AM > To: Jean-Noel Filippi > Cc: Nicolas Williams; [email protected] > Subject: Re: [cifs-discuss] Idmap stability problem > > Next time you have to restart smb/server run the attached DTrace > script right after the service is restarted and let it run until > you see the problem below then stop it and post the output: > > netuse.d -p `pgrep smbd` | tee netuse.out > > Thanks, > Afshin > > Jean-Noel Filippi wrote: >> I enabled debugging on the syslog daemon to get more information. >> Here are the errors thrown while SMB stops working: >> >> Oct 3 22:31:00 vdcnas001 idmap[4619]: [ID 537588 daemon.debug] Found >> _ldap._tcp.gc._msdcs.photochannel.local 600 IN SRV [0][100] >> ad001.photochannel.local:3268 >> Oct 3 22:31:00 vdcnas001 idmap[4619]: [ID 966149 daemon.debug] unable > >> to discover Site Name >> Oct 3 22:31:00 vdcnas001 idmap[4619]: [ID 873961 daemon.info] change >> domain_controller=ad001.photochannel.local port=389 >> Oct 3 22:31:00 vdcnas001 idmap[4619]: [ID 873961 daemon.info] change >> domain_controller=vdcdc002.photochannel.local port=389 >> Oct 3 22:31:49 vdcnas001 smbd[10584]: [ID 775558 daemon.debug] >> smb_door_srv_func: execute server routine(opcode=0) >> Oct 3 22:31:49 vdcnas001 smbd[10584]: [ID 277356 daemon.debug] >> *smbrdr_netuse_alloc: table full* >> Oct 3 22:31:49 vdcnas001 smbd[10584]: [ID 577104 daemon.debug] >> smbrdr_tree_connect: init failed >> Oct 3 22:31:49 vdcnas001 smbd[10584]: [ID 321293 daemon.debug] > smbrdr: >> (open) vdcdc002 PHOTOCHANNEL VDCNAS001$ \NETLOGON INTERNAL_ERROR >> Oct 3 22:31:50 vdcnas001 smbd[10584]: [ID 775558 daemon.debug] >> smb_door_srv_func: execute server routine(opcode=0) >> Oct 3 22:31:50 vdcnas001 smbd[10584]: [ID 277356 daemon.debug] >> smbrdr_netuse_alloc: table full >> Oct 3 22:31:50 vdcnas001 smbd[10584]: [ID 577104 daemon.debug] >> smbrdr_tree_connect: init failed >> >> >> > ------------------------------------------------------------------------ >> *From:* Jean-Noel Filippi >> *Sent:* Fri 03/10/2008 6:22 PM >> *To:* Nicolas Williams >> *Cc:* [EMAIL PROTECTED]; [email protected] >> *Subject:* Re: [cifs-discuss] Idmap stability problem >> >> The ouput was created when the issue was happening. I attempted to > connect to the share 2 or 3 times from a Windows host. Each time I got > permission denied. >> >> To answer your other questions, restart SMB alone fixed the problem. I > don't need to restart idmap. You are right and I should be > troubleshotting SMB instead of idmap. Is there any dtrace script to run > to catch SMB traffic while the issue is happening? >> >> Thanks, >> >> JN >> >> ________________________________ >> >> From: Nicolas Williams [mailto:[EMAIL PROTECTED] >> Sent: Fri 03/10/2008 1:29 PM >> To: Jean-Noel Filippi >> Cc: [EMAIL PROTECTED]; [email protected] >> Subject: Re: [cifs-discuss] Idmap stability problem >> >> >> >> On Fri, Oct 03, 2008 at 12:38:50PM -0700, Jean-Noel Filippi wrote: >>> We are still struggling here with the SMB and IDMAP daemons. >>> For some reasons, all the authentications requests start failing >>> randomly. The only way to get it working again is to restart SMB. >>> >>> I have attached the output of the dtrace script for idmap (captured >>> while authencation was failing) and the cifs-gendiag output. >>> >>> I would appreciate any help. >> Hmmm, I'm not finding any telltale clue in there. I'll have to look > at >> it more carefully. >> >> Meanwhile, the idmap.d output is particularly small. When run on a > busy >> service, or even on an otherwise idel service just to capture a single >> logon attempt this script tends to produce massive output. Can you >> confirm that the output you sent captures the failing share logon? >> >> Nico >> -- >> >> >> _______________________________________________ >> cifs-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/cifs-discuss _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
