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.
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...
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 ()
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
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?
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
The bug you mentioned is definitely something else. It is about crashes, not hangs and the backtrace is totally different.
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.
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
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.
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.
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.
Does the problem still occur on F25?
This problem certainly occurs still on F24. I haven't tried on F25.
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.