gpg-agent timer tick

[Alan Jenkins]

Werner Koch wrote:
> On Fri, 11 Jan 2008 18:09, alan-jenkins at tuffmail.co.uk said:
>
>   
>> This is potentially a Bad Thing for CPU power consumption, because it
>> reduces the amount of time the CPU can spend in deep sleep states.  I
>>     
>
> I thought that 2 seconds are long enough but tehre is no reason why we
> can't have a config option for this.
Having the CPU wake up every 2 seconds still isn't ideal.

It may not seem that much of an issue on its own, but the problem is 
that there are many programs which do the same.  Say you have four 
programs that do exactly the same thing.  Then the CPU is potentially 
waking up every half a second, which is not so good.

It's possible to co-ordinate timeouts between programs, as with using 
glib's g_timeout_add_seconds(), which limits such wakeups to one a 
second no matter how many programs use it.  Redhat have hacked several 
programs they distribute to round their wakeups to the nearest second 
and perhaps gpg-agent could do the same.

It's also a pity to add another config option unless it's really necessary.

Ultimately, a number of people are hoping to eliminate these sorts of 
timer ticks altogether.  I'm just seeing whether I can shift some of the 
simpler cases that cross my path.  I don't know if there's anything I 
can say to inspire you, but it's one of the things the "$100-dollar 
laptop" (http://laptop.org/) project had to look at.  If you look on 
Redhat Bugzilla it might give you an idea of the amount of work that is 
going into this issue generally: 
<https://bugzilla.redhat.com/showdependencytree.cgi?id=204948>.
>  
>   
>> my patch.  Let me know if you're interested here and I'll submit a
>>     
>
> FSF copyright assignment is required, so it might be easier if we do it.
>
>   
>> In that case it runs the command given.  The tick handler is used to
>> check, every two seconds, whether the command is still running; if
>> not, gpg-agent quits.
>>     
>
> 10 seconds or even longer should not pose a problem.
>
>   
>> A better way to do this is to run the command as a child of gpg-agent,
>> and rely on the SIGCHLD signal instead of a timer tick.
>>     
>
> The problem with this approach is that any bug in gpg-agent causes the
> entire child hierarchy to die.  Yes there should be no bug in gpg-agent
> but in some cases (e.g. resource problems) it just prefers to exit.  It
> is really annoying to see your desktop vanishing along with all the
> unsaved data.
>   
Yes, that sure would be annoying.  That's not quite what happens 
though.  Child processes aren't automatically killed when their parent 
terminates.  The reason that seems to happen with shells is that the 
shell is a "session leader"; it starts commands in the same "session", 
and when the "session leader" dies all the other processes in the 
session get sent SIGHUP.  (Something like that.  I'm not familiar with 
this but I've read up on it).

When gpg-agent "daemonizes" by calling setsid(), it starts a new session 
containing only itself.  Since it does this after running the command, 
the command will carry on running even if gpg-agent dies.  So I think 
you're technically wrong.

*However*, depending on how gpg-agent is used, there could still be a 
similar effect.  For example, if the last command in a .Xsession file was:

gpg-agent startkde

I think when gpg-agent terminates, the login manager would assume you've 
logged out and your session is over.  So I agree what I described was 
probably a bad idea.

That's still fixable though.  I've attached an example which uses a more 
complex method and avoids the problem.  The command being run (e.g. the 
session) has a simple parent process that waits for its death, and a 
child process that runs the daemon.  The parent notifies the daemon when 
the child command dies, by writing to a pipe.
>   
>> The timer tick is also used to check the Scdaemon (whatever that is
>> :-)
>> is still running.  However, since it use waitpid() to check this,
>> Scdaemon must already be being run a child, so that shouldn't be a
>>     
>
> Scdaemon handles smartcards.
>
> We could indeed change this to use SIGCHLD but given that we need a
> ticker anyway I don't think that makes much sense.  Note that a future
> version will use the ticker to do housekeeping for the saved
> passphrases.
>   
I did wonder about the generic name (handle_tick()).  You don't need a 
ticker though; you can can use a timer.  You don't need to say "wake me 
up every 10 seconds so I can see if I need to do anything"; you can say 
"the users passphrase is going to expire in half an hour; wake me up at 
that point".  If you have multiple timers or timers that need cancelling 
or readjusting, it may end up slightly easier / clearer if you use the 
timers in libpth.
> Would a option to set the timer tick help you?
>   
I have to admit non of this would directly benefit me - I only use 
gpg-agent on a desktop.  The option might help if I was using it on a 
laptop.  A realistic figure for a functional laptop is 10 wake-ups per 
second, so it can be worth looking at a program doing 0.5 wakeup/s.

Many thanks!  (I think you deserve them if you read this entire email).

Alan