Description of problem: Modify a launcher e.g. dolphin using the Edit Launcher -> application tab -> Advanced options -> Run as different user Enter "root" as user and OK the dialog. Clicking the launcher correctly asks for root password, but then there is a delay of over a minute before the application opens. Similarly if Kate is opened by clicking on a text file from within the root dolphin, it too opens after a long delay. The delay is variable, there is nothing obviously wrong in top, cpu usage is low. Nothing in logs that seem related. If I open dolphin as root from a terminal with: kdialog --password 'Enter root password' | su - -c dolphin or indeed just as root with su - dolphin ... there is no delay opening dolphin nor when opening kate from within it. I have used dolphin like this for years without issues, even had it's own red icon, until the last few months in cauldron when this has become a problem. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Testing in a VM the delay occurs for a real user (20 seconds) but for Xguest there is no delay. Testing with a different real user on real hardware the delay is there (50 seconds). I don't currently have Xguest on a real system to test.
CC: (none) => balcaen.john, lmenut, mageiaBlocks: (none) => 12079
Does the same delay occur when you run that application via kdesu?
CC: (none) => doktor5000
(In reply to Florian Hubold from comment #2) > Does the same delay occur when you run that application via kdesu? Yes /OT Why is kdesu not in $PATH? It took a bit of finding to do the test. /usr/lib64/kde4/libexec/kdesu is not exactly intuitive :\
(In reply to Barry Jackson from comment #3) > (In reply to Florian Hubold from comment #2) > Why is kdesu not in $PATH? It took a bit of finding to do the test. > > /usr/lib64/kde4/libexec/kdesu is not exactly intuitive :\ kdesu is probably primarily meant to be run via krunner (Alt+F2) where it is in the path. Otherwise, confirming the issue. Although it's not really critical overall, as running via su - or kdesu still works. Will test with xguest on real hardware shortly. FWIW, what graphics chip and what driver do you use? proprietary nvidia maybe?
(In reply to Barry Jackson from comment #3) > (In reply to Florian Hubold from comment #2) > > Does the same delay occur when you run that application via kdesu? > > Yes > > /OT > Why is kdesu not in $PATH? It took a bit of finding to do the test. > > /usr/lib64/kde4/libexec/kdesu is not exactly intuitive :\ kdesu is not aimed to be used in konsole like this. so this is not an issue.
(In reply to Florian Hubold from comment #4) > (In reply to Barry Jackson from comment #3) > > (In reply to Florian Hubold from comment #2) > > Why is kdesu not in $PATH? It took a bit of finding to do the test. > > > > /usr/lib64/kde4/libexec/kdesu is not exactly intuitive :\ > > kdesu is probably primarily meant to be run via krunner (Alt+F2) where it is > in the path. Otherwise, confirming the issue. Although it's not really > critical overall, as running via su - or kdesu still works. No, running via kdesu does not work, it produces the delay as I confirmed above. Running as root using "su -" is the only option that works. I consider it critical, as a feature is broken which should work, and until mga4 has always worked. > > Will test with xguest on real hardware shortly. > > FWIW, what graphics chip and what driver do you use? proprietary nvidia > maybe? Basic onboard Intel - no fancy graphics card. From hwinfo: 15: PCI 02.0: 0300 VGA compatible controller (VGA) [Created at pci.319] Unique ID: _Znp.TE0vqGgTKoB SysFS ID: /devices/pci0000:00/0000:00:02.0 SysFS BusID: 0000:00:02.0 Hardware Class: graphics card Model: "Intel VGA compatible controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x0162 SubVendor: pci 0x1458 "Giga-byte Technology" SubDevice: pci 0xd000 Revision: 0x09 Driver: "i915" Driver Modules: "drm" Memory Range: 0xf7800000-0xf7bfffff (rw,non-prefetchable) Memory Range: 0xe0000000-0xefffffff (ro,non-prefetchable) I/O Ports: 0xf000-0xf03f (rw) IRQ: 41 (14705 events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: "pci:v00008086d00000162sv00001458sd0000D000bc03sc00i00" Driver Info #0: Driver Status: i915 is active Driver Activation Cmd: "modprobe i915" Config Status: cfg=new, avail=yes, need=no, active=unknown
Raising priority/severity as this is a real PITA. Still happening in real and VBox fully updated Cauldron installs.
Priority: Normal => HighSeverity: normal => major
Seems we got sort of a reverse case of the original bug: In Mageia 4, kwrite (as an example) does not start when launched from the menu When changing the launcher to run as user and putting in your actual username there, it works as intended. That is with nvidia driver 325.15, so the nvidia driver should not be the cause, cf. https://bugs.mageia.org/show_bug.cgi?id=12079 Can someone from KDE team please take a look at this? Both issues should be fixed. If required, I'll clone this bug into a new one for this issue.
CC: (none) => neoclust
OK, after hours of testing I think I found the culprit. It seems to be fixed by the removal of the qtatspi-plugin package which is required by onboard. I have emailed the KDE developer of qtatspi-plugin in the hope that he may have some insight on this. @Florian yes I think that's a different issue so another bug is best.
I have opened a bug with Onboard upstream as they suggested qtatspi-plugin as require for some Onboard functionality. https://bugs.launchpad.net/onboard/+bug/1302056
Summary: When running KDE apps as root from a modified launcher they take 1min+ to open => qtatspi-plugin causes delay opening KDE GUI applications as root
This does seem to be a qtatspi-plugin problem related to dbus, which is confirmed by the author of qtatspi, but no solution has been suggested. For now I have made qtatspi-plugin a 'suggest' of onboard so that it may be removed if required to work around this issue. (with some loss of features). Extracts from an email from the author of qtatspi: "So it is due to the dbus session being started. I'd be interested to know how Gnome handles this - does accessibility work for Gnome apps running as root? I don't see a way to connect to the user's session bus. Of course Gnome might use xatoms to find the bus address - I'm not fond of using that way since it's not wayland compatible. " "Yes, qtatspi is using the dbus session to discover the accessibility bus address and is thus to be blamed." @Marmuta: maybe you can answer this?
Any progress on that bug ? is it still valid for current cauldron?
CC: (none) => ennael1
No - qtatspi-plugin has only had one unrelated upstream commit this year. As workaround I uninstall it in KDE, to avoid the annoying delay. For most 'normal' users (meaning those who are unlikely to want to run KDE GUI applications as root) this is not an issue. Maybe should be mentioned in errata?
I think a mention in the Errata would be nice yes. Can you handle it Barry?
CC: (none) => remi
(In reply to Rémi Verschelde from comment #14) > I think a mention in the Errata would be nice yes. Can you handle it Barry? Yes - will do.
https://wiki.mageia.org/en/Mageia_5_Errata#KDE
Should we mark this one as WONTFIX, or is there something that we can do to improve the situation? Is qtatspi-plugin doing its job properly apart from causing this bug, or could it be removed from KDE recommended packages?
(In reply to Rémi Verschelde from comment #17) > Should we mark this one as WONTFIX, or is there something that we can do to > improve the situation? Nothing more I can do, so either leave it open or close it, I don't have a preference. > Is qtatspi-plugin doing its job properly apart from > causing this bug, Yes perfectly. > or could it be removed from KDE recommended packages? I don't understand - it is only 'Recommended' by onboard which works without it, with reduced functionality. The bug *only* affects the *startup* of KDE GUI packages that are started as *ROOT* when qtatspi-plugin is installed. Since this is a corner use case I think the errata is adequate and we can live with it.
(In reply to Barry Jackson from comment #18) > (In reply to Rémi Verschelde from comment #17) > > > or could it be removed from KDE recommended packages? > > I don't understand - it is only 'Recommended' by onboard which works without > it, with reduced functionality. Ok this was a misunderstanding on my side, I forgot the onboard middle man :) > Since this is a corner use case I think the errata is adequate and we can > live with it. Let's leave the bug report open, since it's not fixed and we would still like to fix it (so it's not strictly speaking a WONTFIX). I'll just remove it from the release_blocker KDE bugs tracker.
Blocks: 12079 => (none)
Priority: High => NormalSeverity: major => normal
CC: lmenut => (none)
Is this bug still present in current cauldron?
Keywords: (none) => NEEDINFOAssignee: bugsquad => kde
I thought that I did not have qtatspi-plugin installed as I have not seen this issue for a while now. Anyway - on checking, it *is* installed, so maybe recent plasma5 has somehow fixed this. This Cauldron has been installed for a few months now, so the plugin must have been there since install and during that time I have not had the issue or I would have removed it. Guess we can close it \o/
Status: NEW => RESOLVEDResolution: (none) => FIXED