Unable to truncate file

[Satish Y]

Hi Experts,

Currentlt I am facing a strange problem with a file.
File is of size almost 2 Gb, when I try to truncate the file, getting truncated but get restores automatically after few seconds.

Another funny thing is, the filesystem size is 2GB, this file itself occupies almost 2 GB and if I sum up sizes of all files in filesystem(including this) it counts approx 2.5GB, but filesystem usage shows 97%.
How is it possible?

Cheers...
Satish.

[Michael Tully]

You need additional space in which the file is used to truncate before the original file is purged. So you need at the amount of the truncated file before you start. Suggest you move it elsewhere if possible.

[Satish Y]

Hi Michael,

Can't move it, it's a open file.
But we truncated lot of large files even when filesystem is 99% full and not sufficient space left.

Cheers...
Satish.

[john korterman]

Hi Satish,

you did not mention how you actually truncated the file.
The only acceptible way of truncating an open file that I know of is to cat /dev/null to the file. This will truncate the file to size 0 and set the file pointer to the start position of the file. Example of doing that to a file named listener.log:

# cat /dev/null > listener.log

If you cut off pieces of an open file, the process holding the file open will not be aware of that, and the process will continue to write after the position in which the file pointer was at the last write to the file.
Therefore the file may seem larger than it actually is, which might explain why it seems to be bigger than actually possible, but perhaps other members can offer better explanations.

regards,
John K.

[Muthukumar_5]

Can you check the filesystem memory informations as,

# bdf
# df


And to truncate the file just do as,

sed -e '1,1000!d' >

echo "`sed -e '1,1000d' `" >

It will delete 1000 lines and put into new file so that we can trim the files there.

[Elmar P. Kolkman]

I think your problem is caused by the process(es) that write to the file.

They apparently do a 'seek' to a certain point in the file before writing data. If the file is not the large enough yet for that position in the file, the file becomes sparse and will report as being large enough to contain the data at the right point in the file.

We created files of almost 2 Gb this way on filesystems of 60Mb some years back....

That's also the reason for the second point you mention: the sparse files look to be more the the total size of the filesystem, but they only use 97% of the 2Gb, not 2.5Gb. Until some process decides it wants to write in the sparse parts of its files, which will soon fail, of course.

[Prashant Zanwar_4]

Surely there are process that are writing to file. You have to kill these processes first and then only you can truncate this file as per your desire.

fuser
ps -aef | grep
kill
or
/sbin/init.d/ stop
cat /dev/null > filename

This should be solution to your problem.

Thanks
Prashant

[Prashant Zanwar_4]

Surely there are process that are writing to file. You have to kill these processes first and then only you can truncate this file as per your desire.

fuser
ps -aef | grep
kill
or
/sbin/init.d/ stop
cat /dev/null > filename

Say also once you stop the processes, you can do du -sxk * under the FS mount point.

du -sxk * | awk '{sum += $1; print sum, $1}'

This will come to some number. If this is what you see with the bdf, then its perfect. Or if it is less, then you have something there below the mount point. Then you have to umount FS and see if any files are lying beneath the mount.

Hope it helps


This should be solution to your problem.

Thanks
Prashant

[Shine_5]

Hello Satish

Is there any apache is running on this .. if so .. can you pl stop and start the same
This will solve the problem.

Regards
Shine

[R. Allan Hicks]

Under Oracle we have a similar problem with the alert log.

(For those unfamilar with Oracle) The alert log is where Oracle puts all of its diagnostic messages. If left unattended, this file will eventually consume the whole disk.

We find the following script run at Midnight frees the disk space but keeps the file for future reference.

#!/bin/ksh
. /home/oracle/.ora_defaults
cd $ORACLE_BASE/admin/ORCL/bdump
mv alert_ORCL.log alert_ORCL`date +%C%y%m%d%H%M%S'.log
touch alert_ORCL.log

We review the logs each morning and delete them if they have nothing of interest in them. Oracle doesn't seem to notice that the file was moved.

[Satish Y]

Hi Elmer,

As you said:

>They apparently do a 'seek' to a certain point in the file before writing data. If the file is not the large enough yet for that position in the file, the file becomes sparse and will report as being large enough to contain the data at the right point in the file.

Do we have a fix for this one? so that it should not happen again.
Because of this our users unable to write some important entries into file.

Cheers...
Satish.

[Hein van den Heuvel · Accepted solution]

>> Do we have a fix for this one? so that it should not happen again.

No. This is application design. They have chosen to 'remember' where they are, supposedly for a reason. You'll have to work with your application provide to come up with a mechanisme to roll-over, or start a new log when the file gets too big.
HPUX is just doing what it is told to do by the application.

>> Because of this our users unable to write some important entries into file.

Make up your mind! It is either important or it is not. If you are willing to truncate, it must not be important. :-).

A log file that gets to be 2GB deserves to have a serious design, complete with maintenance, purge, and summary funstions or you might just as well not have it. No-one will read-through and check 2GB raw data.

Is this application ever stopped/restarted?
That would be the time to rename and start a fresh file as a matter of procedure.

Can you perhaps force a stop/restart in a few seconds and move teh file inbetween?

Cheers,
Hein.

[Satish Y]

Hein,

Application users copied file to other location, gzipped and truncated original one.
However, I have suggested them to restart the application, but not sure if they have done.

Cheers...
Satish.