Code change:
If account-daemon restarts in a gnome3 session it totally breaks and becomes unusable. What happens for me if account-daemon restarts is that I see the screen flash like the login animation from gdm. All programs are still up. But the mouse is frozen and I can't even switch to a tty with my keyboard. The only thing that it actually responds to seems to be Ctrl+Alt+Delete which triggers a reboot. And this indicates that I'm actually in a tty but I see an image of my gnome-session. This is a problem when doing nixos-rebuild switch etc. I had a proposed fix in but dropped my branch because I was unsure if that fixed the issue, but I'm having that overriden in my personal config here: And it's much better while doing or or so than it was before. This can be tested by just doing a . system: host os: multi-user?: sandbox: version: channels(etu): channels(root): nixpkgs: cc
This is also breaking my ui whenever I try activate a configuration. Stack trace of , with and compiled with . Stack trace of from a coredump, with regular libraries:
Filed bug upstream:
For those looking to work around this, it should be sufficient to remove any config. (Untested).
This still an issue
oh, sorry. I've forgotten about this issue and stopped running gnome like 8 months ago. So I have no idea :D
I'm able to confirm that when using in GDM that restarting the accounts-daemon does crash the session. And isn't a sufficient workaround.
I'm seeing a very similar stack trace from in my user session after a -triggered . I'm not using GDM auto-login. I don't have debug symbols but here's the stack trace from . Note that the top of the stack is still in in libaccountsservice. When I went looking at the source for these functions, the only thing which made sense was that returned , which led me to the upstream bug and then to here.
Had the exact same issue today. my backtrace is identical to that of
This needs an upstream fix as reported in This is very confirmed.
I've been testing the workaround on one laptop and not on another. On the laptop without the workaround, upgrading from to caused to crash. On the laptop with the workaround, upgrading to that version from an older version () did not lead to a crash. why did you say this is not a sufficient workaround? It's kind of a pain to test so I can easily believe I'm missing something. Is it important to restart on upgrade? I assume no other distro has reported this bug or there'd hopefully be more activity in the upstream bug report. Are other distros just not restarting it on upgrade for some reason, maybe? Perhaps it's that… because NixOS treats as changed if any of its transitive dependencies change, we upgrade+restart it a lot more frequently than anybody else does? Maybe nobody else is noticing because changes rarely and other distros aren't triggering the crash often enough to annoy people into investigating?
I'm also seeing this crash and UI hang during . I am not using at all (I'm using ). I'm able to recover the hung session if I can get to a terminal by running . I left a note in with log output.
Still happens on NixOS 20.03 because the fix was never ported. Here is my backtrace from gdm, which seems to be exactly the same as reported earlier in this thread.

Related discussion:
text: ''; patches = [ <ins> # https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/55 (fetchpatch { url = "https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/58.patch"; sha256 = "1pnwq4ycnryb2kkgvnz44qzm71240ybqj6507wynlkdsw8180fdw"; }) </ins> (substituteAll { src = ./fix-paths.patch; inherit shadow coreutils;