Hello!
When I want to encrypt and sign a message on the command line, I get an error message:
“can’t connect to ‘socket:///home/user/.gnupg/log-socket’: Connection refused” - How can I solve the problem without lowering security?
I’ve done a lot of research but there are no solutions, apart from old versions of Gnupg.
This is a real problem and I’ll give it to you straight.
I have the impression that nobody has a solution.
For information, I use ArchLinux.
Thanks!
Hi @alexandre0123
this problem seems to be ArchLinux specific.
Here is the page GnuPG - ArchWiki that has a number of hints how ArchLinux’s default configuration looks like.
That message
“can’t connect to ‘socket:///home/user/.gnupg/log-socket’: Connection refused”
relates to logging actions which is optional, so you can turn it off.
Set --log-file to a real file that gpg can write and only you can read in your call on the command line. And add an -v to see a little more details.
You may need to check if other components have this option in their configuration file, if changing the call to gpg is not enough. See the different log-file options in Option Index (Using the GNU Privacy Guard)
Best,
Bernhard
I had the same problem, found a solution here:
https://bbs.archlinux.org/viewtopic.php?id=296399
So I edited gpg.conf and gpg-agent.conf and changed the logfile from a socket to a local file:
log-file /home/lpc123/.gnupg/gpg.log
Hello, thanks you for answers @bernhard and @stokito
When I change the location of the socket to a folder that has read and write permission, I still get the same error message, except that the error message with the new socket path.
I tried to do what you told me but I still have the same problem, socket file is a hell for gnupg.
Finally, I deleted the .gnupg folders in /root and in the home file.
Then I run the following commands:
I added lines concerning the servers to receive the public keys in dirmngr.conf and I deactivated the line concerning the file linked to the socket.
There is no problem, but until when ?
To avoid losing public and private keys, I use kleopatra.
So I used kleopatra via AppImage, because kleopatra does not launch on ArchLinux and I want to avoid using Xorg at all costs, only Wayland.
I can save the public keys in a single block but also to save the private keys which are saved in an encrypted container via cryptsetup.
Indeed, I am sure that the socket problem will reappear and I do not understand the problem with the socket.
so if the problem reoccurs, I will use this method.
Thanks you !
No, I see the same problem on openSUSE Tumbleweed. Both are rolling releases - may that be the issue?
There is no problem, but until when ?
Until you again do not have a server running which is listening at that socket…
Your error message “can’t connect to ‘socket:///home/user/.gnupg/log-socket’: Connection refused” is typical for this. Gpg can not connect to a socket where no one is listening.
And when you define a socket for logging in one of your .conf files, this will happen sooner or later.
So my advice is to use a log file as @stokito suggested, which will always work as long as the file is writeable. Alternatively only enable a log socket for a debug session where you are more likely to remember to start your log server (e.g. watchgnupg), too.
By the way: if you use Kleopatra instead of the command line to encrypt something, you won’t see any error message at all in the case your log server is not running. You will sit there wondering why Kleopatra doesn’t start as expected until you remember that you had enabled logging via socket the day before but didn’t start watchgnupg yet… As happens to me once in a while 
Hi @docB!
It’s not an issue of rolling releases. I assume you configured the log socket yourselves, in that case its a misconfiguration by the user. It could theoretically be a misconfiguration in the global config files by the maintainers of these distributions, too, but I guess then we would get more questions regarding this.
Hello Bernhard,
It’s not an issue of rolling releases.
Sure - rolling releases usually have the latest version of gnuPG available, so if it is a regression we will see it first.
I assume you configured the log socket yourselves, in that case its a misconfiguration by the user. It could theoretically be a misconfiguration in the global config files by the maintainers of these distributions, too, but I guess then we would get more questions regarding this.
I have not touched this at all, but opened a bug: 1226912 – gnupg problem with socket connection
Ok, after consulting with a colleague this might be an issue with kwatchgnupg. Which is the tool started when you click on Tools → “GnuPG Log Viewer” in Kleopatra. (But it can be started on the command line, too.)
This then writes the line log-file socket:///home/user/.gnupg/log-socket in all existing .conf files in you GNUPGHOME apparently and does not delete them again when logging is stopped.
Did you start kwatchgnupg in the past? Maybe unintentionally
This is usually only annoying, as the message is only a message warning you that no log can be written to the socket and logging will then fall back to STDOUT.
But if you have kwatchgnupg or watchgnupg running, you will get all dignostic output there and not in your terminal. Which is very confusing. But gpg should do the operation anyway, e.g. encryption. But in your case is was a verification and that result will only appear in the log viewer. Do you have one running? Can you confirm you see the output there?
In any case when you delete all the log-file lines in your configuration files in GNUPGHOME which point to a socket you will see the output again on the command line.
Kwatchgnupg has not changed in some years AFAIK, so I’m not sure if something else has triggered some change in the behavior. Can you point to a specific update after which this started to happen?
Anyway, we will think about how to improve that irritating behavior of Kwatchgnupg in the future.
I just checked with ps, I have no such process running
As witten, no such log viewer. I would not mind about the missing log, but gnupg does not perform the verification, and stops with this error.
Not really, as I dont use gnupg on the command line that often, but had to deal with a failing tarball signature, when I detected the issue.
Deleting the lines from the config files helped, thank you!
In all likelihood it does, but the verification result is send to the log file / socket.
Seems the fallback to stdout does not work for you then, strange.
Your welcome!
Hi,
somehow I was of the understanding after looking at the ArchLinux Wiki files that they may do something special with sockets. Good that you did more analysis that a kwatchgnupg run may have added that configuration. Haven’t seen this before either.
Hello,
The problem seems to have been solved in my case.
The problem has been solved by updating GnuPG and libgcrypt ( Archlinux gnome)
So I can check file signatures without error messages.
logs:
[2024-06-28T22:02:20+0000] [ALPM] upgraded gnupg (2.4.4-1 → 2.4.5-1)
[2024-06-28T19:59:18+0000] [ALPM] upgraded libgcrypt (1.11.0-1 → 1.11.0-2)
@DocB:
I did a test under Opensuse Tumbleweed with virt-manager and I did not see any problems with gnupg.
It seems that rolling release distributions also have problems, which is normal.
There is also a problem with kleopatra, but there is an Appimage that you can download from the following link:
This sounds amazing as I found it very much useful and informative to be honest. Also, I have gone through this post which definitely helped me out a lot as a new member I am looking forward for more such discussions.