Logging into the greeter fails often

[senntore]

Usually I'm able to log-in but sometimes the greeter doesn't seem to work as expected. I don't get the error message(below) in all of those occasions but I did got it once. unable to send message: Transport endpoint is not connected (os error 107)

Let me know if anything on my end would fix this for me.

[jamestait]

This sounds similar to an issue I'm experiencing. The error message is not exactly the same, but it sounds like it might be affecting the greeter in the same way. I get unable to send message: Connection refused (os error 111). I'm not sure when this started, because I've just rebooted for the first time since probably before Christmas.

Restoring gdm3 as the display manager with sudo dpkg-reconfigure gdm3 has allowed me to log in again; prior to that I was worried it was something to do with my somewhat esoteric setup, which started life as a standard Ubuntu installation some 10 or so years ago and has probably accumulated some cruft.

Another item I think I've ruled out is my use of sssd for LDAP-based single sign-on: reconfiguring PAM to exclude SSS authentication via sudo pam-auth-update did not resolve the issue.

What's the best way for me to provide system configuration info and debug logs to help resolve this?

[aschiavon91]

I'm also receiving unable to send message: Connection refused (os error 111) after trying to login, but in my case, I have pam-fprint configured.

[jamestait]

I did a little digging with strace and was able to see the conversation between greeterd and (presumably) the SSS PAM module/backend; I realised that a character in my password was incorrect, and recognised the incorrectness as being due to an incorrect keyboard mapping: US QWERTY instead of UK QWERTY. So I was able to login with the necessary correction, although on the successful attempt I didn't observe the conversation as I has before. This matched the behaviour under gdm3, so it could be that it's using the locally-cached credential DB in that instance.

I'll keep poking it to see if I can narrow it down further, but I'm groping in the dark a little bit because I'm not quite sure of the order the different processes are invoked and how the messaging works between them -- and in an attempt to avoid caching, I'll probably need to reboot between each attempt.

[jackpot51]

54 may have improved this.

[senntore]

I tested it multiple times and it seems to work. Now it fail only when trying to log in to a Pop wayland session(x-org seems to work). But since we won't have a gnome(wayland) session by default in the alpha, I imagine it's okay to close this for now. Feel free to close this issue.

[jackpot51]

Thanks for testing. I will work on the GNOME Wayland issue in #18

[WatchMkr]

This problem still occurs on my darp8. This report could be helpful: https://github.com/pop-os/cosmic-greeter/issues/56

[WatchMkr]

Should be fixed with this today's updates.

[cncastillo]

I have the latest updates from staging master, and I am still experiencing problems logging in (same as in #56).

jul 30 11:36:23 pop-os cosmic-session[3756]: Starting cosmic-session
jul 30 11:36:23 pop-os cosmic-session[3756]: starting process ' COSMIC_SESSION_SOCK=12 cosmic>
jul 30 11:36:24 pop-os cosmic-session[3756]: process ' COSMIC_SESSION_SOCK=12 cosmic-comp ' f>
jul 30 11:36:24 pop-os cosmic-session[3756]: cosmic-comp exited with error code 1
jul 30 11:36:24 pop-os cosmic-session[3756]: draining stdin receiver before restarting process
jul 30 11:36:24 pop-os cosmic-session[3756]: sleeping for 1ms before restarting process cosmi>
jul 30 11:36:24 pop-os cosmic-session[3756]: restarted process ' COSMIC_SESSION_SOCK=12 cosmi>
jul 30 11:36:24 pop-os cosmic-session[3756]: process 'ProcessKey(1v1)' cancelled

Results of journalctl -b-1 > cosmic.log cosmic.log

Interestingly, when I am connected to my eGPU with an RTX 2080 Ti, I get no errors, but when I am just using my laptop with a GTX 1650 Ti, I do. an external monitor I am able to login successfully. Unplugging it also crashes the session (laptop's screen goes black).

Results of journalctl -b-1 > cosmic_external_monitor.log cosmic_external_monitor.log

Hardware Neofetch results (from Gnome Wayland session):

```bash ❯ neofetch --backend off ccp@pop-os ---------- OS: Pop!_OS 22.04 LTS x86_64 Host: Blade Stealth 13 (Late 2020) - RZ09-0327 5.04 Kernel: 6.9.3-76060903-generic Uptime: 14 mins Packages: 4180 (dpkg), 23 (flatpak) Shell: zsh 5.8.1 Resolution: 1920x1080 DE: GNOME 42.9 WM: Mutter WM Theme: Pop Theme: Pop-dark [GTK2/3] Icons: Cosmic [GTK2/3] Terminal: gnome-terminal CPU: 11th Gen Intel i7-1165G7 (8) @ 4.700GHz GPU: NVIDIA GeForce GTX 1650 Ti Mobile GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics] Memory: 3575MiB / 15756MiB ```

UPDATE: I just deleted my .local folder, and now it works! :smile:

[curiousercreative]

FWIW, this seems to be happening with a similar regularity to before, 1 in 3 boots will fail to start session on first attempt. The above comment mentions deleting .local folder which I'm not at liberty to do. Is there a specific file to remove?

[git-f0x]

The only thing that seems related is ~/.local/state/cosmic-comp/outputs.ron, but not sure. It's automatically recreated on login if deleted.

[mmstick]

The fix was disabling ecryptfs in PAM. Haven't seen any login issues since removing the ecryptfs-utils package.