net usershare info takes too long (was: Nautilus hangs from time to time)

[falstaff]

Binary package hint: nautilus

When I boot up my laptop and start Nautilus for the first time it always hangs several seconds (~30 seconds). Then it often works for some minutes, and suddenly (especally when i type letters to select a folder) he hangs again. While nautilus hangs, i started several times gdb and printed a backtrace, he prints allways the same backtrace (see attachment). This bug could be a duplcate of several other bugs reporting hangs in nautilus, but they often lack information to descide if this is true... therefor I opened a new one.

The stacktrace lacks some method names, can I do something to print more method names (load symbols?).... I can provide more information if you need, the problem is reproducable all the time (and really anying btw :-))

ProblemType: Bug
Architecture: amd64
Date: Mon Nov 9 23:40:04 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/nautilus
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Alpha amd64 (20091008)
NonfreeKernelModules: nvidia
Package: nautilus 1:2.28.1-0ubuntu2
ProcEnviron:
 PATH=(custom, no user)
 LANG=de_CH.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: nautilus
Uname: Linux 2.6.31-14-generic x86_64

[Pedro Villavicencio (pedro)]

nautilus share issue.

[Chow Loong Jin (hyperair)]

Thank you for reporting this bug. Please install the package "nautilus-share-dbgsym" and get the backtrace again. It's impossible to tell anything from the given information.

You may get this package from the APT repository ddebs.ubuntu.com, by adding the following line to your sources.list, either via system->administration->software sources, or by manually editing /etc/apt/sources.list, or dropping a file containing said line in /etc/apt/sources.list.d:
deb http://ddebs.ubuntu.com karmic main

For more information, please see https://wiki.ubuntu.com/DebuggingProgramCrash

[falstaff (falstaff)]

Thanks, I installed the package and did the same with gdb as I did when I created Stacktrace.txt. As expected, the symbols helped to show the called functions...

bye
falstaff

[Chow Loong Jin (hyperair)]

On Wednesday 11,November,2009 03:00 AM, falstaff wrote:
> Thanks, I installed the package and did the same with gdb as I did when
> I created Stacktrace.txt. As expected, the symbols helped to show the
> called functions...
>
> bye
> falstaff
>
> ** Attachment added: "gdb-nautilus-with-dbgsym.txt"
> http://launchpadlibrarian.net/35493277/gdb-nautilus-with-dbgsym.txt
>
As I expected, it appears to be hanging and waiting for "net usershare info".
Could you run that in a terminal and see what it says? Also, please run "time
net usershare info" to see how long it takes.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[falstaff (falstaff)]

In a first test it seems that the command is executed pretty fast:

$ time net usershare info

real 0m0.206s
user 0m0.000s
sys 0m0.020s

I will try again when i reboot my laptop (because then the hang always happens)

[falstaff (falstaff)]

Yeah, after the reboot the command takes really long:

$ time net usershare info

real 1m24.070s
user 0m0.000s
sys 0m0.000s

I started the command again, and it tooks again very long...

[Chow Loong Jin (hyperair)]

On Wednesday 11,November,2009 06:30 AM, falstaff wrote:
> Yeah, after the reboot the command takes really long:
>
> $ time net usershare info
>
> real 1m24.070s
> user 0m0.000s
> sys 0m0.000s
>
> I started the command again, and it tooks again very long...
>
Hmm so it seems. I'll mark this as affecting samba as well then. net isn't
supposed to take so long to finish.

   affects ubuntu/samba
   status new

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[Thierry Carrez (ttx)]

The timeout seems to point to some name resolution issue, but "net usershare list" is very local...
Anything special in your setup, like username resolution coming from a domain server ? Any hints on what "net usershare info" is doing while it hangs (strace ?). Couldn't find anything related in samba bugzilla.

[falstaff (falstaff)]

Hi,

My setup is a typical home setup, no domain server or something like that, local user accounts. I have a D-Link DIR-855 Router at 192.168.220.1 which also acts as DHCP and DNS-Server (DNS-forwarding or something like that). That router has also the ability to share an attached USB-Harddisk (SMB?), altough, I have no harddisk attached and dont use this feature. But I couldn't find a disable option...

I started strace on net usershare info:
$ time strace net usershare list 2> strace.txt

real 1m24.027s
user 0m0.020s
sys 0m0.040s

I attached the output. He waits for a longer period of time at each "poll([{fd=3, events=POLLIN}], 1, 5000"-line.

When im offline (not connected via Ethernet/WLAN), the command is allways very fast (and therefor nautilus doesnt hang...)

[Thierry Carrez (ttx)]

The trace also seems to point to an issue in your name resolution configuration. Either failing to connect to 192.168.220.1 for name resolution, or failing to get an answer from it...
What happens if you run "ping $(hostname)" ? Could you attach your /etc/resolv.conf and /etc/hosts ?

[Chow Loong Jin (hyperair)]

On Thursday 12,November,2009 03:57 PM, Thierry Carrez wrote:
> The trace also seems to point to an issue in your name resolution configuration. Either failing to connect to 192.168.220.1 for name resolution, or failing to get an answer from it...
> What happens if you run "ping $(hostname)" ? Could you attach your /etc/resolv.conf and /etc/hosts ?
>
Out of curiosity, why does 'net usershare info' need to resolve a hostname? What
hostname would this be anyway?

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[Thierry Carrez (ttx)]

Yes, like I said in comment 9, net usershare list is very local, so it shouldn't really need to resolve names. I suspect some TCP connections against the local system hostname that would trigger a simple resolution (that may fail on faulty setups). If that doesn't prove right, next step is looking in the code itself to understand :)

[Chow Loong Jin (hyperair)]

On Thursday 12,November,2009 04:19 PM, Thierry Carrez wrote:
> Yes, like I said in comment 9, net usershare list is very local, so it
> shouldn't really need to resolve names. I suspect some TCP connections
> against the local system hostname that would trigger a simple resolution
> (that may fail on faulty setups). If that doesn't prove right, next step
> is looking in the code itself to understand :)
>
That's net usershare list. What I'm asking is if net usershare info is any
different?

Anyway, if resolving the local system hostname is what's causing issues, then
perhaps it's a faulty /etc/hosts? falstaff, could you attach your /etc/hosts and
the output of "hostname -f"?

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[falstaff (falstaff)]

Oops, sorry, that was not intended... Again an strace...

$ time strace net usershare info 2> strace-info.txt

real 1m24.015s
user 0m0.030s
sys 0m0.030s

strace-info.txt is attached. It hangs at the same line as "list" does...
$ hostname -f
alpha

hosts and resolv.conf is attached... I don't remember that i changed in this setup. DNS itself works like a charm...

Thanks

[falstaff (falstaff)]

I asked myself why it has two times the same nameserver in this list. Its because im connected two times to that network, over wireless and ethernet. When I disable one connection, one nameserver disappears. Nevertheless the problem persists...

[Thierry Carrez (ttx)]

My trace does not do:
socket(PF_FILE, 0x80801 /* SOCK_??? */, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
...
It jumps directly to:
geteuid() = 1000

Could you attach your /etc/nsswitch.conf, and let me know if you have anything defined for "name resolve order" in /etc/samba/smb.conf ?

[falstaff (falstaff)]

Hi,

I attached nsswitch.conf. The config in question in smb.conf is commented out:
# What naming service and in what order should we use to resolve host names
# to IP addresses
; name resolve order = lmhosts host wins bcast

I think I have a copied version of smb.conf from an older instalation, but I did not experienced such hangs. I discovered that starting the samba daemon also takes a long time...

Bye
falstaff

[falstaff (falstaff)]

I found out what was wrong:

I copied the smb.conf from my old setup, where I used KVM and had several vnet's. This line in smb.conf allowed me to share files only with my virtual machines:

   interfaces = 127.0.0.0/8 vnet0 vnet1 vnet2

I did not setup kvm that way again, therefor I had no vnet0-2. Whireshark showed me that the net command (and I suppose the samba daemon did the same) did DNS requests asking for the IP of this non existent devices (IN A requests for vnet0, vnet1 and vnet2, is this a volitional behaviour?). I removed those non existent devices and the bug is gone now. But anyway, shouldnt call nautilus-share such programms asynchronious then?

Sorry, and thanks for your work!

[Chow Loong Jin (hyperair)]

On Thursday 12,November,2009 10:56 PM, falstaff wrote:
> I found out what was wrong:
>
> I copied the smb.conf from my old setup, where I used KVM and had
> several vnet's. This line in smb.conf allowed me to share files only
> with my virtual machines:
>
> interfaces = 127.0.0.0/8 vnet0 vnet1 vnet2
>
> I did not setup kvm that way again, therefor I had no vnet0-2.
> Whireshark showed me that the net command (and I suppose the samba
> daemon did the same) did DNS requests asking for the IP of this non
> existent devices (IN A requests for vnet0, vnet1 and vnet2, is this a
> volitional behaviour?). I removed those non existent devices and the bug
> is gone now. But anyway, shouldnt call nautilus-share such programms
> asynchronious then?
>
> Sorry, and thanks for your work!
>
Yes, I suppose it should, but 'net usershare info' should *really* finish fast.
I mean, there really isn't any reason 'net usershare info' should be looking
anywhere but the usershares directory, which is local. Even if vnet[0-2] existed
and could be resolved, 'net usershare info' does not use that information in any
way unless I'm mistaken.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[Thierry Carrez (ttx)]

I agree nautilus could be more resistant to that... Closing as invalid nevertheless.

[Thierry Carrez (ttx)]

@Chow Loong Jin: feel free to submit a bug to upstream bugzilla about this, link it to this bug and reopen it as Wishlist.