Bug 1303300 - gvfsd-smb-browse causes 100% CPU usage
gvfsd-smb-browse causes 100% CPU usage
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
24
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Guenther Deschner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-30 07:49 EST by Alex Willmy
Modified: 2016-12-20 13:31 EST (History)
26 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 13:18:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logfile of gvfs (13.97 KB, text/plain)
2016-01-30 07:49 EST, Alex Willmy
no flags Details

  None (edit)
Description Alex Willmy 2016-01-30 07:49:28 EST
Created attachment 1119633 [details]
Logfile of gvfs

Description of problem:
Whenever I use a file open or save dialog in an application gvfsd-smb-browse causes 100% CPU usage on one of my cores until I kill it manually. I don't have a Windows network, in fact my laptop is the only computer in the local network.

After some investigation I discovered that part of the problem is my ISP. They offer a "feature" to provide customers with a special search site whenever they type an invalid address into their browser. This is implemented on the DNS level. So when gvfs-smb  tries to connect to the non-existing host MYGROUP.localdomain, instead of a DNS error my ISP returns the IP of their search site, which gvfs-smb is then trying to connect to and that causes CPU usage to rise to 100%.

Version-Release number of selected component (if applicable):
1.26.2

How reproducible:
Every time

Steps to Reproduce:
1. Add an invalid host name entry to /etc/hosts e.g
   192.168.123.43   MYGROUP
2. open gedit
3. click save

Workaround:
To work around this problem, either configure a custom DNS server in network settings (like Google's 8.8.8.8 for example) or simply remove gvfs-smb.
Comment 1 Ondrej Holy 2016-02-01 04:27:36 EST
Thanks for your bug report. It sounds like a bug in samba, because gvfs just call SMBC_opendir_ctx and it hangs there...

See backtrace in time of hang:
Thread 2 (Thread 0x7fe4a1510700 (LWP 30003)):
#0  0x00007fe4b92b5cb7 in fcntl () from /lib64/libpthread.so.0
#1  0x00007fe4b2713d26 in async_connect_send () from /usr/lib64/samba/libsmb-transport-samba4.so
#2  0x00007fe4b782df47 in open_socket_out_connected () from /lib64/libsmbconf.so.0
#3  0x00007fe4b5ca8be4 in tevent_common_loop_immediate () from /lib64/libtevent.so.0
#4  0x00007fe4b5cada2e in epoll_event_loop_once () from /lib64/libtevent.so.0
#5  0x00007fe4b5cac137 in std_event_loop_once () from /lib64/libtevent.so.0
#6  0x00007fe4b5ca838d in _tevent_loop_once () from /lib64/libtevent.so.0
#7  0x00007fe4b5ca95ff in tevent_req_poll () from /lib64/libtevent.so.0
#8  0x00007fe4b8ce31ee in tevent_req_poll_ntstatus () from /lib64/libtevent-util.so.0
#9  0x00007fe4b7cb3980 in cli_connect_nb () from /usr/lib64/samba/liblibsmb-samba4.so
#10 0x00007fe4bb01a03d in SMBC_server_internal () from /lib64/libsmbclient.so.0
#11 0x00007fe4bb01a95d in SMBC_server () from /lib64/libsmbclient.so.0
#12 0x00007fe4bb0139ef in SMBC_opendir_ctx () from /lib64/libsmbclient.so.0
#13 0x0000000000405cb6 in do_mount (backend=<optimized out>, job=0x8fc2f0, mount_spec=<optimized out>, mount_source=<optimized out>, is_automount=<optimized out>)
    at gvfsbackendsmbbrowse.c:974
#14 0x00007fe4badf176a in g_vfs_job_run (job=0x8fc2f0) at gvfsjob.c:197
#15 0x00007fe4b9748731 in g_thread_pool_thread_proxy (data=0x8ee170) at gthreadpool.c:307
#16 0x00007fe4b9748157 in g_thread_proxy (data=0x7fe49c0044f0) at gthread.c:780
#17 0x00007fe4b92ad60a in start_thread () from /lib64/libpthread.so.0
#18 0x00007fe4b8fe7a4d in clone () from /lib64/libc.so.6

It time outs after several minutes and cpu usage go down...
do_mount - URI = smb://MYGROUP/
do_mount - try #0 
looking up cached server 'MYGROUP'\'IPC$', user 'MYGROUP';'oholy'
  returning (nil)
auth_callback - anonymous pass
auth_callback - out: last_user = 'oholy', last_domain = 'MYGROUP'
looking up cached server 'MYGROUP'\'IPC$', user 'MYGROUP';'oholy'
  returning (nil)
...
do_mount - [smb://MYGROUP/; 0] dir = (nil), cancelled = 0, errno = [110] 'Connection timed out' 
do_mount - (errno != EPERM && errno != EACCES), cancelled = 0, breaking
send_reply(0x8fc2f0), failed=1 (Failed to retrieve share list from server: Connection timed out)
purging server cache

Let's change the component to samba...
Comment 2 Stefan Hajnoczi 2016-04-08 09:03:49 EDT
I'm experiencing the same problem and also use an ISP that has a landing page for unknown domain names.

gvfs-smb-1.26.3-1.fc23.x86_64

The following process consumes 100% CPU:
/usr/libexec/gvfsd-smb-browse --spawner :1.9 /org/gtk/gvfs/exec_spaw/4

Here is the call stack:
Thread 5 (Thread 0x7fd178e13700 (LWP 6358)):
#0  0x00007fd18ee4efdd in poll () at /lib64/libc.so.6
#1  0x00007fd18f58316c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007fd18f58327c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007fd18f5832b9 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007fd18f5a9835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007fd18f12060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007fd18ee5aa4d in clone () at /lib64/libc.so.6
Thread 4 (Thread 0x7fd173fff700 (LWP 6359)):
#0  0x00007fd18ee4efdd in poll () at /lib64/libc.so.6
#1  0x00007fd18f58316c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007fd18f5834f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007fd18fba4336 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007fd18f5a9835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007fd18f12060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007fd18ee5aa4d in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7fd172ffd700 (LWP 6361)):
#0  0x00007fd18ee4efdd in poll () at /lib64/libc.so.6
#1  0x00007fd18f58316c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007fd18f58327c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007fd17840d2ad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007fd18f5a9835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007fd18f12060a in start_thread () at /lib64/libpthread.so.0
#6  0x00007fd18ee5aa4d in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7fd1727fc700 (LWP 6362)):
#0  0x00007fd18f128dfd in connect () at /lib64/libpthread.so.0
#1  0x00007fd1887b6dce in async_connect_send () at /usr/lib64/samba/libsmb-transport-samba4.so
#2  0x00007fd18d6a0f47 in open_socket_out_connected () at /lib64/libsmbconf.so.0
#3  0x00007fd18bb0cbe4 in tevent_common_loop_immediate () at /lib64/libtevent.so.0
#4  0x00007fd18bb11a2e in epoll_event_loop_once () at /lib64/libtevent.so.0
#5  0x00007fd18bb10137 in std_event_loop_once () at /lib64/libtevent.so.0
#6  0x00007fd18bb0c38d in _tevent_loop_once () at /lib64/libtevent.so.0
#7  0x00007fd18bb0d5ff in tevent_req_poll () at /lib64/libtevent.so.0
#8  0x00007fd18eb561ee in tevent_req_poll_ntstatus () at /lib64/libtevent-util.so.0
#9  0x00007fd18db26a60 in cli_connect_nb () at /usr/lib64/samba/liblibsmb-samba4.so
#10 0x00007fd190e4be44 in SMBC_server_internal () at /lib64/libsmbclient.so.0
#11 0x00007fd190e4c95d in SMBC_server () at /lib64/libsmbclient.so.0
#12 0x00007fd190e459ef in SMBC_opendir_ctx () at /lib64/libsmbclient.so.0
#13 0x00005615fc5acf01 in do_mount ()
#14 0x00007fd190c22baa in g_vfs_job_run () at /usr/lib64/gvfs/libgvfsdaemon.so
#15 0x00007fd18f5aa1ce in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#16 0x00007fd18f5a9835 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#17 0x00007fd18f12060a in start_thread () at /lib64/libpthread.so.0
#18 0x00007fd18ee5aa4d in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7fd1911f1840 (LWP 6356)):
#0  0x00007fd18ee4efdd in poll () at /lib64/libc.so.6
#1  0x00007fd18f58316c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007fd18f5834f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00005615fc5adcda in daemon_main ()
#4  0x00005615fc5aa99f in main ()
Comment 4 Ondrej Holy 2016-05-10 03:59:50 EDT
It is reproducible even with "smbclient -L MYGROUP". This causes high cpu usage for 2 minutes before "Connection to MYGROUP failed (Error NT_STATUS_IO_TIMEOUT)" is returned. However the error was returned almost immediately and without high cpu load with earlier versions of samba...

(In reply to collura from comment #3)
> the comment at 
> 
>   
> https://ask.fedoraproject.org/en/question/86178/gvfsd-smb-browse-heating-my-
> computer/
> 
> has this as being upstream as:
> 
>    https://bugzilla.gnome.org/show_bug.cgi?id=762580

This upstream report is for Nautilus, however the bug is in samba, can you please file a bug report on bugzilla.samba.org?
Comment 5 collura 2016-05-11 18:12:22 EDT
from comment#4 upstream filing a request for SMBC_opendir_ctx:

  looks like it might already be there as

     https://bugzilla.samba.org/show_bug.cgi?id=11574
Comment 6 Ondrej Holy 2016-05-12 04:11:10 EDT
The bug you mentioned is definitely something else. It is about crashes, not hangs and the backtrace is totally different.
Comment 7 seeker_moc 2016-05-20 14:10:07 EDT
I'm also experiencing the same bug when using a public wifi service that has a captive portal login. I never had this problem on my home internet connection. Running "smbclient -L MYGROUP" also gives me a couple of minutes of 100% CPU on a second core. After smbclient exits with timeout error the gvfsd-smb-browse process continues to take 100% for another few minutes, then eventually stops itself as well.
Comment 8 Brett Bogert 2016-06-04 16:40:24 EDT
I was also experiencing this bug in Ubuntu 16.04 and was able to reproduce
it in Fedora 24 Beta. After doing some research and troubleshooting I was
able to come up with the following workaround(fix ?).

This bug is being tracked in Ubuntu under launchpad bug #1409032 for
reference.

Note: This change only addresses the 100% CPU usage when opening
the Nautilus file browser after a initial boot or reboot. I am 
not sure what other issues with gvfsd-smb-browse and 100% CPU
usage this may impact so your experience may vary.

1- Make a back up of your /etc/samba/smb.conf file.

2- Using your preferred editor edit the smb.conf file and
add the following line below the "[global]" statement:

name resolve order = wins lmhosts bcast

Your file should look like this:

[global]
name resolve order = wins lmhosts bcast

3- Save the file and reboot.

This should resolve the 100% CPU usage problem and you should notice
that the "Network" Icon and label should appear in your file browser
much quicker that before.

I was only able to test this workaround/fix in Ubuntu 16.04 as I
could not find up to date information on how to restart the samba
service in Fedora 24(I tried both /sbin/service and systemctl
commands but they did not work).

If someone can test this on Fedora 24 I would appreciate it (Note it
requires an active internet connection to reproduce the problem).

Hope this helps
Comment 9 seeker_moc 2016-06-04 21:06:51 EDT
I can confirm this prevents the 100% CPU issue from occurring on Fedora 24. However, I am not currently at a location with an available Samba share, so I can't test to confirm whether this potentially breaks any kind of expected functionality.
Comment 10 Paul Gier 2016-08-22 11:24:00 EDT
Brett's fix (comment#8) seems to fix the issue for me on Fedora 24.  And I am able to access a windows share after changing my smb.conf file and rebooting.
Comment 11 Fedora End Of Life 2016-11-24 10:17:31 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 12 Andreas Schneider 2016-11-25 03:53:45 EST
Does the problem still occur on F25?
Comment 13 David Strauss 2016-11-26 21:34:32 EST
This problem certainly occurs still on F24. I haven't tried on F25.
Comment 14 Fedora End Of Life 2016-12-20 13:18:49 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.