View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012808||CentOS-7||gnome-shell||public||2017-02-13 10:26||2018-01-23 15:32|
|Target Version||Fixed in Version|
|Summary||0012808: Gnome-Shell freezes after 50 days running|
we are in the process of moving to CentOS as the base platform for our products. After an uptime of around 50 days we noticed on many of these systems that the user interface freezes and is not usable any more. On most systems one can still click on the taskbar but the shell wont switch to the selected application. Sometimes one can still use (parts of) the applications, sometimes they won't react to any input at all. Often it is still possible to open the app menu and start new programs.
Most of the time it is possible to restart the gnome-shell with alt+F2 => r, then everything works again (probably for the next 50 days). But sometimes this won't open the command menu and then everything is frozen.
These systems were all installed with a custom kickstart installation but i could reproduce this bug with a standard installation.
I don't know if that bug appears on 7.3 but i expect it and i will start a test and check it.
|Steps To Reproduce||Make a standard installation of 7.2.1511 (all settings on default). |
Open a terminal ( make a loop that prints the time every minute ) (don't know how important that step is)
wait 50 days
Note: In my test that system was without network connection all the time.
|Additional Information||a 32bit unsigned int timestamp (max 4294967295) with a millisecond precision overruns after 49.71 days.|
I have taken a look at the gnome-shell source code and i found some timestamps that could lead to these problems but i wasn't able to find out, where the problem exactly is.
|Interesting - I also noted that gnome-shell in CentOS 7 became painfully slow after running for several weeks. The problem was there in point released before 7.2.1511 as well but IIRC 7.2.1511 was the last time I tested it - I simply switched to Mate from EPEL instead.|
This is still an issue in latest 7.4. (Or at least 50-day old 7.4, since it takes a long time to reproduce.)
Here are some potentially-interesting log-messages from /var/log/messages:
org.gnome.Shell.desktop: Window manager warning: last_user_time (20691848) is greater than comparison timestamp (4262798381). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around...
org.gnome.Shell.desktop: Window manager warning: 0x1800076 (TITLE_OF_WINDOW) appears to be one of the offending windows with a timestamp of 20691848. Working around...
journal: Couldn't lock screen: Timeout was reached
org.gnome.Shell.desktop: Window manager warning: last_focus_time (20699824) is greater than comparison timestamp (4262798381). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around...
org.gnome.Shell.desktop: Window manager warning: last_user_time (20699655) is greater than comparison timestamp (4262798381). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around...