The attached patch removes the --supervised option from the example dirmng and gpg-agent systemd unit files.

This issue was reported to the Fedora devel list today. A related Fedora https://bugzilla.redhat.com/2158627 was also created.

Actually, the entire systemd based launching is deprecated and thus the logged warning is on purpose.

The problem with the systemd launched gpg-agent is that it creates a race: gpg launches gpg-agent as needed and to avoid concurrent launching by other gpg or gpgsm processes, it takes a file system lock during the launch process. systemd does not know about this and we end up with sometimes end up with two gpg-agent processes. Eventually one of those processes detects that it does not own the socket and terminates itself. No real harm here but you may see smart card lockups or a flushed password cache.

Thanks for the context Werner. This was missing from the commit which added the deprecation warning so all one could do is guess.

If this is the case, a prominent notice in doc/examples/systemd-user/README (and possibly within the unit files as well) would probably be warranted?

The current warning doesn't directly suggest that the solution is to not use the systemd-user units at all. I'm not sure of the best way that it could, or I would try to put that in patch form.

In T6336#166815, @werner wrote:

Actually, the entire systemd based launching is deprecated and thus the logged warning is on purpose.

The problem with the systemd launched gpg-agent is that it creates a race: gpg launches gpg-agent as needed and to avoid concurrent launching by other gpg or gpgsm processes, it takes a file system lock during the launch process. systemd does not know about this and we end up with sometimes end up with two gpg-agent processes. Eventually one of those processes detects that it does not own the socket and terminates itself. No real harm here but you may see smart card lockups or a flushed password cache.

I think it shouldn't be a problem, systemd socket activation will place a socket file on where gpg-agent placed. So gpg will found a socket and use it without launching new one. Then systemd pass fd to new gpg-agent so all message should be proccessed correctly.
For conflicts with other autolaaunching, systemd place socket so early that it's impossible that other autolaunching way will launch gpg-agent at same time. (Actually, when user login, only thing that will start earlier than systemd socket activation is PAM.)

The only way leading to a conflict is gpg doesn't recognize socket but file lock, but I think it's not a good practice. Unix domain socket will be removed automatically when all users close it. A file lock to determine whether agent is alive is unnecessary.