| Walt Mankowski on Wed, 26 Feb 2003 23:40:29 -0500 |
|
On Wed, Feb 26, 2003 at 10:38:51PM -0500, gabriel rosenkoetter wrote: > Every time a key is added to my public keyring, GnuPG forces a > trustdb check. Is anyone else experiencing this aberrant behavior? Yeah, it's annoying. I find that running gpg --rebuild-keydb-caches periodically helps a bit, but only very briefly. > Using --no-auto-check-trustdb makes reading mail with mutt practical > again. I just finally got around to setting that the other day, after getting fed up with the long delays every time I add a new key. > There is no sane explanation for needing to do a trustdb check with > every imported key. If that were going to be necessary, then it > shouldn't ever have been modularized out. It's particularly annoying when you import a key that's only been self-signed, but gpg *STILL* spends over a minute rechecking the entire trust db. A month or so ago I saw something on the gpg-users list that someone had added a patch to the development version to prevent that behavior. > For reference, here's what a --check-trustdb looks like for me these > days: > > uriel:~% time gpg --check-trustdb > gpg: checking at depth 0 signed=46 ot(-/q/n/m/f/u)=0/0/0/0/0/1 > gpg: checking at depth 1 signed=84 ot(-/q/n/m/f/u)=0/0/0/17/29/0 > gpg: checking at depth 2 signed=288 ot(-/q/n/m/f/u)=0/0/0/72/7/0 > gpg: checking at depth 3 signed=181 ot(-/q/n/m/f/u)=0/74/0/22/1/0 > gpg: checking at depth 4 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/1/0 > gpg: next trustdb check due at 2003-03-07 > gpg --check-trustdb 109.24s user 20.77s system 80% cpu 2:40.70 total Wow, I'm only going to depth 2. I wonder what the difference is. > This is on a PowerPC G3 (a 750, running, I believe, at 300 MHz, > but it's been a long time since I thought about it and NetBSD/macppc > doesn't report cycle speed in dmesg(8)) with 288 MBs (says dmesg(8); > I don't recall exactly what DIMMs I've got in there) of memory. > The disk isn't the fastest around, but this process is clearly > (based on zsh's time builtin's output and also observation of top(1) > while the thing is running) cpu-bound, so that doesn't matter > here. I'm using: Yes, it's also my impression that this is a cpu-bound process, too. I really don't understand what it could possibly be doing that it could suck up the cpu of a modern machine for over a minute. You'd think this would be a fairly simple tree traversal algorithm we all learned back in our computer science classes. Walt Attachment:
pgpUQNeFyUvG2.pgp
|
|