Ubuntu
gksu package

Hangs for 10 seconds when starting an admin app.

Bug #349988 reported by Trouilliez vincent on 2009-03-27

Affects		Status	Importance	Assigned to	Milestone
	gksu (Ubuntu)	New	Low	Unassigned

Bug Description

Binary package hint: gksu

title says it all ;-)

This bug has been around for as long as I can remember. A couple years or more probably.

The problem is that every time I start any admin app in the System->Adminstration menu, like Gparted or Synaptics for example, the application starts instantly once I have entered my password, however, once the application is started and at first sight ready to accept user input, well the mouse cursor is still showing the "busy"/spinning animation for what seems like eternity (about 10 seconds), and at the same time, in the task bar one can see a button labeled "Starting <app name>". After 10 seconds, this button disappears along with the busy cursor, and I can at last use the application.

It's very tedious..

I notice that if I start the same application from a terminal rather than the mouse, using sudo not gksu, that the applications start instantly. The mouse cursor doesn't spin forever nor is there any "starting app" button in the task bar.

I attached a screen cast ilustrating the problem: I first start gparted thourgh the menu (gksu), then from the terminal with sudo, so one can compare easily.

Revision history for this message

Trouilliez vincent (vincent-trouilliez-modulonet) wrote on 2009-03-27:

gksu hanging Edit (6.7 MiB, image/gif)

Revision history for this message

Sebastien Bacher (seb128) wrote on 2009-07-23:

Thank you for your bug report, setting low importance since that's not something most users have having and just an annoyance, would be interesting to know if that's use config specific

Changed in gksu (Ubuntu):
importance:	Undecided → Low

Revision history for this message

gravy45 (gravy45) wrote on 2015-03-20:

I can confirm this on Ubuntu MATE 14.04 with gparted like the user reported, and add to that that sometimes the freeze takes over the whole desktop . It freezes more like 20-25 seconds.

This is additional behavior:
https://bugs.launchpad.net/ubuntu/+source/gksu/+bug/1433854

Summary: gksudo commands can take up to about 15 seconds to complete. While waiting, no other desktop actions can occur, and the screen does not update until control is returned to the terminal.

It shares a little with this: https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/253504
But I'm not creating a launcher.

In the below output, the "Yeah, we're in..." is the last message before everything freezes. Then there is the approximate 15 second delay, the screen comes back and the last three lines of the output show.

rmadcow@msnbc:~$ gksudo --debug caja
No ask_pass set, using default!
xauth: /tmp/libgksu-chlcZO/.Xauthority
STARTUP_ID: gksudo/caja/4857-0-msnbc_TIME12647535
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[4]: GNOME_SUDO_PASS
cmd[5]: -u
cmd[6]: root
cmd[7]: --
cmd[8]: caja
buffer: -GNOME_SUDO_PASS-
brute force GNOME_SUDO_PASS ended...
Yeah, we're in...
xauth: /tmp/libgksu-chlcZO/.Xauthority
xauth_env: /home/rmadcow/.Xauthority
dir: /tmp/libgksu-chlcZO

System info:
System: Host: msnbc Kernel: 3.13.0-46-generic x86_64 (64 bit) Desktop: MATE 1.8.2 Distro: Ubuntu 14.04 trusty
Machine: Mobo: MSI model: 790X-G45 (MS-7622) version: 1.0 Bios: American Megatrends version: V1.8 date: 03/02/2011
CPU: Quad core AMD Phenom II X4 965 (-MCP-) cache: 2048 KB flags: (lm nx sse sse2 sse3 sse4a svm)
Graphics: Card: Advanced Micro Devices [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series]
X.Org: 1.15.1 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1920x1200@60.0hz
GLX Renderer: Gallium 0.4 on AMD CEDAR GLX Version: 3.0 Mesa 10.1.3
Info: Processes: 178 Uptime: 3:45 Memory: 689.6/3953.0MB Client: Shell (bash) inxi: 1.9.17

Revision history for this message

gravy45 (gravy45) wrote on 2015-03-30:

@Sebastien Bacher, I'm sure that if I were in your shoes, I would be saying many of the same things. It is clearly not showing up as a major issue on https://errors.ubuntu.com. Then again, I'm not sure that opening a program as administrator is all that common for most users, so one would expect occurrence to be low. For those running applications as administrator relatively often, it may not be low.

As @Troull.. points out, the issue has been around for quite a while, the difference is "back then" it didn't occur as often. By back then I'm referring to Ubuntu 11.04 and 12.04. Now with Ubuntu MATE 14.04 it happens to me almost all the time. Maybe it can be given somewhat greater importance based on that (since you asked about config-specific) and the additional information I provide below?

What I'm throwing out there is the question: Is this caused by the presence of the .gksu.lock file? And the other question is: Why would that lock file be retained if the (offending) administratively-run program has been closed? Shouldn't that lock file be removed at that moment?

Additional info: the problem seems to begin after there has been a .gksu.lock file created from a previous "Open as Administrator". If there is no .gksu.lock file then at the first "Open as Administrator" the issue does not occur. But when attempting a second "Open as Administrator" and the .gksu.lock is still present from the first, then the delay occurs.