Gpgconf error after install Pi-hole / gpgconf Fehler nach Pi-hole Installation

Hallo, ich habe heute pi hole installiert und ich habe ein Skript auf dem Pi am laufen das mir Fehler meldet. Nach der Installation erhalte ich nach jedem Neustart folgende Fehlermeldung:

systemd[2340]: gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error

Ohne Pi-hole-Installation tritt der Fehler nicht auf.

Mein Betriebssystem ist Rasbian Buster auf einem Pi4

Können ihr mir weiterhelfen?

Hello, I have pi hole installed today. I have a script on the run which reports errors. After the installation skript, I get this error after every restart:

systemd[2340]: gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error

Without Pi hole installation, the error does not occur. My OS is Rasbian Buster on a Pi4

Can you tell me where the problem is?

King Regards


wie hast du das festgestellt? Indem du Pi-hole wieder vom System entfernt hast?

War GPG bereits vor der Installation von Pi-hole auf dem System installiert und eingerichtet?

Ich habe gpg nicht installiert es war scheinbar standardmäßig im Raspbian Buster Image vorinstallierte. Wüsste auch garnicht ob man es nraucht und was es genau macht.

Rausgefunden habe ich es so:

Ich habe Pi-hole gestern installiert und hatte mich gewundert das nachdem heute Nacht ein automatischer Reboot vom Pi durchgeführt wurde das ich eine Push Nachricht von meinem Skript bekommen habe das im Log auf Fehler überwacht mit dem gpg Fehler. Habe dann zum testen ein paar neustarts gemacht wo der Fehler immer wieder direkt nach dem Start aufgetaucht ist.

Da ich es nicht direkt mit Pi-hole in Verbindung gebracht habe und ich mir nicht erklären konnte wieso der Fehler aufgetreten ist habe ich probiert den Fehler zu beheben mit Hilfe von Google. Konnte aber leider keinen richtigen Lösungsansatz finden.

Anschließend habe ich mein sauberes Backup wo noch kein Pi-hole installiert gewesen ist eingespielt. Hier ist der Fehler nicht aufgetreten auch nach mehrmaligen neustarten nicht.

Anschließend habe ich probiert auf dem sauberen Image Pi-hole erneut zu installieren da ich mir gedacht habe das es ggf. ein einmaliger Installationsfehler ist.

Aber direkt nach dem beenden des Pi-hole Installationsskript war der Fehler wieder vorhanden und ich habe erneut eine Meldung erhalten vom Log.

Bin jetzt erstmal ohne Pi-hole mit meinem sauberen Image wieder unterwegs.

Hast du vielen eine Idee wie man es beheben kann?

Vielen Dank im Voraus.

Gruß Nastra

Momentan keinen Plan, wo da ein Zusammenhang zwischen gpgconf und Pi-hole bestehen soll :thinking:

Schau ggf. mal, ob eines der folgenden Kommandos etwas brauchbares bringt (mit installiertem Pi-hole):

gpgconf -v --check-programs
gpgconf -v --check-config
gpgconf -v --list-dirs
gpgconf -v --list-config

Werde ich morgen mal machen und anschließend berichten. Dank dir erstmal.

Ich habe die Befehle gerade mal ausprobiert auf dem Image ohne Pi-hole zum vorher nachher vergleich.

sudo gpgconf -v --list-config
gpgconf: can not open global config file '/etc/gnupg/gpgconf.conf': Datei oder Verzeichnis nicht gefunden

gpgconf -v --check-configgpgconf: can not open global config file '/etc/gnupg/gpgconf.conf': Datei oder Verzeichnis nicht gefunden

Beide ohne Ergebnis.

Bei den anderen beiden ist der erste Eintrag von check-programs zumindest verdächtig auch ohne installierten Pi-hole obwohl der ursprünglichen Fehler im Log nicht auftaucht.

The problem is that GnuPG can't find its config folder (~/.gnupg). To fix this run

sudo mkdir -p /home/pihole/.gnupg
sudo chmod 700 /home/pihole/.gnupg
sudo chown -R pihole: /home/pihole

The real fix would be for pi-hole to specify --homedir and I'm kinda worried that this hasn't happed yet.

The pihole user should not have a homedir or a login.

Yeah, that's why I was suggesting --homedir.

I'm saying that pihole should NOT have a /home partition, nor should it even have a shell to be able to log in to. There should be no gpg associated with pihole user.

Sicher, dass der User pihole überhaupt involviert ist?

Auf meinem System wird die Meldung im Log dadurch provoziert, dass gnupg die notwendigen Rechte zum Anlegen von ./gnupg im Home-Verzeichnis von www-data (edit: /var/www) fehlen, also ein ganz anderer User, der außerdem ein Homeverzeichnis gesetzt hat.

Ich halte das daher für einen Seiteneffekt aus der Installation von gnupg.

Durch das Erstellen von /home/pihole/.gnupg konnte ich den "fatal error" beim Neustart vermeiden. Habe gerade in den Log geschaut und nun wieder einen gesichtet (um 06:25 Uhr). Scheint wohl ein Cron-Job o.ä. zu sein. Werde jetzt mal zusätzlich /var/www/.gnupg erstellen (hatte ich vorher schon probiert, hat das Problem beim Neustart aber nicht behoben) und morgen nochmal schauen.

Edit: Scheint weg zu sein - man braucht also beides.

Happy cake day! What would be the best solution going forward with this? I didn't setup any of this but it should ideally work out of the box.


I don't know what the best solution is because I don't know what the problem is or why you would even be prompted for gpg. There's no encryption involved with any Pi-hole process?

@mibere Can you help me understand how gpg comes in to play?

Have the same message on my system

gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error

but ignored it so far.

Just tried this and the error message is gone.

=> gpg-agent needs a configuration/data directory for every available user?

I'm not convinced it's a Pi-hole issue (if it even is an issue at all - I did not notice any negative effects, despite of the FATAL log message).

The more I investigate this, the more it would seem to me that GnuPG is assuming that every user on a system has to be using GnuPG and therefore it should be allowed to access its config options in their respective home dirs, disregarding the fact that some users would never need one.

I don't know whether that's a valid proposition for GnuPG, but I think that classifying the lack of a homedir or permission to access it is wrongly categorised as FATAL by gpgconf.

I've found a bug report at GnuPG that seems to point in the same direction, though that was prompted by actively using a gpgconf command:

Interestingly, that report has a link to

So this could also be specific to Debian's integration of GnuPG.

Although what you said makes sense, the error did go away after creating ~/.gnupg for pihole (startup) and www-data (6:25 am). The other users on my system don't have that directory (like e.g. the plex user), yet the error is gone. I think the best way to investigate this is to find what's happening at 6:25 am every day. I was looking through crontab/cron.d and systemd timers but couldn't find anything interesting. But I'm sure this is related to www-data/lighttpd, possibly Pi-hole as well.

Of course it would, but I disagree that this should be viewed as a correct solution.

Imagine only recently, you'd have plucked quite a few oversized letters sticking out from your mailbox that are neither addressed to you nor do you happen to know the sender.

Fortunately, your new neighbour drops by to pick up his letters.
But seeing they've been bent, buckled and folded, he complains about your mailbox being to small to fit his large letters!

You could either purchase and install a larger box, or tell the postman to stick letters in the right box, or have your neighbour provide his correct address in the future.

I would consider it wrong to buy a larger box, i.e. to create a .gnupg/ folder for a user that does not need one, just to get rid of an error message that should be a warning.
As far as I can tell, that message can be safely ignored, so creating that folder would serve no real purpose, apart from making your log file appear cleaner.

By all means , if creating that extra folder works for you, go ahead with it, but consider that a workaround rather than a solution.

I've had a closer look at the bug reports I posted above.

The problem is triggered by a systemd system-wide environment-generator for Debian's gpg-agent that gets called on user session creation (/usr/lib/systemd/user-environment-generators/90gpg-agent).

Betrusting most of the work to GnuPG's gpgconf, that script didn't test for home dirs, while gpgconf was treating inability to access a home dir always as FATAL.

It would seem that Debian as well as GnuPG have done their parts and addressed that problem.

As of 2.2.22, GnuPG's gpgconf will issue a warning:

I t could print a warning for a non-existant homedir

Should be fixed now for 2.2.22 and the forthcoming 2.3;

And Debian's 90gpg-agent script has been fixed as well:

That said, i agree that the spurious warnings don't seem relevant.
Rather, the environment generator shouldn't try to claim that gpg-agent
should be the active ssh-agent socket if it knows that gpg-agent is
somehow broken.

So i've wrapped the test in question in a "gpgconf --check-programs"
command instead.

Unfortunately, neither fixed version seems to be available for mainline Debian Buster, though at least a backport for gpg-agent exists.

Pulling only the 90gpg-agent script from the backport sources, I did a quick test and couldn't detect any gpgconf: running /usr/bin/gpg-agent failed messages upon restarting my system.
This is just a preliminary and very limited test, though.