Fixing quicklookd going nuts on MacOS

Today I looked into a problem with my father’s late 2012 Mac Mini running MacOS High Sierra. Since about a week the machine got terribly slow and often unresponsive. It turned out the system was extremely busy with   kernel_task and quicklookd as per the screenshot below:

Once the CPU load peak started, it would never reduce, making the system almost unusable until a reboot and started again shortly after logging in to the system. More interesting was that the quicklookd process was using memory like crazy:

So within about 6 minutes of processing time, it was already occupying 45GB! of memory. This kept growing till the use of the Swap memory reached it’s 64GB limit and the process died. Since LaunchDaemon is making sure it runs it then got restarted and the whole process got repeated. Even though the CPU load was high, it did not consume all CPU so the system could still be used but the high IO load on the disk caused by swapping memory still killed the performance (despite having an SSD).

So great, it’s clear what is causing the slow computer though even after spending quite some time on googling the symptoms I could only find (quite a few) others that had similar issues but no solutions. The best hint I saw was referring to a corrupt file so I started checking that first. To get the list of open files of the quicklookd process I ran:

lsof -p `pgrep quicklookd` | less

Browsing through the list of open files, I noticed that there were not real data files in there that could be corrupted. Given the symptom – continuous growing memory usage – I would have expected a single file being processed for a long time, which clearly was not the case and (in my opinion) ruling out the corrupt file theory for now.

As this looked more like an internal data corruption to me I decided to check the other files the processes had open. With this I noticed that it created a sqlite cache (DB), which I have seen getting corrupted in other cases. To get the list of files in the cache directly I ran:

ls -l `getconf DARWIN_USER_CACHE_DIR`/com.apple.QuickLook.thumbnailcache

which produced the following output:

total 57024
-rw-r--r--  1 user staff         0 Nov 24 14:42 dirty
-rw-------  1 user staff         0 Nov  9  2013 exclusive
-rw-r--r--  1 user staff     12288 Nov 24 14:50 index.sqlite
-rw-r--r--  1 user staff         0 Nov 24 14:50 index.sqlite-wal
-rw-r--r--@ 1 user staff  29176786 Nov 24 14:50 index.sqlite.lasterror
-rw-r--r--@ 1 user staff        18 Nov 24 14:42 resetreason

The existence and size of index.sqlite.lasterror drew my  immediate attention and when looking at the contents of the file (with the last line repeated 320k+ times) it was clear that this sqlite database indeed got corrupted.

unexpected behavior of sqllite bridge: (triggered by 14 - database errcode: 14 - unable to open database file)
error while preparing 'SELECT value FROM preferences WHERE key='version''
error while executing 'CREATE TABLE preferences (key TEXT UNIQUE PRIMARY KEY, value TEXT)'

To fix this, I backed out the corrupt data directory with:

mv `getconf DARWIN_USER_CACHE_DIR`/com.apple.QuickLook.thumbnailcache `getconf DARWIN_USER_CACHE_DIR`/com.apple.QuickLook.thumbnailcache.corrupt

and restarted the quicklookd daemon with:

pkill -9 quicklookd

QuickLook re-created a new com.apple.QuickLook.thumbnailcache folder and started creating the icons normally again. CPU Load was normal and the memory usage did not grow anymore.

8 Replies to “Fixing quicklookd going nuts on MacOS”

  1. Thanks Frederik! Seems to have sorted the same problem om my machine, MBP Late2013, OSX Sierra. CPU/memory problem started after a System Update yesterday. Strange. In my case, the thumbnails.data file was by far the largest (95503328) but your commands worked.

  2. Worked like magic! Thanks.
    The only little point is that for MacOS Mojave, the security would not let you do the operation, throwing the ‘Operation not permitted error’. The way to get around this is to reboot and hold Cmd + R. Open Terminal and type ‘csrutil disable’. This would disable the System Integrity Protection (SIP). You can turn it back on in the same way but this time with ‘crustily enable’.

  3. Thank you so much! Was trying out solutions until I got to the index.sqlite.lasterror and wasn’t able to find a solution on StackOverflow. Luckily I found this and avoided having to backup my computer and wipe it clean.

  4. I’m not a terminal guru but I had the same symptoms, changed the com.apple.Quicklook.thumnailcache folder name within Finder to add .corrupt, and then used your pkill command to relaunch quicklookd. It worked like a dream and I have my daughter’s computer back. I could watch the file storage back off in the course of 30 seconds from completely full to normal (32G free on the 129G drive). Running High Sierra 10.13.6 on a 2014 Macbook Air. Beautiful!

  5. Worked perfectly. As someone who doesn’t know how to code or use terminal, following your commands (matched with the exact same problem file) worked perfectly. Thanks Frederik!

  6. Thank you for posting this. I have been trying to sort this out for hours and your thorough description appears to have worked a treat.

Leave a Reply to Jake Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.