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

[Daniel Kahn Gillmor]

On Mon 2017-02-06 11:32:06 -0500, Yuri D'Elia wrote:
> 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 "$@"

sure, but what's the "$@" ?  Is it guaranteed to be a simple file name?
or could it be more gpg options?

You're saying that this command itself launches the agent, but i'm not
seeing that locally:

0 test at alice:~$ systemctl --user status
● alice
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Mon 2017-02-06 14:55:38 EST; 5min ago
   CGroup: /user.slice/user-1003.slice/user at 1003.service
           └─init.scope
             ├─8163 /lib/systemd/systemd --user
             └─8164 (sd-pam)
0 test at alice:~$ gpg --batch -qe -r 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 test.txt
0 test at alice:~$ systemctl --user status
● alice
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Mon 2017-02-06 14:55:38 EST; 5min ago
   CGroup: /user.slice/user-1003.slice/user at 1003.service
           └─init.scope
             ├─8163 /lib/systemd/systemd --user
             └─8164 (sd-pam)
0 test at alice:~$ 

So i'm still unable to reproduce this :/

> 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)

hm, that's interesting.  I wonder whether it makes sense for a package
upgrade that includes user services to tell all systemd-managed user
services to reload.  I could see that being useful, but i don't know how
to do it.

> 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.

so in that case, when the listening sockets are removed, does the
gpg-agent process itself also get terminated properly?  or does the
process continue to survive even with all sockets removed?  gpg-agent
should notice that removal and shut itself down.

>> 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.

Me too! i'm unable to replicate the launching of the processes on the
basis of public key encryption, and i'm unclear on why they aren't being
shut down by default at the end of the cron session when the sockets are
removed.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170206/6699fc86/attachment.sig>