Hello all,
I've a problem with an application that runs over Oracle, it generates an error, this error is automatically redirect into a file, also this error doesn't stop. And the worst thing I cant kill the process without stoping Oracle, the application and so on.
So, the "log file" started to increase in size till 30GB (text file), then I decided to write a cron that does: /bin/echo "" > big_file, so the file reduces its size to 0... actually i do this once per hour. BUT! when I want to see If it has really shrinked I can't verify it. I mean, after decrease the size i run the following commands:

df -h -> The overall file system size has decreases (ok...)

du -h -> (inside de directory of the file) The file has just a few kbytes (ok...)

ls -l -> The file has 40GB and growing... (¿?¿?¿?)

At first sight, I said "ok, no problem if the whole sistem size has decreased". But what about the inodes? what about...i don't know! My question is, what can happens? I'm not sure about the consequnces...

Any comment would be appreciated!

Try this instead:

If you're not actually looking at the errors, can you just turn off logging to file? or log to /dev/null?

I have encountered this exact problem with .xsession-errors using KDE. This is a problem with the ext file system (I think). You can't *really* delete an open file, and some programs seem to open then hold open their error file forever.

When you try to delete the file, you will succeed in removing its entry from the directory structure, but the file still exists since there is an open handle to it. Your app continues to write to it, and the file doesn't really vanish until all open handles are gone - and sometimes it doesn't vanish then until you unmount the volume and force fsck to run (fsck will report the file system as clean until you force it).

I have a couple of "chatty" programs on my system (debugging turned on and I don't have the source so can't turn it off) which fills my .xsession-errors. The way I "solved" the problem was to shut down KDE, then delete the file, then recreate the file as root, as a symlink to /dev/null. This prevents me from receiving error messages that I would like to know about, but at least it keeps my /home partition from filling up and crashing my session.

When you change such a file into a symlink, your program might look for a fallback place to write these errors. After doing what I did to .xsession-errors, I also had to do the same thing to ~/tmp/.xses-jiml (my username) and also to /tmp/.xses-jiml. Then, finally, I wasn't filling partitions with spurious nonsense.

So, the answer seems to be that you'll have to shut down Oracle, delete the file, unmount the partition and fsck it, remount the partition, create the symlink, and restart Oracle.

Not what you wanted to hear, I know, but it is the solution that I have for you.

Thank you very much for your answers. You are right, it's not what I wanted to hear but that can solve (meanwhile) my problem.
Just one more question: ...what can happen if...the file is growing (as usual) and I do echo "" > to_the_file. The problem is that the file keeps growing but not the filesystem, I mean, the command ls -l shows the size before "echo" and growing but "df -h" shows the size without the file (0 bytes). Well, its just curiosity.

When you do an echo "" >, I *think* that the file system treats this like a deletion, so it unlinks the open file from the directory structure, and links in the new blank file that you have created with the echo.

But, there is still that live file handle to the old file, so it just keeps on a'growin' until you run out of space. And, since it is "deleted", you've lost control of it altogether.