Where do I find GNOME logs

When GNOME gives you trouble and you want to find the fault or report it to developers, you must find the log files. Alternatively, you can create extra log files. This requires adding patches, so requires more experience than regular user have. If you have problems starting GNOME, you will need to check what is happening with your display manager. On a vanilla system GDM starts it all. This has its own log files. The most frustrating that can occur is a Shell freeze. Your computer will seem to be unresponsive. What can you do when the shell stops responding?

There is a graphical application to view ‘GNOME Logs’. You can use the GNOME Logs application to get an overview.

Most systems will have journalctl

In Linux, the dominant initialisation system is systemd. This system also keeps your daemons and services alive during ordinary operation. GNOME is no exception, any problems can be traced with journalctl.

Use systemd!

While keeping the system running, systemd also logs any events that happens. This includes major events and errors. The logs are saved in a common file that you can read with journalctl. Usage seems clunky to start with but is actually smooth if you know some regular expressions. It also has ways to filter out information.

The most direct way to find out what is going on and dig through the logs is to do it for your own identity. You need to use the numeric identity, which usually is 1000 but check with the ‘id’ command.

The result is your users id. Plug it in to your check of the logs.

All logs from your user will appear, no need to pipe it to ‘less’, it behaves like the same way. For you who are not fans yet. In less you can search for strings with grep-like features and filters.

Other log files

In earlier versions of GNOME, it used the standard error file. Lately, GNOME has changed where it logs, many sites report using ~/.xsession-errors, since several version, it no longer uses this file.

Watch out, GNOME does not write to this file. If there are text in this file, you have started another window manager! You can find data about your current session in var/log/syslog, it have many details available.

Filter using grep or ‘less’ to find what is ailing your system.

Advanced troubleshooting

You may have the desktop lock up. If this happens, check if you have keyboard response. If you do, press ctrl-alt- where Fn is usually F3, to open virtual terminal (vt) 3. The reason is that GDM uses F1 for vt 1 and your session uses vt 2, leaving vt 3-6 for you to make your own commands. You can then use that terminal to do troubleshooting or open even open an x-session.

If you are developing or are in contact with a developer to troubleshoot a serious shell problem, you need more detailed logs. To check for serious hangings you need to recompile gjs and js52 and then look for the core dump.

Patch-files https://wiki.archlinux.org/index.php/GNOME/Troubleshooting

The patch and compile procedure is simpler than you might think, it is covered in the link. The package to check for where the core dumps is not available on vanilla systems. You need to install the package yourself.

When it is installed you can list the core dumps using the new tool.

When you have done that, send the dumps to the project page https://gitlab.gnome.org/GNOME/gnome-shell/issues Only keep the debugging package on your system while debugging. You will only need it for troubleshooting!

Looking at an application at a time

The first thing to do if you have problems with an application, is to start it from the command line. You can let the output run on the terminal or send it to a file for later processing. Using regular expressions is very useful for this work also.

Filtering per application

If you have a special application that is giving you problems, you can also filter inside the systemd. To do this, you must find the PID you are running and then choose that PID from journalctl.

Use the result as PID in the next command.

Any problems interacting with GNOME will appear here. This does not show what is going on inside the application. To send to a separate file use the below command.

Again, here you can and should pipe it through tools such as ‘grep’, sed and others to get the most relevant information in your log.

Conclusion

Most troubleshooting for GNOME, should be done using the journalctl command. It is only if you have serious problems, you need any thing else. Before you start reporting problems, also find the regular syslog files. They contain most of the information. You have the option to use graphical presentation software for checking files. Once you have long logs, make sure you know how to process files with regular expressions. If you have serious problems or are looking for a new window manager use another virtual terminal to explore.