When GNOME gives you problems and you want to troubleshoot or report it to the developers, you must find the log files. In addition, you can create additional log files. This requires adding patches, so it requires more experience than the average user. If you’re having trouble getting GNOME up and running, you’ll need to check what’s going on with your display manager. In a typical system, it all starts with GDM. It has its own log files. The most annoying thing that can happen is Shell hanging. Your computer is not responding. What if the shell stops responding?
There is a graphical application for viewing GNOME logs. You can use the ‘GNOME Logs’ app to get an overview.
Most systems will have journalctl
Systemd is the dominant init system on Linux. This system also keeps your daemons and services running during normal operation. GNOME is no exception, any problems can be tracked down using journalctl.
To keep the system running, systemd also logs all events that occur. This includes major events and errors. The logs are saved in a shared file that you can read with journalctl. The usage seems awkward to start with, but it will actually be slick if you know some regexps. There are also ways to filter information.
The most direct way to find out what’s going on and dig in magazines is to do it for your personality. You need to use a numeric ID, which is usually 1000, but check it with the id command.
$ id –user
The result is your user id. Connect it to your log checker.
$ journalctl _UID=1000
All the logs from your user will appear, no need to route them to “less”, it behaves the same. For those who are not yet a fan. In less, you can search for strings using functions and filters like grep.
Other log files
Earlier versions of GNOME used a standard error file. GNOME has changed the location of its logging lately, many sites are reporting using ~ / .xsession-errors as it no longer uses this file in several versions.
Beware GNOME does not write to this file. If this file contains text, then you are running another window manager! You can find your current session data in var / log / syslog, there is a lot of detail there.
Filter with grep or “less” to determine what is not giving your system.
Your desktop may be locked. In this case, check if you have a keyboard response. If you do, hit ctrl-alt-
If you are developing or communicating with a developer to troubleshoot a serious shell problem, you need more detailed logs. To check for severe freezes, you need to recompile gjs and js52 and then look for a core dump.
The patching and compilation procedure is simpler than you think, it is described in the link. The package for checking for kernel dumps is not available on vanilla systems. You need to install the package yourself.
$ sudo apt install systemd-coredump
After installing it, you can compile a list of core dumps using the new tool.
$ coredumpctl -l
When you have done this, post the dumps to the project page https://gitlab.gnome.org/GNOME/gnome-shell/issues Keep the debug package on your system only during debugging. You only need it for troubleshooting!
View the app at a time
The first thing to do if you are having problems with an application is to launch it from the command line. You can run the output to a terminal or send it to a file for further processing. Using regular expressions is also very useful for this job.
Filter by application
If you have a special application that is causing problems, you can filter inside systemd as well. To do this, you have to find the PID you are using and then select that PID from journalctl.
$ ps aux|grep chrome
Use the result as PID in the next command.
$ journalctl _PID
Any problems with interoperability with GNOME will appear here. It doesn’t show what’s going on inside the app. To send to a separate file, use the command below.
$ chrome 2> Chrome-Error.log
Again, this is where you can and should pipe it through tools like grep, sed and others to get the most up-to-date information in your log.
In most cases, GNOME troubleshooting should be done using the journalctl command. Only if you are in serious trouble do you need something else. Look for regular log files as well before reporting problems. They contain most of the information. You have the option to use graphic presentation software to check your files. If you have long logs, make sure you know how to process files using regular expressions. If you’re in serious trouble or looking for a new window manager, use a different virtual terminal to explore.