/usr/lib/systemd/user/gpg-agent.service (for >=app-crypt/gnupg-2.1.0) [Unit] Description=GPG Agent Service IgnoreOnIsolate=true Before=default.target [Service] Type=forking ExecStart=/usr/bin/gpg-agent --daemon [Install] WantedBy=default.target Reproducible: Always
Is it needed to run it in "--daemon" mode (and hence "Type=forking") or could it be run in foreground?
No doubt that it could run either way as far as service management is concerned, but I'm not sure if gpg-agent itself might behave differently when not in daemon mode. It might be more chatty when not in daemon mode, but as long as it doesn't expect something from STDIN it probably doesn't matter.
I prefer to have --daemon and forking mode since it allows systemd to detect startup failures.
> IgnoreOnIsolate=true Why do you have this? > Before=default.target This also seems unnecessary.
This is entirely a copy paste from https://github.com/alezost/systemd-user-units/blob/master/gpg-agent.service I figured that would be a good starting point. Those directives don't make much sense to me either, but I assumed there was reasoning of some sort behind it. I'm not familiar enough with the internals of gpg to determine why those options are, or at one time were needed.
And just to be clear, that service file with the same directives is found in Arch, Ubuntu, and several other git repos. But nothing with a git commit log that actually explains why those directives are needed.
This seems related and possibly a duplicate of bug 562782
(In reply to Kristian Fiskerstrand from comment #7) > This seems related and possibly a duplicate of bug 562782 As pointed out in bug 562782, gnupg 2.1 auto-launch gpg-agent and other daemons as needed. The only place this would need to be explicitly launched is to enable ssh support, and the supported upstream way of launching it is gpgconf --launch gpg-agent
(In reply to Kristian Fiskerstrand from comment #8) > (In reply to Kristian Fiskerstrand from comment #7) > > This seems related and possibly a duplicate of bug 562782 > > As pointed out in bug 562782, gnupg 2.1 auto-launch gpg-agent and other > daemons as needed. The only place this would need to be explicitly launched > is to enable ssh support, and the supported upstream way of launching it is > gpgconf --launch gpg-agent ... and just so that it is explicitly clear; this is to be done in the context of a user, not as a system service
(In reply to Kristian Fiskerstrand from comment #8) > (In reply to Kristian Fiskerstrand from comment #7) > > This seems related and possibly a duplicate of bug 562782 > > As pointed out in bug 562782, gnupg 2.1 auto-launch gpg-agent and other > daemons as needed. The only place this would need to be explicitly launched > is to enable ssh support, and the supported upstream way of launching it is > gpgconf --launch gpg-agent The only reason I'm using this is for clients that were designed before 2.1 came out. In my case for kgpg and kleopatra on KDE desktops. It may be that setting GPG_AGENT_INFO is enough as long as there is something listening to the socket. (#562782). But I'm not certain if there is something always on the other end of the socket. > ... and just so that it is explicitly clear; this is to be done in the > context of a user, not as a system service This is a session service, not a system service
Gave this a shot on the latest Gentoo LiveDVD image running in a VM. I wasn't able to gain access to the yubikey with pcsc_tools, but I don't believe that is relevant to gnupg continuing to provide the same output. The scdaemon would access it (and fail), but gnupg can't access the scdaemon. https://bpaste.net/show/1709d6c87ff0
Please ignore my comment, wrong bug. Sorry.
I wonder if we can make it work with ssh agent support enabled in gpg.
(In reply to Michał Górny from comment #13) > I wonder if we can make it work with ssh agent support enabled in gpg. You might get some hints from bug 547544 comment 4
Current versions of gnupg ship with systemd units provided by upstream.