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
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
|
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
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.
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
"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
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
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)
/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?
Ratiomale: GnuPG already autolaunches the daemons. This way they're under control of the supervisor instead of free-floating.