CentOS 7 gdm/gnome locks up after users enter password

[trinisan]

Hi All

Using CentOS Linux release 7.3.1611 on various intel hardware
GNOME Shell 3.14.4 for the desktop.
Users are authenticated over the network

We have a few users who after being away for a few days try to log in to the locked desktop by entering their password.
After entering their password and hitting unlock, the password prompt and the entire screen freezes up.

CTRL+ALT+F2 allows me to get a shell prompt where I can log in to see whats going on. So far I haven't seen any apparent errors jumping out.

/var/log/secure shows the log in was successful e.g. pam_sss(gdm-password:auth): authentication success; but the desktop is frozen.

I've tried loginctl unlock-session N where is the user's session, but that doesn't work or give an error.

To get the user to log in I have to either restart gdm or reboot, both of which causes them to lose progress on anything they may have been working on.
I usually chose to reboot to give them a clean slate.

What should I be looking at to identify the problem and resolve it as it has happened a few times over the last few mths?

Thanks

[aks]

Many years ago had a similar problem and what was happening was the graphic driver would not redraw the new window. The system "thought" all was well, but the screen had not been redrawn. Errors where in X.log. Also check .xsession* in users $HOME

[trinisan]

Thanks for the follow up Aks.

I'm checking those files for the affected users and will upate..

The .xsession files i found were over a year old and no errrors were found in the Xorg.x.log files.

[trinisan]

I added the debug option to gdm.conf and set journald to keep previous logs.

Maybe something more will show up.

[desertcat]

I added the debug option to gdm.conf and set journald to keep previous logs.

Maybe something more will show up.

If you happen to be running a Standard Partitioning scheme one place to check is to run the df command and see if the boot or root partitions are approaching 100% capacity. I had the exact same thing happen, and the only way to solve it was to run Knoppix and then mount the troublesome partition, and then offload some of the data and try to get it back to about 50%, though even cutting it back to 90% should allow people to log back in without problem.

[trinisan]

Hi desertcat

Sorry for the late reply.

I checked and none of the machines are low on disk space.

I remembered this thread as the issue happened to me and another professor this morning.

As of now commonality between the machines are the logins are network authentication (which succeed according to logs) and home directories are on a network share.

[jlehtone]

I remembered this thread as the issue happened to me and another professor this morning.

As of now commonality between the machines are the logins are network authentication (which succeed according to logs) and home directories are on a network share.

Are you still at 7.3 or have you orderly updated (as one should)?

I've seen some up to date systems "freeze". On all several user's desktop processes were on state D, which usually is due to some network share access issue. Most don't have gnome, but xfce. Home via NFSv4.1.

Personally, I've experienced lockup twice since 7.4 update. Not at login. On gnome. Got rid of gamin and haven't suffered since. Knock on wood. (I don't have nautilus either.)

[trinisan]

Are you still at 7.3 or have you orderly updated (as one should)?

I've seen some up to date systems "freeze". On all several user's desktop processes were on state D, which usually is due to some network share access issue. Most don't have gnome, but xfce. Home via NFSv4.1.

Personally, I've experienced lockup twice since 7.4 update. Not at login. On gnome. Got rid of gamin and haven't suffered since. Knock on wood. (I don't have nautilus either.)

Yes still on 7.3, i'll look at 7.4 and upgrade one of the users. Will update on the outcome.

Thanks