FS#54396 - [gnupg] installing sockets in /etc/systemd/user may break login sessions

Attached to Project: Arch Linux
Opened by Mark Kusch (groover) - Saturday, 10 June 2017, 09:23 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 29 August 2017, 22:13 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

Description: gnupg 2.1.21-2 pacman hook installs systemd socket in /etc/systemd/user. If a user has local services configured in ~/.config/systemd/user already, installation of these sockets breaks systemd login sessions.

This bug is reported to Archlinux and to gnupg package for a quick "fix" of the gnupg package and to have a reasonable discussion/review if this should get reported upstream to systemd. Further this is reported to generate awareness of this issue.


Additional info:
* gnupg 2.1.21-2


Steps to reproduce:
* Install service in ~/.config/systemd/user/multi-user.target.wants
* Have gnupg package hook install services/sockets in /etc/systemd/user
* reboot
* systemctl --user status -> broken (and many things more, like everything which has to do with login sessions)

* remove ~/.config/systemd/user
* reboot -> everything is fine

* remove /etc/systemd/user
* re-add ~/.config/systemd/user
* reboot -> everything is fine

* re-add /etc/systemd/user
* reboot
* login sessions broken again
This task depends upon

Closed by  Gaetan Bisson (vesath)
Tuesday, 29 August 2017, 22:13 GMT
Reason for closing:  Not a bug
Comment by Jan Alexander Steffens (heftig) - Saturday, 10 June 2017, 17:41 GMT
What kind of local services do you mean?
Comment by Mark Kusch (groover) - Saturday, 10 June 2017, 17:57 GMT
In my case (4 different systems with this issue) it were very different services. ~/.config/systemd/user/default.target.wants/mpd.service, gpg-agent.service, ... I read a lot of reports online that a particular service was the problem. In my (4) case(s) the issue with broken systemd login sessions was fixed only by removing either /etc/systemd/user or ~/.config/systemd/user from my system(s).
Comment by Jan Alexander Steffens (heftig) - Saturday, 10 June 2017, 18:02 GMT
Did you install any conflicting unit files for gpg-agent?
Comment by Mark Kusch (groover) - Saturday, 10 June 2017, 18:06 GMT
Yes, I did, at least on 3 out of 4 systems. Not sure right now about the 4th system. Cannot check until Monday.
Comment by Mark Kusch (groover) - Saturday, 10 June 2017, 18:12 GMT
Removing ~/.config/systemd/user/default.target.wants/gpg-agent.service symlink fixes the issue.
Comment by Stefano (masque) - Saturday, 10 June 2017, 20:25 GMT
Same for me. Removing gpg-agent.service in user's home fixed it.
Comment by Mark Kusch (groover) - Saturday, 10 June 2017, 20:41 GMT
Removing ~/.config/systemd/user/default.target.wants/gpg-agent.service symlink fixes the issue.
Comment by Mark Kusch (groover) - Saturday, 10 June 2017, 20:41 GMT
Removing ~/.config/systemd/user/default.target.wants/gpg-agent.service symlink fixes the issue.
Comment by Christian Rebischke (Shibumi) - Sunday, 11 June 2017, 14:23 GMT
For me it was a little bit more difficult. I had already a custom gpg-agent.service in /etc/systemd/user/gpg-agent.service therefore the gnupg update broke my whole `systemd --user`-daemon as the Bug-Reporter stated in his report.
Even when I unlinked the symlink in ~/.config/systemd/user/default.target.wants/gpg-agent.service I had the issue that `systemctl --user` doesn't work even after a reboot. I had to manually unlink all symlinks in /etc/systemd/user/sockets.target.wants and ~/.config/systemd/user/default.target.wants/ and then reboot. After it I had a full working `systemctl --user` again.
Comment by Jan Alexander Steffens (heftig) - Sunday, 11 June 2017, 15:19 GMT
If you have an overriding gpg-agent-service which does not support socket activation, you need to remove the unit file itself and not the symlinks that point to it.
Comment by Jan Alexander Steffens (heftig) - Sunday, 11 June 2017, 20:05 GMT
This is an issue with user-installed conflicting unit files. In addition, https://github.com/systemd/systemd/issues/4561 then causes the entire user manager to get killed instead of just gpg-agent failing to start.
Comment by Hawky (p90) - Monday, 12 June 2017, 11:02 GMT
Holy shit, just waisted a day of work trying to fix my system due to this.

While removing the custom gpg-agent.service made most of my desktop usable again, gpg-agent itself does not work,
even invoking gpg-connect-agent /bye just hangs
Comment by fermi (fermi) - Monday, 12 June 2017, 14:15 GMT
I see the following errors (same with 2.1.21-3):
"pam_systemd(sshd:session): Failed to create session: Connection timed out",
"user@1000.service: Failed with result 'timeout'", ...
I only have one service in ~/.config/systemd/user/ which is totally unrelated to the gnupg service.
It's an intermittent issue, during several reboots my user service starts fine, no errors, during other attempts, the errors pop up, and the user service isn't started.
What I also see is in case the service isn't started the log file is flooded with:
systemd-resolved[265]: Switching to DNS server ... for interface wlan0 messages ...
The fact that this is intermittent: race condition?
Are we looking at the same issue here? Or do I have to explore in another direction?

Thanks,
/fermi
Comment by Jan Alexander Steffens (heftig) - Monday, 12 June 2017, 19:20 GMT
Do you have more logs from just before user@1000.service timing out? Resolved stuff should be unrelated.
Comment by Sean Enck (enckse) - Monday, 12 June 2017, 19:53 GMT
Following Christian's advice I was able to both fix login and have a working gpg-agent
1. I did what everyone above suggests: rm .config/systemd/user/default.target.wants/gpg-agent.service (reboot, login isn't slow, no working gpg-agent)
2. rm gpg-related units from /etc/systemd/user/sockets.target.wants/
3. Re-issue my systemctl --user enable for gpg-agent.service (recreating link from #1)
4. Reboot -> working gpg agent and login is not slow

There may be a more optimal order of operations but this did work for me
Comment by Jan Alexander Steffens (heftig) - Monday, 12 June 2017, 21:08 GMT
The shipped gpg-agent.service has no [Install] section so an "enable" would fail. You still have custom units installed.
Comment by Sean Enck (enckse) - Tuesday, 13 June 2017, 19:09 GMT
@Jan - understood

I do believe I've removed the "custom unit" that I had now, though. Just to complete the circle for what I had to do where I was locally running gpg-agent before and now am not, from my last comment/state

5. I've issued
systemctl --user --global enable dirmngr.socket
systemctl --user --global enable gpg-agent.socket

6. I removed my custom unit scripts entirely (from ~/.config/systemd/user)
7. Reboot (everything works)
Comment by David McAdoo (geecroof) - Saturday, 24 June 2017, 15:17 GMT
I don't understand why symlinks go to /etc/systemd/user/sockets.target.wants rather than /usr/lib/systemd/user/sockets.target.wants as pulseaudio already do.

/etc dir is for local administration, i.e. you can mask those units globally there. In current config you can't do this.

Also it's better to do this symlinks in PKGBUILD package section so it will be clear those belongs to gnupg package.

BTW: what's rationale for enabling this units by default rather than leave it to user?
Comment by Jan Alexander Steffens (heftig) - Saturday, 24 June 2017, 15:27 GMT
This way disabling works; masking is harder and even prevents manual starts. You're wrong about PulseAudio; it uses the same scheme.

Ratiomale: GnuPG already autolaunches the daemons. This way they're under control of the supervisor instead of free-floating.

Loading...