SMBD should use /var/run/cups/cups.sock to talk to cups

[Alexander Jones]

Binary package hint: samba

Hardy has recently been failing to bring lo up automatically for me (separate bug).

The Samba Daemon (SMBD) hangs on startup with this:

alex@flash:~$ sudo strace -p $(pidof smbd)
Process 11132 attached - interrupt to quit
connect(6, {sa_family=AF_INET, sin_port=htons(631), sin_addr=inet_addr("127.0.0.1")}, 16 <unfinished ...>
Process 11132 detached

Issuing a: "sudo ifconfig lo up" fixes everything. Bringing it back down breaks it again.

Does SMBD really need the loopback interface at all? Even if it does, it should not hang if it is not available.

ProblemType: Bug
Architecture: i386
Date: Wed Dec 5 19:36:36 2007
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: vmnet vmblock vmmon fglrx
Package: samba 3.0.27a-1ubuntu1
PackageArchitecture: i386
SourcePackage: samba
Uname: Linux flash 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

[Chuck Short (zulcss)]

https://bugzilla.samba.org/show_bug.cgi?id=4052

This looks like to be the fix in here.

Regards
chuck

[Steve Langasek (vorlon)]

Not related to upstream bug #4052.

port 631 is the ipp port. I can't reproduce this problem here with the current version of Samba, but it appears that your server is set up with 'load printers = yes' and is trying to read the list of available printers from the local cups server. Yes, if your system needs to connect to localhost and can't find a route to it, this is the behavior that will result. I submit that this is a misconfiguration of your network interfaces, not a bug in samba; if you had no network interfaces enabled, then at least the connection attempt would have failed immediately, but to have some network interfaces up without lo being one of them is going to confuse a number of applications, not just samba.

As a workaround, you can either bring the lo interface up (as it should be), or you should be able to stop samba from looking for cups on startup by setting 'load printers = no' or 'printing = bsd'. Either way, I don't think it's the samba package is responsible for compensating for misrouting of 127.0.0.1, so I'm marking this bug as invalid.

[Alexander Jones (alex-weej)]

It seems you're suggesting that the problem is Samba attempting to connect to the print service. So the same scenario arises even if lo is up but CUPS is down?

In the interests of robustness, Samba should bring itself up even if it can't access CUPS.

[Steve Langasek (vorlon)]

If lo is up but CUPS is down, samba will get an immediate 'connection refused' and move on. The problem in this case is that samba has *tried* to connect to localhost, and is getting no answer back - this can only happen if the system's routing tables are misconfigured in such a way that the kernel keeps trying, and failing, to reach 127.0.0.1.

If all your network interfaces are down, the connect() should fail with ENETUNREACH. If your network interfaces are up but cups is not running, connect() fails with ECONNREFUSED. Only when traffic for 127.0.0.1 is being routed somewhere unusual would the connect() hang indefinitely. (Actually, it should only hang for the length of the TCP timeout - which is on the order of a few minutes, so long enough.)

[Alexander Jones (alex-weej)]

Thanks for explaining that. I don't recall why my loopback interface was
down, but I agree it shouldn't have been.

Does Samba absolutely need to connect to CUPS over IP by default? Assuming
there are other ways... I don't know.

[NoOp (glgxg)]

FWIW I have exactly the same problem on Hardy (Alpha 6). If I attempt to browse my other machines (all Gutsy) I _may_ be able to browse one (not consistent) machine's shared folder, but consistently cannot browse another machine's shared folder without: sudo ifconfig lo down/up. Prior to doing so I _always_ check ifconfig and find that: 1) lo is up and 2) I can ping local host.

I have 2 fixed IP's on the Hardy machine & /etc/network/interfaces is:

====
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface

iface eth0 inet static
address 192.168.4.105
netmask 255.255.255.0
gateway 192.168.4.1

iface eth1 inet static
address 192.168.4.104
netmask 255.255.255.0
gateway 192.168.4.1

auto eth1
====

I also have an identical Gutsy machine with dual interfaces as well (different local IP's of course) and have no such problems with Samba.

Request that the status of this bug be changed from "Invalid" to "New" or something else until the problem is determined not to be Samba and/or identified as caused by some other component.

[Steve Langasek (vorlon)]

Alexander,

> Does Samba absolutely need to connect to CUPS over IP by default? Assuming
> there are other ways... I don't know.

Thanks, that's a good point. CUPS does have a UNIX socket that it listens on, and it probably would be better to use that instead of the IP address; if nothing else, Unix sockets have less overhead. Reopening this bug then, and updating the summary to reflect this.

[Steve Langasek (vorlon)]

NoOp,

How did you determine that your problem is the same as this one? This bug refers to smbd hanging on startup; do you have an strace of smbd showing this symptom on your system?

A browsing problem that's fixed by resetting the lo interface does not sound like the same bug; in particular, nmbd, the daemon responsible for advertising browse lists, does not talk to CUPS.

[NoOp (glgxg)]

On 03/18/2008 08:40 PM, Steve Langasek wrote:
> NoOp,
>
> How did you determine that your problem is the same as this one? This
> bug refers to smbd hanging on startup; do you have an strace of smbd
> showing this symptom on your system?
>
> A browsing problem that's fixed by resetting the lo interface does not
> sound like the same bug; in particular, nmbd, the daemon responsible for
> advertising browse lists, does not talk to CUPS.
>

Apologies - I should have engaged brain before posting - wrong bug for
my problem.

[Steve Langasek (vorlon)]

Retesting with the 8.04 release, it appears that libcups will now correctly try to use the unix socket by default before trying to connect to localhost. So I think this bug is now resolved.