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
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.
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.
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.
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?
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: https://dev.gnupg.org/T4866
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.
