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.
