Recurring problems with Login Loops ubuntu 20.10

I seems to be experiencing frequent problems with login loops on ubuntu 20.10 but only on 1 account, other accounts on the same machine work. This has now happens on several machines and I'm trying to get to the bottom of it.

I am able to access tty and login using the credentials of the affected account. I have tried all the copy pasted advice from the various blogs, which all basically discuss the same details.

They all point Xauhtority details etc, but this is definitely not the case. I have gone through most of the questions and answers I am able to find on this forum, but to no avail.

I am not sure what causes the error, I have a suspicion that it may be Snap, but I have accessed the accounts and uninstalled, removed and purged Snap, but that doesn't seem to help.

The fact that seems to occur fairly frequently across several machines, I suspect that is actually a problem with ubuntu, but I can't figure out why.

Anybody else experience this? Or has anyone found a way to exit login loops?

I've tried the following but with no result:

  • https://support.system76.com/articles/login-loop-ubuntu/

Before anyone suggests to read the logs again. I have already tried this step. The syslog seems to contain millions of lines detailing this issue

May  6 09:24:27 geek-i-am gnome-shell\[4017\]: == Stack trace for context 0x55d6b3a55230 == May  6 09:24:27 geek-i-am gnome-shell\[4017\]: #0   7ffe6ac7df10 b   /usr/share/gnome-shell/extensions/ubuntu-dock@ubuntu.com/docking.js:2051 (203207eae7e0 @ 208) May  6 09:24:27 geek-i-am gnome-shell\[4017\]: == Stack trace for context 0x55d6b3a55230 == May  6 09:24:27 geek-i-am gnome-shell\[4017\]: #0   7ffe6ac7df10 b   /usr/share/gnome-shell/extensions/ubuntu-dock@ubuntu.com/docking.js:2051 (203207eae7e0 @ 208) May  6 09:24:27 geek-i-am gnome-shell\[4017\]: Object St.Bin (0x55d6b7bdc680), has been already deallocated — impossible to set any property on it. This might be caused by the object having been destroyed fr> May  6 09:24:27 geek-i-am gnome-shell\[4017\]: Object St.Bin (0x55d6b4a642e0), has been already deallocated — impossible to set any property on it. This might be caused by the object having been destroyed fr> May  6 09:24:27 geek-i-am gnome-shell\[4017\]: == Stack trace for context 0x55d6b3a55230 ==

I found this post https://superuser.com/questions/1644654/gnome-shell-spamming-on-var-log-syslog


Solution 1:

If you have a desktop crash during login but only on one account, it's not a problem with the system, but a problem with your account.

There are two approaches to fixing this. You can either search your account for log files to see if there is a relevant error, or you can start renaming config files until you find what is corrupted.

Before you can try either of these methods, first you need to log in successfully. If you can get into another account, you could use that account and then run 'su - youruser' to switch. Or you can get to a text console by ssh from another machine, or by pressing ctrl-alt-f2 and logging in on the text console. Or you could check if your display manager login has a failsafe session or alternate desktop that works. Any of these may help.

The main log file that would be most relevant for an account crash would be .xsession-errors but there may be another. Generally there are a lot of harmless warnings in this file, and it is difficult to distinguish warnings from errors, but possibly some of the last lines there might give a clue why your session crashed. If you have another user account that doesn't crash, it might be helpful to examine .xsession-errors in that account to get an idea of which warnings are harmless.

Before wiping config files, you should first check if you are over disk quota or the disk your home directory is on is full, as this would easily prevent login.

If you are using gnome-shell, it is possible a shell extension is crashing your session. Gnome-shell has mechanisms in place to automatically disable all extensions after it crashes on login, but if this doesn't trigger, you can try manually disabling them with

   gnome-shell-extension-tool -d

and see if that helps.

Generally config files are hidden, you can see all files with 'ls -a'. You could try moving all your account config files into a sub directory and then see if you can log in. Most of them will be recreated, so if you want to restore your account config, you would copy them back over top of the newly created ones one by one until you find what is crashing your session.

These files are critical to the session, but can be safely deleted if you don't have an open session. If the permissions on these files are wrong or they can't be created, your session will fail: .ICEauthority .Xauthority .xsession-errors

Config files that are critical to the desktop to check are in directories: .local/ .config/ some separate config files are: .dmrc .gconf

Some config files that are not desktop specific but might cause problems are the default config files, and the system defaults can be found in /etc/skel/ ; Generally you don't want to delete those as they don't get recreated, but if they are corrupt it could cause problems, so you could compare them against the defaults or rename them and copy the defaults to see if it is an issue.

There are many other config files, but most of them are application specific and would not affect your desktop.

Very possibly something in .cache/ could be corrupt, and it is generally safe to remove this directory.

That's a few things to check anyway.