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

[Daniel Kahn Gillmor]

On Sat 2017-02-04 09:06:12 -0500, Yuri D'Elia wrote:
> On Sat, Feb 04 2017, Daniel Kahn Gillmor wrote:
>> What are you doing with gpg?  if whatever you're doing needs the secret
>> keyring, the agent will be launched.  if it doesn't need the secret
>> keyring, the agent will not be launched.
>
> In one instance, I have a couple of gpg --batch processes that are run
> via cron to encrypt some files.

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.

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

what does "stale" mean?

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

>> With gpg-agent as a systemd user service, when the user completely logs
>> out of the system, any services launched (socket-activated or otherwise)
>> will be stopped automatically.
>
> Extra question, if this would be true for an user with lingering
> enabled? Because on servers we have those enabled for all users.

According to loginctl(1), users with lingering enabled do not have their
services terminated at logout, so a gpg-agent process running as a user
service for a user with lingering enabled shouldn't be terminated at
logout.

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

For auto-launched gpg-agent processes (not systemd user services), i
don't think lingering is the relevant configuration.  The relevant
configuration is logind.conf(5)'s KillUserProcesses (and KillOnlyUsers
and KillExcludeUsers) setting, which is (i think) orthogonal to the
question of user services.

Michael Beibl can probably shed more light on this.

>> Yuri, it sounds like you've got a particular scenario that you don't
>> like, and you're trying lots of things to change it, but i don't
>> understand what the scenario is.
>
> Not fully, no :/
>
> Bug debugging some of these runaway processes is tricky and time
> consuming.

when you say "runaway", are they consuming resources actively?  that is,
are there ongoing memory leaks, unnecessary CPU cycles consumed, disk
I/O contention?  Or is it a single process that sleeps in the
background, paged out until someone queries it?

Regards,

            --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/20170204/4f37591c/attachment.sig>