Debugging some CouchDB problems, I was looking for (still open) deleted files:

$ lsof -nP | grep '(deleted)'

And to my surprise I found that Google Chrome has around 16900 such files:

  • 15870 files in /run/shm/.com.google.Chrome/
  • 969 files in /opt/google/chrome/

And there are around 350 deleted files from other applications (Dropbox, etc)

  • Does this mean Chrome is "leaking" files?
  • Do these files use up memory (appart from the small use of kernel table entries)? I guess not: they are probably only in the filesystem, albeit without directory entry.
  • Do they use disk space? I would say so, since they are still open, the kernel is not freeing up the disk space.

I have Google Chrome Version 43.0.2357.130 (64-bit), and my system is:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty
  • It doesn't leak - and yes they use disk-space. To Chrome they're not deleted - those are files which exist only in Chrome's namespace sandbox. I think it's kind of cool/weird you can detect them at all. Anyway, Googke prohibits any Chrome tab process from reaching out and touching the filesystem - and that's mostly how. They had to come up with something like it to push the HTML 5 filesystem into the spec. – mikeserv Jun 30 '15 at 9:03
  • Yes but ... 17000 files! Are they all being used by Chrome? Or are they forgetting to close the file handles somewhere? – dangonfast Jun 30 '15 at 9:06
  • No, they all get closed... eventually. Have you ever looked at Chrome's own task manager? Do shift+esc. – mikeserv Jun 30 '15 at 9:09
  • Well, I have around 40 tabs, and 17000 files. I find it difficult to believe that all those files are needed by chrome right now. I find it easier to accept that, since I started chrome (yesterday), it has been opening and closing files, deleting some, forgetting to close some, and we have reached a situation where some not needed files are still open. I mean ... 17000 files! – dangonfast Jun 30 '15 at 9:13
  • 1
    No, they're not all needed, but neither are 39 of your tabs. There's at least one process for each tab - and then there are renderers and V8 and ... well, there's a lot going on there - and you've got 40 times that. And anyway, what does it matter? Those are mostly all in RAM. – mikeserv Jun 30 '15 at 9:17

That's not a problem on your system, it's the way Chrome works. It isn't leaking memory or files or anything, that's data that Chrome is currently using.

Chrome uses many separate processes (not exactly one per tab, but that's the general idea). Some of these processes need to exchange data. They do this via shared memory. Chrome implements (at least some of) this shared memory via files in an in-memory filesystem (tmpfs) which are deleted as soon as they're created (ensuring that the files don't get mixed up).

The files you're seeing don't take any disk space, they take up memory. They're located under /run, which is an in-memory filesystem. They can get swapped out like almost anything else in RAM.

The only time when you'd be seeing deleted files under /opt/google/chrome is if you've upgraded Chrome but not restarted it yet. Restart it and the deleted files will go away.


mikeserv says "39 (out of 40) of your tabs [are not needed]".

This is (probably) not true. Yes, we look at only one tab at a time. We keep multiple tabs because, at different times of the day, we need the info in those tabs and, usually, want to pick from where we left off, after consulting info in other tabs.

When chrome is running, something called "Composito", "WorkerPoo", and chromium use 26% of the 270,479 open files. This seems rather excessive for 30 tabs!

41062 Composito
17078 chromium-
12625 WorkerPoo

With my 30 tabs, lsof reports around 170 instances of various library modules:

lsof | grep '^Composito' | sed -e 's/^.............................................................................................//' | sort | uniq -c | sort -nr
173  /usr/lib/locale/locale-archive
172  /usr/lib/x86_64-linux-gnu/libXss.so.1.0.0
172  /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
172  /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
172  /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
172  /usr/lib/x86_64-linux-gnu/libXinerama.so.1.0.0
172  /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
172  /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
  • is this supposed to be answer or more question? – mikeserv Oct 23 '15 at 19:03
  • It's more info. It's shocking to me to see so many files being kept open by these 3 programs. It's 2 orders of magnitude more than I would have expected. I'm still getting truncated Thunderbird messages. That problem was cured when I upped the number of open files in /etc/security/limits.conf from 4096 to 8192, but the problem is back again! Do I really need to up the number of open files to half a meg? – Chelmite Dec 19 '15 at 7:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.