adding "sudo" before command in launcher in gnome panel freezes X session

Bug #253504 reported by Ramón Rocha
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-panel (Ubuntu)
Invalid
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gnome-panel

I am using 8.04.1 Server with X and gnome installed.

I have a launcher on one of my gnome panels for "gnome-system-monitor". I wanted to run it with root privileges so I added "sudo" before the command (I did not know I should have been using "gksudo"). When I clicked the launcher, my entire X session froze and was not responsive to the keyboard.

I was unable to switch to another terminal via CTRL+ALT+Fn or kill X via CTRL+ALT+Backspace so I had to ssh in from another machine and kill X and that bash session after which the affected machine became responsive to the keyboard again. I was also able to "startx" again with no problem.

I have not tried to reproduce the issue for fear having to reboot the machine (it is old hardware and sometimes takes a while for the BIOS to pass the POST). I can try though if required for gathering logs, etc.

I would not expect a launcher for "sudo gnome-system-monitor" to work as "gksudo gnome-system-monitor", but it should not freeze the system. If I did not have another computer I would have had to reboot.

Let me know if more information is required.

Revision history for this message
Sebastien Bacher (seb128) wrote :

thank you for your bug report, I just tried on my intrepid installation and can't confirm the issue. was the cursor stucked in busy mode when you had the session frozen? did you look to /var/log/messages and /var/log/syslog after the reboot? was there any useful message there? if ctrl-alt-fn was not working that's not likely a gnome bug

Changed in gnome-panel:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Ramón Rocha (ramon.rocha) wrote :

Thanks for the fast response, Sebastien. The cursor was not stuck, it remained an arrow. However, the default animation that plays when clicking a launcher (icon gets bigger and bigger while fades) was stuck. The icon appeared large and transparent when the screen froze and the keyboard became unresponsive.

I looked in /var/log/messages and only saw entries for when I pushed buttons on my KMV switch (for disconnecting and connecting USB devices). /var/log/syslog only had some info about cron jobs which I did not create so they must be setup default.

If the mouse was still moving, but the keyboard and screen were not working, could it be a bug in X or compiz? I will try to reproduce the issue and report back.

Revision history for this message
Sebastien Bacher (seb128) wrote :

could be a compiz bug, if you trigger the issue again and ssh to the box look if some processus is eating cpu

Revision history for this message
Ramón Rocha (ramon.rocha) wrote :

I was able to reproduce the issue by adding "sudo" before my "gnome-terminal" launcher as well. I was actually hoping I would not be able to reproduce the issue :) The animation did not get stuck this time but the keyboard became unresponsive again.

When I SSHed into the machine the sudo process was occupying 100% of the CPU according to "top". I wasn't expecting that. Killing the sudo process did not make the keyboard start working again. I had to kill xinit at which point I plopped back to a terminal and everything was fine again. Second time I tried it, I killed sudo, killed xinit and all the gnome panels and desktop icons disappeared but I could still see my desktop background image. At this point CTRL+ALT+Backspace worked and I was back the terminal.

This seems strange. The only thing I have noticed in the logs that seems out of the ordinary was this line in syslog which appears after I type "startx":

Jul 31 22:41:25 <machine_name> console-kit-daemon[6278]: WARNING: Unable to activate console: No such device or address

Maybe that is normal. Anything else I could try?

Revision history for this message
Ramón Rocha (ramon.rocha) wrote :

Well, I saw the notification in the panel that some updates were available. I noticed one of them was for gnome-panel (and other packages). I thought "why not?" and installed them. I then tried to reproduce the issue.

Having a sudo before the command in a launcher is no longer locking up the X session! Instead, it opens the tool with root access. I was surprised. However, it never prompted me for a password. Is this because I had already specified it when I ran the Update Manager tool?

I tried logging out and back in to see if that would "reset" it, but I still was not prompted by the launcher. However, attempting to execute the same command from the terminal did prompt me to enter my password.

I was able to execute "sudo gnome-terminal" from a launcher on my panel, it opened a terminal with root@<machine name> and I indeed had root access (tried to write some files in other users' home directories).

I am completely confused now. Is this the expected behavior? Should the user not be prompted for a password when running a command prefixed by sudo from a launcher in a panel or is this working by chance because I performed a system update right before the test?

Revision history for this message
Sebastien Bacher (seb128) wrote :

the sudo ticket is available for 15 minutes once you entered your password so you need to restart or wait this delay before having to enter your sudo password again

Revision history for this message
Ramón Rocha (ramon.rocha) wrote :

Yeah, still freezing up. So the problem is with sudo then?

Revision history for this message
Sebastien Bacher (seb128) wrote :

could you try using a new user configuration? do you get the issue every time? can you switch to a vt after getting the bug?

Revision history for this message
Ramón Rocha (ramon.rocha) wrote :

I tried it on a different computer running 8.04.1 Desktop (as opposed to 8.04.1 Server with X and Gnome installed). I was unable to reproduce the issue. The launcher did not open the application and I also saw that sudo was not even running after clicking the launcher. However, the machine did not lock up. Is this the expected behavior?

On the original computer having the problem, I get the issue every time assuming the sudo ticket is not already available. I am unable to switch to a VT after getting the bug. I must SSH to the machine and kill the rogue processes.

Maybe it's a video card driver issue? The computer where I am able to reproduce the issue has a ATI Radeon 9600 XT and the one that is not having the issue is a NVIDIA GeForce 8800 GTS.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the issue is not likely a video one no, could be due to some user setting though

Revision history for this message
Ramón Rocha (ramon.rocha) wrote :

Sebastien, what is the expected behavior in this situation? If a user prefixes his command in a launcher with 'sudo' instead of 'gksudo' what should happen?

Revision history for this message
Sebastien Bacher (seb128) wrote :

the likely behaviour would be to have nothing visible on screen but the command waiting for a password and running

Revision history for this message
Sebastien Bacher (seb128) wrote :

could you try if that's still an issue in jaunty?

Revision history for this message
Hardik Dalwadi (hardik-dalwadi) wrote :

@Sebastien,

Ubuntu Version

--
#cat /etc/issue
Ubuntu 9.04 \n \l
--

Step to reproduce the bug (Please correct me if i am wrong):

*Make custom launcher of "gnome-system-monitor" to launch as root*

-> "Right Click" on "Gnome Panel" to launch panel manu -> click on "Add Panel" to launch

-> Select "Custom Application Launcher", fill it as below.
  Name: gnome-system-monitor
  Command: sudo gnome-system-monitor
  Comment: Try to launch gnome-system-monitor as root using SUDO
-> Click on "Ok"

Note:
It should create new launcher with custom launcher icon on "Gnome-Panel"
Now, try to click on that that two three times, It should not freeze you X-Session.

Observation:
In my case i am not able to duplicate this issue on 9.04 with latest updates.

Revision history for this message
Ramón Rocha (ramon.rocha) wrote :

Hello,

The old server I originally encountered this issue finally succumbed to age and is no more. Since then, I have built a new server. I tried to reproduce this issue on both my desktop and my server.

The desktop is running a fresh install of 9.04 and I am not able to reproduce the issue there. The sudo process does not even appear in top or in gnome system monitor which is not the expected behavior (but is desirable I suppose). The desktop does not lock up. This is the same behavior I had on my desktop originally.

Very surprisingly though, (or maybe not) I am still able to reproduce the issue on my server which is running Ubuntu Server 9.04 64-bit with X and gnome installed. The original problem was also on the server version of Ubuntu. Maybe that is why people recommend not running X on a server? :)

It's a little different now in that I am able to switch to a VT via CTRL+ALT+Fn, login, kill the process, etc. whereas before this did not work. Other than that, the session is frozen just like before.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Changed in gnome-panel (Ubuntu):
status: Incomplete → New
Revision history for this message
Rajat Khanduja (rajatkhanduja13) wrote :

When I click on the launcher, there is no response (none visible). Even issuing the following command on a terminal shows no output "ps -e|grep sudo".

This shall mean that it is not even running in the background (as earlier mentioned by Sebastien). I think this is a bug in itself (as there is no response to the command).

Changed in gnome-panel (Ubuntu):
status: New → In Progress
Changed in gnome-panel (Ubuntu):
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.