Fix Slow GTK Apps on GNOME® after Updating Ubuntu, Manjaro, Arch Linux

Cover image banner for fixing slow GTK apps on GNOME® after updating Ubuntu, Manjaro, Arch Linux

Backstory

I have been using my laptop full-time for the past 3 months. Consequently, my desktop PC remained dormant during this period and the software was obviously (extremely) out of date when I turned on my desktop computer on Wednesday. The very first thing I did was to update all repositories and packages using sudo pacman -Syy && sudo pacman -Syu, and then reboot the machine for a fresh start.

To my surprise, it took around 30 seconds for the desktop to appear after completing the login process. Once on the Desktop, I launched the file manager (Nautilus) to browse my files and I had to wait another 30-40 seconds just for the file manager to open!

I became increasingly concerned as the huge timeouts tremendously impacted the usability of the computer. After a couple of minutes, I noticed that this issue seem to affect only GTK apps such as Nautilus, Gedit, etc. Here are the steps I took to fix the slow GTK apps issue on GNOME^® .

Step 1: Check Systemd Journal Logs

My online research suggested me to inspect the systemd journal logs for anomalies. I closed all Nautilus windows and launched the file manager again to ensure that the latest systemd logs will contain messages pertaining to Nautilus, and then ran this command to display the last 50 logged messages:

journalctl -l -n 50

Below is a partial dump of the journalctl logs:

systemd[1]: Starting Daemon for power management...
upowered[7468]: /usr/lib/upowerd: error while loading shared libraries: libplist-2.0.so.4: cannot open shared object file: No such file or directory
systemd[1]: upower.service: Main process exited, code=exited, status=127/n/a
systemd[1]: upower.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Daemon for power management.
systemd[1]: upower.service: Scheduled restart job, restart counter is at 2.
systemd[1]: Stopped Daemon for power management.

One particular line caught my attention:

upowered[7468]: /usr/lib/upowerd: error while loading shared libraries: libplist-2.0.so.4: cannot open shared object file: No such file or directory

Inspect system logs (journalctl) for slow GTK apps on GNOME®

I concluded that Nautilus is attempting (and failing) to locate the shared library libplist-2.0.so.4 and this was causing the ~30 seconds timeout when launching any GTK app!

Step 2: Search for the Missing Library

Next, I did a system-wide search for the missing shared object. I searched for libplist* instead of libplist-2.0.so.4 in a bid to obtain more potential matches:

sudo find / -type f -name "libplist*"

Search for missing library libplist-2.0.so

One of the entries in the search results was /usr/lib/libplist-2.0.so.3.3.0. However, the library that Nautilus was looking for is libplist-2.0.so.4, which is a newer version than the currently installed one.

Step 3: Dirty Fix to the Rescue

Because the package libplist-2.0 was already installed and up to date, I tried a “hacky” approach by creating a symlink of the currently installed version (libplist-2.0.so.3.3.0) to the one Nautilus is desperately looking for (libplist-2.0.so.4).

sudo ln -s /usr/lib/libplist-2.0.so.3.3.0 /usr/lib/libplist-2.0.so.4

Then, I rebooted my computer and everything returned to normal! 💯

Conclusion

Inspecting systemd journal logs is a great way to quickly identify anomalies. More often than not, the root cause is logged as error messages which directly lead us to the solution thanks to the detailed messages.