Bug#833596: [pkg-gnupg-maint] Bug#833596: systemd user service {gpg-agent, dirmngr} breaks GNOME session startup

2016-08-17 Thread Stefano Zacchiroli 
On Wed, Aug 10, 2016 at 11:46:55AM -0400, Daniel Kahn Gillmor wrote:
> That's the exact same stack i used for my test, and i didn't see the
> error.  so yeah, i'd like to try to track it down.

So I've tried again. I've good and bad news.

Good news: I can no longer reproduce the session startup failure. GNOME
starts just fine, and this is how the two services in question look:

---
  $ systemctl status --user dirmngr.service
  ● dirmngr.service - GnuPG network certificate management daemon
 Loaded: loaded (/usr/lib/systemd/user/dirmngr.service; enabled; vendor 
preset: enabled)
Active: active (running) since mer 2016-08-17 09:09:06 CEST; 5min ago
 Docs: man:dirmngr(8)
 Process: 21506 ExecStart=/usr/bin/dirmngr --daemon --homedir 
%h/.gnupg (code=exited, status=0/SUCCESS)
  Main PID: 21509 (dirmngr)
 CGroup: 
/user.slice/user-1000.slice/user@1000.service/dirmngr.service
└─21509 /usr/bin/dirmngr --daemon --homedir 
/home/zack/.gnupg

  ago 17 09:09:06 timira systemd[21502]: Starting GnuPG network certificate 
management daemon...
  ago 17 09:09:06 timira dirmngr[21506]: dirmngr[21506.0]: WARNING: 
***
  ago 17 09:09:06 timira systemd[21502]: Started GnuPG network certificate 
management daemon.

  $ systemctl status --user gpg-agent.service
  ● gpg-agent.service - GnuPG secret key agent and passphrase cache
 Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; enabled; vendor 
preset: enabled)
Active: active (running) since mer 2016-08-17 09:09:06 CEST; 5min ago
 Docs: man:gpg-agent(1)
 Process: 21507 ExecStart=/usr/bin/gpg-agent --daemon --homedir 
%h/.gnupg (code=exited, status=0/SUCCESS)
  Main PID: 21508 (gpg-agent)
 CGroup: 
/user.slice/user-1000.slice/user@1000.service/gpg-agent.service
└─21508 /usr/bin/gpg-agent --daemon --homedir 
/home/zack/.gnupg

  ago 17 09:09:06 timira systemd[21502]: Starting GnuPG secret key agent and 
passphrase cache...
  ago 17 09:09:06 timira systemd[21502]: Started GnuPG secret key agent and 
passphrase cache.
---

Bad news: I checked where the services belong in the service tree (as
you suggested on debian-devel [1]) and they are still not part of the
session scope:

---
  └─user.slice
└─user-1000.slice
  ├─user@1000.service
  │ ├─gpg-agent.service
  │ │ └─21508 /usr/bin/gpg-agent --daemon --homedir /home/zack/.gnupg
  │ ├─dirmngr.service
  │ │ └─21509 /usr/bin/dirmngr --daemon --homedir /home/zack/.gnupg
  │ └─init.scope
  │   ├─21502 /lib/systemd/systemd --user
  │   └─21503 (sd-pam) 
  └─session-1209.scope
---

[1]: https://lists.debian.org/debian-devel/2016/08/msg00085.html

FWIW I've checked and there are no other dirmngr or gpg-agent services
running in the whole tree.

Is this the expected behavior? In your test where did the two services
ended up being located in the service tree?

Hope this helps,
Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#833596: [pkg-gnupg-maint] Bug#833596: systemd user service {gpg-agent, dirmngr} breaks GNOME session startup

2016-08-10 Thread Daniel Kahn Gillmor 
On https://bugs.debian.org/833596 :

On Wed 2016-08-10 04:27:21 -0400, Stefano Zacchiroli wrote:
> On Wed, Aug 10, 2016 at 12:12:27AM -0400, Daniel Kahn Gillmor wrote:
>> So i'm not able to reproduce this behavior.
>> 
>> Zack, can you help me narrow down how this is happening for you?
>
> Sure, I'll be happy to. But as I mentioned before I wonder if it's worth
> to do it with my current package mix: I'm using testing, where the GNOME
> stack seems to be still in flux, apparently), with gnupg2 coming from
> experimental. I can debug, but I wonder if it'd be a good time
> investment.

That's the exact same stack i used for my test, and i didn't see the
error.  so yeah, i'd like to try to track it down.

> Unless you consider this issue potentially blocking for uploading to
> unstable, I'd rather wait for gnupg2 to land in testing and try again.
> After all the issue is for a non-default behavior that one should
> explicitly enabled, right?

I'm willing to upload to unstable with this bug still open  -- but the
software will still be the same software ;)

>> do you have logs of the failed login session someplace, or other details
>> that might help diagnose?
>
> I can look up logs, but I could use some guidance about where the GNOME
> user session logs are supposed to be. ~/.xsession-errors seems to be
> obsolete --- or else it hasn't received log entries on my laptop since
> March 2016, which seems unlikely...

Hm, maybe "journalctl --user" ?  i'm cc'ing pkg-gnome-maintainers to see
whether they have any suggestions for better debugging techniques.

Thanks for following up,

--dkg


signature.asc
Description: PGP signature

Bug#833596: [pkg-gnupg-maint] Bug#833596: systemd user service {gpg-agent, dirmngr} breaks GNOME session startup

2016-08-10 Thread Stefano Zacchiroli 
On Wed, Aug 10, 2016 at 12:12:27AM -0400, Daniel Kahn Gillmor wrote:
> So i'm not able to reproduce this behavior.
> 
> Zack, can you help me narrow down how this is happening for you?

Sure, I'll be happy to. But as I mentioned before I wonder if it's worth
to do it with my current package mix: I'm using testing, where the GNOME
stack seems to be still in flux, apparently), with gnupg2 coming from
experimental. I can debug, but I wonder if it'd be a good time
investment.

Unless you consider this issue potentially blocking for uploading to
unstable, I'd rather wait for gnupg2 to land in testing and try again.
After all the issue is for a non-default behavior that one should
explicitly enabled, right?

OTOH if you do consider this a blocker, I'll roll up my sleeves and have
a look ASAP :-)

> do you have logs of the failed login session someplace, or other details
> that might help diagnose?

I can look up logs, but I could use some guidance about where the GNOME
user session logs are supposed to be. ~/.xsession-errors seems to be
obsolete --- or else it hasn't received log entries on my laptop since
March 2016, which seems unlikely...

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#833596: [pkg-gnupg-maint] Bug#833596: systemd user service {gpg-agent, dirmngr} breaks GNOME session startup

2016-08-09 Thread Daniel Kahn Gillmor 
Control: tags 833596 + moreinfo unreproducible

Hi Zack--

On Sat 2016-08-06 13:58:18 -0400, Stefano Zacchiroli wrote:
>> > On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
>> >> On desktop systems (where i'd expect the majority of secret key access
>> >> happens), for folks who are running systemd, i recommend enabling the
>> >> systemd user services, as documented in
>> >> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
>> >> 
>> >>   systemctl --user enable gpg-agent
>> >>   systemctl --user enable dirmngr
>
> OTOH, doing this inhibited a proper start of my GNOME session at next
> login: only Nautilus started (I can tell because I've it handle my
> desktop icons) and I could use it to browse the filesystem, but GNOME
> Shell didn't see to be running.  Reverting the above with "disable" [*]
> fixed the issue, and at next login GNOME session started properly,
> including GNOME Shell.
>
> [...] my package mix is kinda unusual at present: Debian testing +
> hand-picked gpg from experimental.

i've now tried to replicate this and failed :(

My replication steps were:

 * new, fairly minimal debian testing installation (kvm guest, using
   -graphics sdl)

 * apt install gnome-core xserver-xorg xserver-xorg-video-qxl 

 * apt install -t experimental gnupg dirmngr gnupg-l10n

 * reboot for clean machine state and see that the gdm login screen
   appears automatically

 * graphical login as a non-privileged user

 * open Gnome Terminal

 * systemctl --user enable dirmngr
   systemctl --user enable gpg-agent

 * log out

 * wait a minute or two for user-1000.slice to complete (it appears that
   i'm waiting for "/usr/bin/pulseaudio --start --log-target=syslog" to 
terminate)

 * log back in

 * reboot

 * log in


all of the above worked without a problem :/

Then i tried to get tricky to see if i could force the issue:

 * log in

 * systemctl --user stop gpg-agent

 * gpgconf --launch gpg-agent

 * log out

 * observe that the session does not terminate because gpg-agent is
   holding it open (even after pulse quits)

 * log in


and it all still works fine.

So i'm not able to reproduce this behavior.

Zack, can you help me narrow down how this is happening for you?

do you have logs of the failed login session someplace, or other details
that might help diagnose?

   --dkg


signature.asc
Description: PGP signature

Bug#833596: systemd user service {gpg-agent,dirmngr} breaks GNOME session startup

2016-08-06 Thread Stefano Zacchiroli 
Package: gnupg
Version: 2.1.14-3

Forwarding from debian-devel
https://lists.debian.org/debian-devel/2016/08/msg00093.html , as
requested by dkg.

- Forwarded message from Stefano Zacchiroli  -

Date: Sat, 6 Aug 2016 12:32:39 +0200
From: Stefano Zacchiroli 
To: debian-de...@lists.debian.org
Subject: Re: [pkg-gnupg-maint] Beware of leftover gpg-agent processes
Message-ID: <20160806103239.ga12...@upsilon.cc>
Resent-From: debian-de...@lists.debian.org

[ quoted text reordered ]

On Fri, Aug 05, 2016 at 02:43:30PM -0400, Daniel Kahn Gillmor wrote:
> The simplest way to see the control group hierarchy is with "systemctl
> status".  When these processes are launched by the user service, they'll
> end up in the user@.service like this:
[...]
> If they've been autolaunched, they'll end up in the sesion-X.scope
> sub-tree.

It was indeed the case for me: they had been auto-launched.

> > On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> >> On desktop systems (where i'd expect the majority of secret key access
> >> happens), for folks who are running systemd, i recommend enabling the
> >> systemd user services, as documented in
> >> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
> >> 
> >>   systemctl --user enable gpg-agent
> >>   systemctl --user enable dirmngr

OTOH, doing this inhibited a proper start of my GNOME session at next
login: only Nautilus started (I can tell because I've it handle my
desktop icons) and I could use it to browse the filesystem, but GNOME
Shell didn't see to be running.  Reverting the above with "disable" [*]
fixed the issue, and at next login GNOME session started properly,
including GNOME Shell.

I haven't yet filed this as a bug report, because my package mix is
kinda unusual at present: Debian testing + hand-picked gpg from
experimental. But it might be useful for you to know about this. Let me
know how I can debug it further and/or if you'd like to move this
discussion into a dedicated bug report (and when).

Cheers.

[*] actually, I manually removed the symlinks from
.config/systemd/user/default.target.wants/, but AFAICT the effect is
the same
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »