gksu dies on first run

Thanks for your bugreport, this should be fixed with the latest upload of gksu/libgksu in edgy. Unfortunately gksu is not build yet.

Hm... was this meant to have been fixed in the version published 2006-08-11 16:03:16 EDT 1.9.3-1ubuntu2? If so, I don't think it's been solved yet. I've been seeing weird problems with update-manager which I believe are attributable to this bug. After I log in and run update-manager the first time, when I click the Check button, the update-manager desensitizes, and gksu attempts to launch, but its window never appears. I must kill gksu from the GNOME System Monitor for things to start working right. After that, everything's peachy.

I'm seeing this again today. I can't get update manager to successfully call gksu and must manually kill it myself.

Can you still reproduce this? If so, can you please make it hang and than check the process id of the haning gksu? With that, you can run:
$ sudo strace -p $pid 2> /tmp/gksu.strace
(where $pid is the number, eg 1234)
Leave it runing for a bit and then press CTRL-C to stop strace tracing the process.

and
$ sudo gdb -p $pid
(gdb) backtrace

and attach both the file and the backtrace to this report?

Thanks,
 Michael

Just got it again. Here are some backtraces:

of the gksu process:
(gdb) backtrace
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x462eee40 in __nanosleep_nocancel () from /lib/tls/i686/cmov/libc.so.6
#2 0x46326bac in usleep () from /lib/tls/i686/cmov/libc.so.6
#3 0x48375670 in gksu_sudo_full () from /usr/lib/libgksu2.so.0
#4 0x48377387 in gksu_run_full () from /usr/lib/libgksu2.so.0
#5 0x0804a485 in ?? ()
#6 0x080708c8 in ?? ()
#7 0x00000000 in ?? ()
(gdb)

Of the sudo process:
(gdb) backtrace
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x4631db43 in __read_nocancel () from /lib/tls/i686/cmov/libc.so.6
#2 0x08050fa8 in ?? ()
#3 0x00000000 in ?? ()
(gdb)

I'll now run strace and attach the result.

the sudo process is hanging on a read from stdin.

Here's the ps axf process tree:

13916 ? Sl 0:06 /usr/bin/python /usr/bin/update-manager
14387 ? S 0:01 \_ gksu --desktop /usr/share/applications/update-manager.desktop -- /usr/sbin/synaptic --hide-main-window --non-interactive --parent-window-id 60817411 --update-at-sta
14403 ? Ss 0:00 \_ /usr/bin/sudo -H -S -p GNOME_SUDO_PASS -u root -- /usr/sbin/synaptic --hide-main-window --non-interactive --parent-window-id 60817411 --update-at-startup
1

Attached is the strace for gksu

After doing "sudo killall sudo", I was able to press the "Check" button in update-manager again and it succeeded in asking for my password.

Hmm... I'm seeing this a lot in edgy again.

I'm seeing this in feisty, too, now that I've upgraded.

An error report from a fresh install of Edgy i386.

Immediately after sending the report above, I went back and tried update-manager again and was successful.

I'm still getting this error on Feisty ;_;

I'm having pretty much the same symptoms as everybody else, it's just most annoying with Update Manager because it hangs if it doesn't get a response from gksu.

I'm still seeing this in gutsy, and I may have narrowed down the circumstances when it happens for me (at least in recent memory).

When I've got a lot of things going on (starting up a few applications like evoution and firefox), gksu will never pop up on the first call. What appears to be happening is that if there aren't enough resources to get the gksu GUI up in 5 or 10 seconds, it decides not to do it at all. It may work the second time because the gksu binary and its resources are already loaded into the file cache and can fire up the GUI in a short amount of time.

Now, when I see stuff like the following in libgksu-2.0.5/libgksu/libgksu.c (around line 2577), I get doubly concerned that there may be timing bugs causing this problem:
      { /* no matter if we can read, since we're using
           O_NONBLOCK; this is just to avoid the prompt
           showing up after the read */
        fd_set rfds;
        struct timeval tv;

        FD_ZERO(&rfds);
        FD_SET(parent_pipe[0], &rfds);
        tv.tv_sec = 1;
        tv.tv_usec = 0;

        select (parent_pipe[0] + 1, &rfds, NULL, NULL, &tv);
      }

Just had this occur on the latest gutsy on my new core 2 duo thinkpad with 2G of RAM. I had launched a bunch of apps and requested a "check for updates" from update manager.

Same problem here. I'm running the latest Hardy-Aplha in an Virtualmachine (VirtualBox - OSE - 1.5.0 - gutsy repos). My machine is an Pentium3 with 1GHz and 512MB Ram. So i have 256 for the Host-System and 256 for the Guest-System (it's not what i would call fast, but it works). I just start the Hardy-Alpha in the VM and the first thing i do is, i start the update-manager an nothing happens. The update-manger doesn't proceed because he's waiting for gksu. So i have to kill the gksu-process, wait for the update-manager and press the "install update-button" again. On the second try gksu appears and everything works fine.

maybe this is also helpful:

$ ps afx
5383 ? Sl 0:23 /usr/bin/python2.5 /usr/bin/update-manager
5394 ? S 0:07 \_ gksu --desktop /usr/share/applications/update-manager.desktop -- /usr/sbin/synaptic --hide-main-window --non-interaktive --parent-window-id 39845891 --update-at-startup
5396 ? Ss 0:00 \_ /usr/bin/sudo -H -S -p GNOME_SUDO_PASS -u root -- /usr/sbin/synaptic --hide-main-window --non-interaktive --parent-window-id 39845891 --update-at-startup

$ strace -p 5383
Process 5383 attached - interrupt to quit
select(0, NULL, NULL, NULL, {0, 36000}) = 0 (Timeout)
read(4, 0x834a80c, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1204018380, 431100}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=10, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}], 8, 0) = 0

$ strace - p 5394
Process 5394 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
waitpid(5396, 0xbf9e411c, WNOHANG) = 0
stat64("/proc/5396", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/5396/stat", O_RDONLY) = 24
read(24, "5396 (sudo) S 5394 5396 5396 0 -"..., 8191) = 196
close(24) = 0
nanosleep({0, 100000000}, NULL) = 0

I can confirm tha this problem has returned with Hardy.
A couple of days ago, i've installed Hardy alpha6 over Gutsy, and since then, the exact same thing happened to me as stonerl and his precursors described above.
This install is on a Sempron 2800+, 1GB RAM and 32GB of diskspace left.

I can verify this for a Packard Bell IPower J9500 PC and a Sony Vaio VGN NR-21E/S. Managing the system really gets complicated. I have just installed the hardy-heron release.

I'm sorry. It was my mistake: gksu didn't work because of the new PolicyKit... I had to enable 'manage system configuration' for my admin user. Maybe I should think first...

Where is this "manage system configuration" option in Hardy? I can't find it in Users and Groups. I had to disable tty_tickets in /etc/sudoers to get gksu to work at all.

I have the problem to now and I am running ubuntu 8.04.

I am seeing this problem in Hardy

Update: I solved the problem by changing /etc/hosts:

http://ubuntuforums.org/archive/index.php/t-613521.html
http://ubuntuforums.org/showthread.php?t=753427

Could you please try the package of libgksu2-0 in hardy-proposed ? It hopefully fixes the problem.

Michael Vogt wrote:
> Could you please try the package of libgksu2-0 in hardy-proposed ? It
> hopefully fixes the problem.
>
>
I'm sorry, cannot access to the system that had the issue :/ Anyway,
it's working for me on several machines.

> Could you please try the package of libgksu2-0 in hardy-proposed ? It hopefully fixes the problem.

Can you give a link to the .deb ?

I'd rather not add hardy-proposed to sources.list, but I'm happy to install the single package. Less variables that way.

This is a pretty nasty bug, it prevents many newbies from upgrading their systems.

Mark Robinson wrote:
>> Could you please try the package of libgksu2-0 in hardy-proposed ? It
> hopefully fixes the problem.
>
> Can you give a link to the .deb ?
>
> I'd rather not add hardy-proposed to sources.list, but I'm happy to
> install the single package. Less variables that way.
>
> This is a pretty nasty bug, it prevents many newbies from upgrading
> their systems.

I tried it, and it does not fix the problem. However, I did notice
something interesting: One of the machines where I saw the problem had
128MB RAM, and the other, 256MB. When both machines were upped to 512MB,
the problem disappeared. Temporarily reducing the RAM again reintroduced
it again. Going back to 512 made it disappear again. It also seems to be
irrespective of how much swap there is. I have not yet tried any amount
of RAM between 256 and 512.

The machines I've seen this on are also RAM starved.

I looked into the code and I think I found a possible problem that might trigger this problem under heavy io load or memory pressure. I uploaded a new version to my PPA and I would be interessted in feedback if that fixes the issue for you.

deb http://ppa.launchpad.net/mvo/ubuntu hardy main

Feedback is welcome.

Adding Michael's PPA to my sources.list, then updating and upgrading with aptitude appears to have sorted this out on this machine.

The following packages have been kept back:
  synaptic [0.61ubuntu9 -> 0.62.1ubuntu1~ppa2]
The following packages will be upgraded:
  f-spot [0.4.3.1-0ubuntu1 -> 0.4.3.1-0ubuntu2~ppa1] friendly-recovery
[0.1.2 -> 0.2~ppa1]
  libgksu2-0 [2.0.5-1ubuntu5.1 -> 2.0.7-1ubuntu2.1] python-apt [0.7.4ubuntu7
-> 0.7.5ubuntu2~ppa1]
  update-manager [1:0.87.27 -> 1:0.91.6] update-manager-core [1:0.87.27 ->
1:0.91.6]
  update-notifier [0.70.7 -> 0.70.8~ppa1] update-notifier-common [0.70.7 ->
0.70.8~ppa1]

Thanks Michael.

This is fixed in intrepid now.

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Every messages is related with someproblem with my SO?can you answer me in spanish please. Thanks

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/

I am not directly affected by this problem but I saw the blog from Jordan Mantha - SRU needs your help.
So I thought, why don't give it a try.

But I don't understand the test case.
with the boot option mem=128M gnome isn't even starting correctly.
Maybe someone can give me a hint so that I can help test the proposed update.

Regards
Achim

On Sat, 2008-08-09 at 11:40 +0000, Achim wrote:
> I am not directly affected by this problem but I saw the blog from Jordan Mantha - SRU needs your help.
> So I thought, why don't give it a try.
>
> But I don't understand the test case.
> with the boot option mem=128M gnome isn't even starting correctly.
> Maybe someone can give me a hint so that I can help test the proposed update.

Either pull extra RAM out of the machine, or use a VM. The mem= option
is not all it's cracked up to be.

> Either pull extra RAM out of the machine, or use a VM. The mem= option
> is not all it's cracked up to be.

Sorry I can not help. Even if I pull out some MB of RAM the minimum that I can get are 1 GB so that wouldn't help I think.
I have installed an Virtual Machine and set the ram setting to 128 MB and nothing happened. (no updates were installed)

Maybe I don't get this problem right.

Sorry for wasting your time.

Regards
Achim

@Achim: with mem=128M you can still log into the failsafe gnome session, it does not go to the full desktop :) Any value of mem in between should also work (like mem=256M). It is just used to create artificial slowdown so that starting of sudo gets slow.

BTW:
I got a user reporting that the hang is fixed for him with the new version of libgksu here:
https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/253439/comments/9

Am Donnerstag, den 14.08.2008, 10:09 +0000 schrieb Michael Vogt:
> @Achim: with mem=128M you can still log into the failsafe gnome session,
> it does not go to the full desktop :) Any value of mem in between should
> also work (like mem=256M). It is just used to create artificial slowdown
> so that starting of sudo gets slow.

Okay, so I think I don't know how to run gnome in failsafe mode.
Can you give me a hint.

Regards
Achim

Achim: try mem=190M, I know that that much memory was demonstrating the problem for me and also that it boots up into gnome, albiet slowly.

I tried to load the packages from -proposed when they were announced but it didn't want to work. As far as I could tell it was because they were not in the archive at that time, however it could also be because I had the packages from Michael's development repository.

I will try again when the opportunity arises.

I was able to reproduce the problem with the version of libgksu2-0 in the 8.04 release with mem=128M. I can confirm that the version of libgksu2-0 in hardy-proposed, 2.0.5-1ubuntu5.2, does appear to solve the issue here with the same kernel command line setting. I also noticed no slowdown when using the updated gksu for other tasks within the system.

Copied to hardy-updates.