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;
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:
O_NONBLOCK; this is just to avoid the prompt
{ /* no matter if we can read, since we're using
showing up after the read */
fd_set rfds;
struct timeval tv;
tv.tv_sec = 1;
tv.tv_usec = 0;
select (parent_pipe[0] + 1, &rfds, NULL, NULL, &tv);
}