[pkg-gnupg-maint] Bug#853905: Bug#853905: Ships incorrect /usr/lib/systemd/user/sockets.target.wants files, makes disabling impossible

[Yuri D'Elia]

On Sat, Feb 04 2017, Daniel Kahn Gillmor wrote:
> Can you give me the exact invocation?  If the agent is being
> queried/auto-launched when it doesn't need to be, that'd be something
> worth asking GnuPG upstream to take a look at.

Nothing fancy. The command line is:

  gpg --batch -qe -r keyid "$@"

>> There's no secret key available for the recipient, but the agent is
>> somehow started, and actually gets stale.
>
> what does "stale" mean?

simply a running agent that became older than the current release of
gpg. from cron itself I also get:

gpg: WARNING: server 'gpg-agent' is older than us (2.1.17 < 2.1.18)

>> Now cron will actually create an user slice for root, meaning that
>> there's some extra interplay with cron that I'm trying to exclude.
>
> what implementation of cron are you using?  Are you using "systemd-cron"
> or the canonical "cron" package?

This is from regular "cron".
But I could test the behavior on another system where I'm using
systemd-cron as well.

> Why do you have lingering enabled if you don't want users running
> services?

I do absolutely want users being able to run services.

> For auto-launched gpg-agent processes (not systemd user services), i
> don't think lingering is the relevant configuration.  The relevant

In the specific cron case, I do see the listening sockets being created
(due to pam-systemd integration I guess) and removed at each job.

> I/O contention?  Or is it a single process that sleeps in the
> background, paged out until someone queries it?

These are all single processes just waiting.
So for gpg purposes, the agent is working as intended.
However, I'm perplexed as of why I have so many running.