>> "S" == Steve wrote:

    S> Matt,

    S> On Mon, Apr 04, 2005 at 09:33:07PM -0700, Debian Bug Tracking System 
wrote:
    >> Processing commands for [EMAIL PROTECTED]:

    >> > reopen 274969
    >> Bug#274969: smbd consumes available CPU cycles
    >> Bug#286818: /var/run/samba/messages.tdb growing up indefinitely
    >> Bug#295256: samba: hangs on printing
    >> Bug reopened, originator not changed.

    S> Can you elaborate?  Can you check the size of the printer .tdb files in
    S> /var/cache/samba/printing/, and delete any grossly oversized ones?  My
    S> suspicion is that this bug is fixed, but that the already-corrupted tdb 
on
    S> your system is still causing problems; sorry for not being more explicit
    S> about this.


Are these files large?  This list seems to include all the printers
I've ever configured on my machine in the last few months, even if I
have subsequently deleted them (I have only one actual printer!).  

Can I simply delete all these .tdb files while samba is not running
and they will be recreated when samba restarts?

    # ls -l /var/cache/samba/printing
    total 484
    -rw-------  1 root root 24576 2005-01-25 14:25 Nib-hpijs.tdb
    -rw-------  1 root root 24576 2005-02-02 14:13 Nib-hp.tdb
    -rw-------  1 root root 24576 2005-01-25 14:44 Nib-ljet.tdb
    -rw-------  1 root root 24576 2005-01-19 17:42 Nibljet.tdb
    -rw-------  1 root root 40960 2004-12-27 17:19 nib.tdb
    -rw-------  1 root root 90112 2004-12-19 16:50 Nib.tdb
    -rw-------  1 root root 24576 2005-01-19 17:42 Nibvavljet.tdb
    -rw-------  1 root root 24576 2005-01-19 14:15 Nibvav.tdb
    -rw-------  1 root root 24576 2005-01-25 14:25 Nib-Vav.tdb
    -rw-------  1 root root 24576 2005-01-25 14:25 Niv-Vav-hpijs.tdb
    -rw-------  1 root root 24576 2004-04-27 21:41 PDFWriter.tdb
    -rw-------  1 root root 24576 2005-01-13 12:14 PostscriptPC.tdb
    -rw-------  1 root root 40960 2005-01-12 21:10 postscript.tdb
    -rw-------  1 root root 24576 2004-04-27 22:12 Postscript.tdb
    -rw-------  1 root root 24576 2004-07-21 00:18 PostScript.tdb
    -rw-------  1 root root 24576 2004-07-20 23:59 printers.tdb


At the same time as that listing, smbd is occupying up to 90% of my
CPU cycles, for no good reason: there are two Windows XP clients
attached which map a couple of samba shares to drive letters, and
recognize a samba printer, but there is no file or printer activity.
An Emacs process on each of the two clients has a number of files open
on the samba shares, but I just tried closing both of them, and smbd
doesn't calm down.  

One oddity that has been there for a while is that the printer
exported by samba shows up on the Windows XP clients as having 153
documents in the queue (I recall 149 as well), even though there are
none when I check on the samba machine with lpq, and indeed when I
look at the print queue from Windows there is nothing in it.  
Clearing the print queue ("cancel all documents") from Windows does
not help, neither does it reduce the 153 documents.  In the past, when
experimenting un/installing Windows and Debian-cupsys/samba printers,
I would occasionally end up with an actual big queue as reported by
Windows, containing seemingly all the documents I had recently printed
from Windows.  The list included successful print jobs that ought to
have subsequently disappeared; I don't know if it included
unsuccessful print jobs.

The CPU cycles actually consumed by smbd seems hard to measure.  

    # ps auxw | grep smb
    root      9873  0.0  0.3  9188 2200 ?        Ss   00:03   0:00 
/usr/sbin/smbd -D
    root      9874 13.4  0.3  9276 2420 ?        R    00:03  93:50 
/usr/sbin/smbd -D
    root     21714  1.8  0.6  9724 3888 ?        S    09:28   2:25 
/usr/sbin/smbd -D

This seems to indicate just about 14% use, and it gives the same
numbers or very close each time I run ps.

Top and gtop, on the other hand, report numbers consistently in the
80-90% range, fluctuating, and sometimes dipping lower.

What's the most helpful way to measure this?




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to