Problem refreshing keys

Jerry jerry at
Wed Jun 13 00:23:40 CEST 2018

On Tue, 12 Jun 2018 16:42:25 -0400, Phil Pennock stated:

>On 2018-06-12 at 10:05 -0400, Jerry wrote:
>> Starting C:\Program Files (x86)\GnuPG\bin\gpg.exe --display-charset utf-8
>> --refresh-keys... gpg: refreshing 387 keys from
>> hkps:// gpg: keyserver refresh failed: Server
>> indicated a failure
>> This is happening on a Windows 10 PRO / amd64 machine. This has been
>> occurring for several days now. Is there something wrong with the server?  
>Seems likely, but there's not enough information there to track it down.
> is a collection of servers, run by
>different people, with management software tracking their status and
>updating DNS as needed.
>I've no idea how to use Kleopatra to ask for more debugging details to
>get the IP, sorry.
>You can see some of what's going on with:
>  gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye
>(if Windows doesn't like that quoting, then press enter after --dirmngr
>and then enter each of the next strings as a command at the prompt)
>Eg, I see:
>% gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye
>S # hosttable (idx, ipv6, ipv4, dead, name, time):
>S #   0
>S #   .
>S #   .   --> 4 9* 3 2 1 8 7 6 5
>S #   1   4
>S #   2   4 (
>S #   3   4 (
>S #   4   4 (
>S #   5   4 (
>S #   6   4 (
>S #   7   4 (
>S #   8   4 (
>S #   9   4
>( OK
>So the "." lines are because the previous item is a pool, so they
>provide more information, and AFAICT the "-->" line is "the order we'll
>try them in, with the currently active server marked with "*"; this
>shows me that the second item is active.  This makes sense, since the
>first retrieval took a long time, but the second was very quick: the
>first keyserver failed to give something sane back, so dirmngr fell over
>to the next item, which responded, and dirmngr has remembered that one
>as "good" so it will use it again in future.
>Given the failure you see, the "blind stabbing in the dark" approach
>would be to use:
>to mark the one with a "*" as "bad" and see what happens.  If that fixes
>it, then you know that the IP address which was "responding" and so
>selected was actually failing.  You can drop a note to
>sks-devel at with details if you manage to extract that much
>information from the tooling.
>-Phil, whose keyserver is in the pool and, coincidentally, is #9 above,
>       the one which worked and was selected.

This is what I am getting:

gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye
gpg-connect-agent: Note: '--hosttable'' is not considered an option
ERR 167772435 Unknown IPC command <Dirmngr>
ERR 167772435 Unknown IPC command <Dirmngr>


More information about the Gnupg-users mailing list