0

when we run lsof to capture deleted files ,

we see the following: ( example )

lsof +L1
java      193699  yarn 1760r   REG   8,16      719     0  93696130 /grid/sdb/hadoop/hdfs/data/current/PLP-428352611-43.21.3.46-1502127526112/current/path/nbt/dir37/blk_1186014689_112276769.meta (deleted)

what is the reason that PID still running in spite files already deleted

lsof +L1 | awk '{print $2}' | sort | uniq
193699 

is it possible to avoid this scenario?

closed as off-topic by Rui F Ribeiro, Jeff Schaller, Fabby, roaima, Mr Shunz Jan 14 at 9:56

  • This question does not appear to be about Unix or Linux within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Don't delete them? – Jeff Schaller Jan 13 at 18:43
  • The application still holds a open handle to those files. The application would need to release the handle (close the file) to make the file really disappear. – Hermann Jan 13 at 18:48
  • 1
    Most apps have open files (title). You've pointed out an app with open , deleted files. You then ask why the app is running like that and how to avoid the scenario. What do you want to see happen? The app stop when an open file is deleted? – Jeff Schaller Jan 13 at 19:05
  • 1
    If it's you who wrote that java app, take care to close any file handles when you no longer need them -- notice that unlike memory objects, file handles are not automatically garbage collected (that could only work in a language which is using reference counting, like perl; if you don't close a stream in java, any fd it's using will leak when the object it's part of is destroyed) – mosvy Jan 13 at 19:06
  • 2
    I'm voting to close this question as off-topic because this is a programming style issue, not a U&L issue. – Fabby Jan 13 at 20:04
5

Too long to put in a comment, so adding as an answer:

That's a Java application keeping those files open, so yes, this scenario can be avoided by using a proper programming style and using the ObjectOutputStream object:

//create a Serializable List
List lNucleotide = Arrays.asList(
  "adenine", "cytosine", "guanine", "thymine", "sylicine"
);

//serialize the List
//note the use of abstract base class references

try{
  //use buffering
  OutputStream file = new FileOutputStream("lNucleotide.ser");
  OutputStream buffer = new BufferedOutputStream(file);
  ObjectOutput output = new ObjectOutputStream(buffer);
  try{
output.writeObject(lNucleotide);
  }
  finally{
output.close();
  }
}  
catch(IOException ex){
  logger.log(Level.SEVERE, "Cannot create Silicon life form.", ex);
}

By closing the file at an application level you will avoid this problem. So this is not a result of Unix or Linux doing anything wrong but inherent to your application.

  • 1
    (And the answer was also posted to make all Computational Biologists here smile...) – Fabby Jan 13 at 20:08
  • Just want to point out a separate possibility -- that the files were removed outside of the java program. – Jeff Schaller Jan 13 at 20:28
  • @JeffSchaller: Oh, you mean the OP wants to know how to avoid having the files deleted? (I.e. Exclusive lock?) Ping me in chat. – Fabby Jan 13 at 20:33
  • 1
    @RuiFRibeiro Apparently: Garbage collection will only free the resources within the JVM. The resources assigned to the VM by the operating system will still be reserved. (Edited) – Fabby Jan 14 at 0:33
  • 1
    “a proper programming style” — better still, use try-with-resources! – Stephen Kitt Jan 14 at 7:05

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