On Thu, 2004-09-23 at 14:17 -0300, BG - Ben Armstrong wrote: > We have been noticing that using MS Wordpad, COPY, or other means to > read the contents of a file, most of the time the file is successfully > retrieved, but sometimes it returns empty. This happens on a fairly > regular basis, so with proper direction, we ought to be able to "catch > it in the act" and report more details here. So, what should we be > looking for? Should our log levels be elevated, and if so, how high? > Is there anything else we can do to make this problem more visible?
With regards to this problem, today we collected some observations during an incident: - backup/ignore=interlock made of all .tdb files - show process/acc on the user's smbd process - show device/files for files open by the user's smbd process - dir (on the Windows client) showing zero blocks for most (but not all) files in the "problem" directory - dir (on the Windows client) after killing off the user's smbd process showing that all files in the "problem" directory now all have expected sizes I will provide all of these in a zip archive to JYC for closer examination. For the rest of us, I include below the show process & show device output, in case anything looks suspicious: 27-SEP-2004 14:54:26.45 User: SYSTEM Process ID: 0001DA0F Node: DYMA Process name: "SMBD_DMPCXP_DA0" Accounting information: Buffered I/O count: 193317 Peak working set size: 14640 Direct I/O count: 44366 Peak virtual size: 184880 Page faults: 1009 Mounted volumes: 0 Images activated: 3 Elapsed CPU time: 0 00:01:53.01 Connect time: 0 08:54:26.07 Soft CPU Affinity: off SMBD_DMPCXP_DA0 0001DA0F [SYSCOMMON.SYSEXE]RIGHTSLIST.DAT;3 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]MESSAGES.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.BIN]SMBD_STARTUP.COM;9 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.BIN]SMBD.EXE;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.PRIVATE]SECRETS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]CONNECTIONS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]BRLOCK.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]LOCKING.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]PRINTING.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]NTDRIVERS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]NTPRINTERS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]NTFORMS.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SAMBA.VAR.LOCKS]SHARE_INFO.TDB;1 SMBD_DMPCXP_DA0 0001DA0F [SYS0.SYSMGR]SMBD_STARTUP.LOG;124 SMBD_DMPCXP_DA0 0001DA0F [SAMBA]LOG.DMPCXP;1 Unfortunately, I didn't think to save [samba]log.dmpcxp itself. I'm kicking myself for that now. That might have been interesting. I'm thinking it might be significant that we keep our SMBD processes around for a very long time because people didn't like having to wait for their SMBD process to come into existence: deadtime = 480 Setting your deadtime as high as ours, and/or keeping a process busy making continuous accesses over a long period of time may help reproduce the problem. Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html