This is an interesting issue. I have a client that runs Voyage Linux
(based on Debian) running mpd which I use a network audio player. It
accesses a CIFS/SMB share with music files that's served by a device
on my network that runs Debian stable with Samba 3.5.6. Every now and
then, music playback on the client would halt for around a minute and
then resume without any user interaction. My analysis of this issue
lead me to conclude that mpd was NOT the cause of this issue. I also
experienced this issue on another client when playing music off this
share on Windows 7. Nothing suspicious showed up in any system logs
(messages, dmesg, kernel, syslog) on the file server. The file server,
as stated before, runs up-to-date Debian Stable and is basically just
a storage device. There are no printers attached to it and
consequently CUPS isn't installed. I finally decided to enable level 2
debug logging on Samba. This helped me out big time. I noticed that
whenever the playback stopped, I'd soon see a message in either one of
Samba's client-specific logs (log.<CLIENT NAME>) or log.smbd if Samba
wasn't logging to a client log. The messages looked something like
this (taken from a log for the Windows 7 client):
[2011/12/18 02:21:51.821618, 0] printing/print_cups.c:108(cups_connect)
Unable to connect to CUPS server localhost:631 - Connection timed out
[2011/12/18 02:21:51.822314, 2]
printing/print_cups.c:550(cups_async_callback)
cups_async_callback: failed to read a new printer list
I saw that, figured connection time outs are never a good thing to see
anywhere, and concluded I needed to tell Samba to stop trying to
connect to a print server that didn't exist. I edited smb.conf with
these lines added to the [global] section to disable printing via
Samba:
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
So far, I have not seem a recurrence of the log messages about
connections to localhost:631 timing out since disabling printing. I
also have not had a random stop in playback of any audio files
streamed off a Samba share. It seems this fix worked to solve my
problem.
So why am I mailing the list about this? Here's why:
Why is printing enabled on a system that has no connected printers and
doesn't even have CUPS installed? That seems absolutely unnecessary
and just ripe for a latent, hard to root cause problem like I had.
This needs to be fixed, IMO. Debian, especially stable, is about
having a robust operating system without much effort. Either require
CUPS (but this causes bloating for file servers that have no attached
printers), intelligently deploy a config file based on whether or not
CUPS is present or just ask the user at install time if they want to
enable printer sharing. Samba should only be performing the functions
that the user requires of it -- no unfounded assumptions! I don't
recall being asked at install time if I wanted Samba to share my
printers.
However, before I run off and file a bug report against samba-common
(I presume that is the package which supplies the default smb.conf
which I based my Samba config off of), I want to find out if this
isn't just some known issue with Samba or the default smb.conf that's
typically distributed as part of a distribution package. If you are
asked at package installation time whether Samba should share printers
and I just forgot, that would also be helpful. I guess if this is
something that people have just learned and come to accept, it should
just be documented somewhere that Samba on Debian, by default, wants
to talk to CUPS at localhost:631 which may cause problems if CUPS is
not present or traffic is not allowed on that port. I haven't seen
this sort of documentation anywhere obvious.
Thanks for your help,
Jon
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAE5So18FfohDORXnr0TqBnPCATAg_=wrqt8a6ngtjn8srdn...@mail.gmail.com
