Linux root partition issue

[muralikrishna]

Hi

i am using more crontab entries so that i am getting sendmails more. I deleted all logs from rescepctive folders i.e /var/log/, /var/spool/clientmqueue/, var/spool/mqueue/, /var/spool/mail. If these folders are empty also root partition is increasing day by day. After rebooting my root partition size is resized i.e i am getting more space in root partition.

I want know where linux storing temparory data. I am using itanium server. my tmp folder is not more than 10mb always.


p

[Vitaly Karasik_1]

Can you please send us output of:

1) df

2) du -x / |sort -rn |head

[Steven E. Protter]

Shalom,

You need to identify the distribution to get accurate help.

You have for Red Hat covered all the temporary storage areas for mail.

What you need to do next is find the source of the email.

/var/log/maillog

Contains a record.

The source may be external. It may be internal. Someone could be trying to relay spam through your server.

Take a look at what cron is running versus the logfile and see if you can find the source.

df -kh
fdisk -l

Provide information on partition structure.

One of the things Red Hat default configuration does I don't like is not providing distinct file systems. By default there is / and nothing else, or /boot plus / in lvm.

This is not a good management approach.

SEP

[muralikrishna]

HI Karasik

Please find the output

[Vitaly Karasik_1]

weird! for now you about 12GB free into your "/", it should be enough.

Can you please run the same commands when your "/" usage is close to 100%?

[Matti_Kurkela · Accepted solution]

The disk space was freed when rebooting the server?

Maybe you deleted a file that was held open by some application. If you do that, the file vanishes from the directory but the disk space is not freed until the application closes the file. This is standard Unix behaviour.

Before deleting any log files, you should use the "fuser" command to make sure the log file is not held open by any process.

If the file is held open, it is better to truncate it to zero size rather than delete it. This causes the disk space to be freed immediately.

Example: to truncate the file /some/logfile.txt to zero size, use this command:

> /some/logfile.txt

(Yes, the command is just a ">" sign.)

If someone has deleted files that are held open by an application, the only way to free the disk space without rebooting is to make the application stop using the file. Often this means stopping & restarting the application.

To identify the application that is holding the deleted files, use this command:

lsof +L1

It will list all deleted files that are still open, and the PIDs of the processes that are holding the files.

MK

[Steven McCoy]

Good call Matti. We had a rogue java process here holding onto a multi-gig file that filled /home. The file had been 'deleted', but since the process was never manually killed, it kept filling the 'deleted' file. Rebooting, of course, killed the process and free'd up that space. I'm wondering if the situation is the same in muralikrishna's case.

[muralikrishna]

Hi Matti

is it possible to assign for all files in a directory ?
> /some/log.txt

i need to resize entire folder.

[Steven McCoy]

I think you'll get an 'ambigous redirect' message by doing that. What I would recommend:

for i in /var/log/somewhere/*; do >${i}; done

HTH

[Vitaly Karasik_1]

but before cleaning your logfiles I suggest to verify that they are really taking many diskspace.
till now we don't know that.