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)
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.
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
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.
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.
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.
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.
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.
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.