Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 454367

Summary: Konqueror will not run as root in user X session
Product: [Fedora] Fedora Reporter: Lacrocivious Acrophosist <altbinspam>
Component: kdebaseAssignee: Ngo Than <than>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 9CC: frank78ac, kevin, ltinkl, rdieter, than, tuxbrewr
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-28 22:36:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Lacrocivious Acrophosist 2008-07-08 00:02:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061712 Fedora/3.0-1.fc9 Firefox/3.0

Description of problem:
Attempting to launch a konqueror instance running as root, while in the userspace X session, fails to load the program and results in a KDE Crash Handler dialog. This occurs when launching from a configured icon, a terminal window as root. Both "konqueror --loadprofile filemanagement" and "kfmclient openProfile filemanagement" give the same results.

The same crash occurs whether running Gnome or KDE desktop, and without change using nv xorg driver or binary nvidia driver, and without change using gdm, kwin, or compiz.

It has been possible to run a root konqueror instance in KDE since at least RedHat 8.0, through each Fedora release including Fedora 8, but does not work in Fedora 9.

If logged in to an X session as root, of course konqueror runs as expected.

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

How reproducible:

Steps to Reproduce:
1.Launch root instance of konqueror from terminal as root, or from congfigured icon to run as root.
2.Enter root password if launching from icon.
3.Observe brief delay, followed by "Konqueror - The KDE Crash Handler".

Actual Results:
The launch always fails with the same Crash Handler appearance and what appears to be an identical backtrace in each instance.

Expected Results:
An instance of konqueror running as root should have loaded on the desktop, just as it has in every RH/Fedora release since RH8 and through F8.

Additional info:
Testbed "frankensystem"; Asus P4VP-MX, P4 2.4GHz, 1.5 GB, nVidia FX-5200, 250GB and 320GB PATA HDs. System is extensively tested, boots and operates fine into Fedora Core 7, Fedora 8, Windows XP Pro, Windows 2000 Server, or Fedora 9 for that matter, absent the above konqueror failure.

gdb backtrace log:

Comment 1 Lacrocivious Acrophosist 2008-07-08 00:05:54 UTC
Errata: Description of problem: First paragraph:

should read:

... when launching from a configured icon, *or* a terminal window as root. Both
"konqueror --profile filemanagement" ...

Comment 2 Steven M. Parrish 2008-07-08 15:31:31 UTC
Unable to reproduce on my F9 system.  Works just fine.  Anyone else able to

Comment 3 Lacrocivious Acrophosist 2008-07-10 02:12:15 UTC
In light of Comment #2 from Steven M. Parrish, who was unable to reproduce this
problem, I will attempt a clean F9 install on a completely different (and more
current) system as soon as possible -- probably five to seven days from now
(09JUN08), unfortunately.

Meanwhile, if anyone else *is* able to reproduce this problem, a word to that
effect is welcome. Otherwise, I recommend to whomever in the development team
this may become assigned, that they place it rather low on their priority list.

Thanks to Mr. Parrish for noting the non-universality of this problem.

Comment 4 Frank Reininghaus 2008-07-10 17:38:09 UTC
This looks like a bug report (and a few duplicates) reported in KDE's 
I've forwarded the backtrace to that report.