|
Bugzilla – Full Text Bug Listing |
| Summary: | Konqueror hangs, ~2min delay before main window. No error messages (timeouts in strace) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Johan Persson <johanp> |
| Component: | KDE Applications | Assignee: | E-mail List <kde-maintainers> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | forgotten_DV81ZEWZkN |
| Version: | 13.1 Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SUSE Other | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=325212 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Trace file from running strace on konqueror | ||
Just discovered that starting Konqueror as root works. As root konqueror behaves as usual. It only hangs when started as a normal user. Same with Firefox. Still the same problem with 13.1beta. Other applications including networked ones work just fine starting them as a normal user (for example Chrome or Firefox) Again, starting konqueror as root makes it display the application window directly. Cause for this problem identified. The problem is caused by a blocked DBUS. This blockage in turn is caused by the Blueetooth service (kded) which has been wrongly enabled by the Suse installation since this server does not have any BT device. The old 12.3 installation did not have this issue. So this problem should be re-categorized as installation related to BT Closed. New bug opened to track the installations issue Bug #842173 Johan, can you paste the contents of /etc/pam.d/common-session file? Not sure if this helps but here it is: #%PAM-1.0 # # This file is autogenerated by pam-config. All changes # will be overwritten. # # Session-related modules common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define tasks to be performed # at the start and end of sessions of *any* kind (both interactive and # non-interactive # session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_umask.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm session optional pam_env.so I see. Adding pam_systemd.so should resolve it... *** This bug has been marked as a duplicate of bug 812462 *** |
Created attachment 557108 [details] Trace file from running strace on konqueror User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22 On a machine that previously run OpenSuSE 11.4 64bit just fine I installed 64 bit version of OpenSuSE 13.1M4 to do some testing on a real system. The installation was done using the network ISO. The installations seems to work fine, the KDE desktop works as expected, Yast2 works fine etc. The installation therefore seems to have succeeded. However, trying to run Konqueror of Firefox either directly from command line or from a KDE menu does not work. On the command line the command can be entered and then it just hangs there for about 2 minutes. Then the Konqueror window is opened but it is unresponsive and it is impossible to do anything with it. I have reinstalled three times with the same result. Thinking that this is a network issue I tried running both ssh, ftp and text-browser "links" to other sites/servers and they all worked fine which somewhat nullifies the idea about a general network issue. I also verified DNS using a ping to "idg.com" which works just fine. Doing an "strace" when running konqueror reveals that it gets 4 timeouts (* 25s) which counts for the roughly 2 minutes before the main application window is opened. Since command line network program works just fine I guess this could be a KDE network issue. The interesting bit of the strace output from konqueror seems to be (full trace included as attachment) ... poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1I\0\0\0%\0\0\0o\0\0\0\1\1o\0\21\0\0\0/modules"..., 128}, {"D\0\0\0https://en.wikipedia.org/wik"..., 73}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 201 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0&\0\0\0{\0\0\0\1\1o\0\21\0\0\0/modules"..., 144}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 144 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1k\0\0\0'\0\0\0o\0\0\0\1\1o\0\21\0\0\0/modules"..., 128}, {"f\0\0\0http://search.yahoo.com/sear"..., 107}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 235 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout) ... Firefox has the same symptom and similar timeout issues. Reverting back to 11.4 (or 12.3) gives a fully working system so this seems to indeed be a issue with 13.1M4 (at least on my machine). Reproducible: Always Steps to Reproduce: 1. See description in details.