gpg-agent timer tick

[Alan Jenkins]

Werner Koch wrote:
> On Sat, 12 Jan 2008 00:14, alan-jenkins at tuffmail.co.uk said:
>
>   
>> 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.
>>     
>
> I understand.  I a conventionally programming environment it is usually
> the best to distribute CPU work most evenly over the time and thus
> making shure that not all timer fire exactly at the full seconds or so.
> Well for power saving this is different.  gpg-agent should do something
> about it.
>
>   
>> 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.
>>     
>
> Shall we change the timer code to do just that?  Run on the full even
> second?
>
>   
>> 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
>>     
>
> I know.  However I hve not thought that gpg-agent is really a candidate
> for it.  You convinced me.
>
>   
>> 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",
>>     
>
> I know.  However, the current code is pretty weel matured and I don't
> want to add new bugs right now.  In particular not if we need a timer
> anyway and if we the change to sync all timer events will be easier than
> changing this code.
>
>   
>> 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.
>>     
>
> I think that this code wouul be more complex than a timer tick to handle
> such things.
>
>   
>> Many thanks!  (I think you deserve them if you read this entire email).
>>     
>
> I assigned bug 871 to it.
>   
Thanks.  OK, I think I understand your points.

I think the best thing would be if the timer tick could be changed to 10 
seconds (by default).  It's a one line change; you said you thought it'd 
be OK, and its also what openssh-agent does.  I don't know of any 
difference between ssh-agent and gpg-agent that means the latter needs 
to wake up 5 times as often.

If you do that, I don't think it's worth rounding the timeouts to the 
nearest second.  It wouldn't really help; you can only save 0.1 wake-ups 
a second, and if you manage to do that it's probably because you're 
sharing wake-ups with something running at 1 wakeup a second.

---

I had another look at how gpg-agent was getting started on my system, 
and it turned out it's not even asked to run a command.  So what it's 
doing is waking up every two seconds and going "nope, I didn't run a 
command, so I don't need to check it's still running", and going back to 
sleep again :-).

So as used on my system, the timer tick could be disabled completely.  
That still leaves the problem of implementing passphrase expiry and 
other timeouts in future though.

I looked a bit harder at libpth and I can see that using timers would 
involve more code than a timer tick.  I do think using timers is the 
"right way to do it" though - no unnecessary wake-ups, no reason to 
limit precision.  I would argue that it wouldn't increase the internal 
complexity - it's more a matter of additional lines of code and 
additional exposure to potential "gotcha's" in libpth.  And in this case 
it's not a matter of ripping out mature code and rewriting it with added 
bugs.  You don't have any timeouts in there yet, so when you do add them 
it'll be new code either way.

---

For waiting for a command to finish, I am forced to concede that any 
technique I propose will lack the elegance of simplicity :-).  It was an 
interesting exercise though. 

In particular adding an extra process as a parent of the command causes 
problems in at least one case I can think of - gpg-agent goes into 
infinite loop, user runs "killall gpg-agent"; they end up killing the 
parent process because it has the same name, and they lose their session. 

I think the reason this is awkward is that gpg-agent is a console 
program which is used in an X11 world.  If gpg-agent was only run from 
console logins, it could preserve its controlling TTY and it'd be killed 
when the user logged out.  If it was an X11 program, it could run 
without a TTY and rely on X session management to tell it when the 
session ended.  I don't think that's going to happen though.

Hope this has been useful.

Alan