14

I have a Java application running on Linux with PID 25426. When running lsof -p 25426, I noticed:

java    25426 uid  420w  FIFO                0,8      0t0 273664482 pipe
java    25426 uid  421r  FIFO                0,8      0t0 273664483 pipe
java    25426 uid  461r  FIFO                0,8      0t0 273622888 pipe
java    25426 uid  463w  FIFO                0,8      0t0 273633139 pipe
java    25426 uid  464r  FIFO                0,8      0t0 273633140 pipe
java    25426 uid  465r  FIFO                0,8      0t0 273622889 pipe
java    25426 uid  471w  FIFO                0,8      0t0 273623682 pipe
java    25426 uid  472r  FIFO                0,8      0t0 273633141 pipe

How should this result be interpreted?

I am troubleshooting an issue with too many open files and trying to understand whether this observation is relevant.

As application continues to run, number of pipe entries varies (goes up and down).

tshepang
  • 12,111
  • 21
  • 91
  • 136
James Raitsev
  • 92,517
  • 154
  • 335
  • 470

1 Answers1

20

Definition

  • java - The process with the open file.
  • 25426 - This should be the real PID. If not please let us know what it is by posting the header.
  • 420 w - The file descriptor number followed by the mode it was opened with. (Read / write)
  • 0,8 - Major minor device identification.
  • 273664482 - The inode of the file.
  • pipe - A FIFO pipe that is open in your application.

Interpretation

You are not closing all your streams. There are many open file descriptors in read or write mode that are writing to un-named pipes. The most common scenario for this to happen, is when folks use Runtime.getRuntime.exec() and then proceed to keep the streams associated with the process open. You can use the commons IO utils library to close them or you can close them yourself.

    try
    {
        p = Runtime.getRuntime().exec("something");
    }
    finally
    {
        if (p != null)
        {
            IOUtils.closeQuietly(p.getOutputStream());
            IOUtils.closeQuietly(p.getInputStream());
            IOUtils.closeQuietly(p.getErrorStream());
        }
    }

If that is not the problem, you'll need to dig into your code base and identify where the leaky streams are and plug them.

Community
  • 1
  • 1
Deepak Bala
  • 11,095
  • 2
  • 38
  • 49
  • Thank you for a wonderfully detailed response. I do something like this in my code `process = Runtime.getRuntime().exec(commandLineAsString);` but later `finally { if (process != null) { process.destroy(); } }`. Is `pipe` the result of this execution attempt? Please notice that count of 'pipe's keeps going up and down. – James Raitsev Apr 11 '13 at 19:45
  • `destroy()` is a native method, so no one can tell what it does across OS implementations. Perhaps in your case you are lucky that the terminated process tries to clean up its un-terminated FDs (I'm speculating to try to explain the variance in pipe count). The `destroy()` method's contract does not dictate that the streams should be closed. – Deepak Bala Apr 11 '13 at 19:57
  • Other then the above example, what else will cause `lsof` to report on `pipe`s please? – James Raitsev Apr 11 '13 at 20:37
  • Any code that leaves open file descriptors will be reported. As for pipes they _should_ be restricted to streams. Here's an [article](https://www.coderanch.com/how-to/java/TooManyOpenFiles) discussing it. – Deepak Bala Apr 13 '13 at 11:03