Login Loop on Fresh Boot about howdy HOT 14 CLOSED

I have had this issue started showing up since switching to KDE Neon using the Plasma desktop. Just like the OP, I can only get this issue to happen on the first login after boot. If I switch to another TTY I am able to login with Howdy. Meanwhile, TTY1 (the desktop login session) is frozen on the login prompt until I reboot.

Anything I can do to collect some more information to help troubleshoot this?

from howdy.

I have that same behaviour on Mint 21.1 Cinnamon.
It works on Terminal, but not on fresh login. Logoff emidatelly after.
There is no more dismiss_lockscreen in the config anymore.

from Auth.log:
Dec 26 15:40:54 kruno-L2 sudo: kruno : PWD=/home/kruno ; USER=root ; COMMAND=/usr/lib/linuxmint/mintUpdate/dpkg_lock_check.sh
Dec 26 15:40:54 kruno-L2 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Dec 26 15:40:54 kruno-L2 sudo: pam_unix(sudo:session): session closed for user root

from howdy.

That's an issue outside of howdy if it starts to log in. One problem with using anything else than a password is that your keyring does not get unlocked, which can cause some problems.

When logging in and failing you can switch to another tty by pressing ctrl + alt + F1, does it work there?

from howdy.

It works and identifies me, and from what you describe it seems to be something outside of howdy.

I can flip to a TTY and use that to log in with howdy and get to a shell and all works there. But still no desktop after a fresh boot.

There seems to be something about a fresh boot that hangs this because sleep, hibernate, lock, screensaver, and logout all allow me to log right back in with howdy and the desktop pulls up just fine.

If this is something more Linux related than something wrong with your app you can close this issue and call it a day.

from howdy.

If it works in a clean TTY it's not an encrypted drive issue or problems like that, so i strongly suspect it's a keyring issue.

Do any errors show up in tail /var/log/auth.log or dmesg?

from howdy.

Any progress here?

from howdy.

If I may, I am getting the same issue with the "looping" login on boot. I looked through my var log auth.log file, and if you'd like I have some bits that could be interesting. Care to reopen?

This is the part that seemed to be relevant, or documenting when the behavior is occurring. Based on the logged times the last one is the successful password login after waiting out the howdy, and the one before is a looped behavior. Let me know if it needs to include more before before or after:

Jul 23 21:31:20 FAN1FNU systemd-logind[948]: Watching system buttons on /dev/input/event4 (AT Translated Set 2 keyboard)
Jul 23 21:31:21 FAN1FNU gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Jul 23 21:31:21 FAN1FNU systemd-logind[948]: New session c1 of user gdm.
Jul 23 21:31:21 FAN1FNU systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Jul 23 21:31:22 FAN1FNU polkitd(authority=local): Registered Authentication Agent for unix-session:c1 (system bus name :1.29 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jul 23 21:31:57 FAN1FNU gdm-password]: pam_unix(gdm-password:session): session opened for user nathanj by (uid=0)
Jul 23 21:31:57 FAN1FNU systemd-logind[948]: New session 2 of user nathanj.
Jul 23 21:31:57 FAN1FNU systemd: pam_unix(systemd-user:session): session opened for user nathanj by (uid=0)
Jul 23 21:31:59 FAN1FNU gdm-password]: pam_unix(gdm-password:session): session closed for user nathanj
Jul 23 21:31:59 FAN1FNU systemd-logind[948]: Removed session 2.
Jul 23 21:31:59 FAN1FNU systemd: pam_unix(systemd-user:session): session closed for user nathanj
Jul 23 21:32:14 FAN1FNU gdm-password]: pam_unix(gdm-password:session): session opened for user nathanj by (uid=0)
Jul 23 21:32:14 FAN1FNU systemd-logind[948]: New session 4 of user nathanj.
Jul 23 21:32:14 FAN1FNU systemd: pam_unix(systemd-user:session): session opened for user nathanj by (uid=0)
Jul 23 21:32:16 FAN1FNU polkitd(authority=local): Registered Authentication Agent for unix-session:4 (system bus name :1.82 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jul 23 21:33:19 FAN1FNU pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
Jul 23 21:33:19 FAN1FNU pkexec[2498]: nathanj: Executing command [USER=root] [TTY=unknown] [CWD=/home/nathanj] [COMMAND=/usr/lib/update-notifier/package-system-locked]

I'm a bit new to linux, but I hope that's what you were getting at with the previous poster.
(thanks for the work on the project:)
Nate

from howdy.

Thanks for reviving this! Just to be sure, are you experiencing the same behavior as the original poster?

The logs don't show anything that could help, just that the session IS authenticated correctly but immediately closed. I take it there are no lines mentioning howdy or python errors?

from howdy.

With the exception of the "fixing the missing cv2 module" thing (I'm not sure what that is I don't remember having an issue during installation with that) the situation is the same.

Inside that file there are no records of howdy or python at all, and I can't make heads nor tails of dmesg

EDIT: Meaning I don't see anything related to software errors or issues in that log (dmesg)

from howdy.

Following up on issues i forgot to reply to, are you still having this problem or did you fix it/uninstall Howdy?

from howdy.

from howdy.

I've installed the project on an ubuntu budgie install, and this problem has yet to recur. New, unrelated, ones have cropped up and I'll try and fix them when I have a minute later. Unless others keep having similar experiences I would say that this bug doesn't need a thread right now.

from howdy.

I'll close it then, haven't heard from anyone else with this specific issue yet. If it does come up feel free to reopen.

from howdy.

same issue here on Mint 21+ login loop present for the first time then it works. No logs whatsoever that could identify anything and bring this case further ... will continue to observe and update if anything interesting found despite this thread is closed.

from howdy.