vmunix file size became 18GB

[Arindam Basu]

Hi
Today I found that the size of the file vmunix has became 18GB for that our root file system became full can I delete the file or do anybody knows why the size of the file is increasing.

Thanks & Regards

[Pete Randall]

By "vmunix", do you mean /stand/vmunix? That is the kernel and you don't want to be deleting that without good reason. Do you have a /stand/vmunix.prev file? How big is that? Did someone make changes to the kernel recently? Did someone write over the kernel with something?

I would try restoring the kernel from backup.


Pete

[Mark Nieuwboer]

Hi i wouldn't touch vmunix becauce its your kernel. If your / is growing i would look into /etc because there are some files which can grow very big.

grtz. mark

[Peter Godron]

Arindam,
if you are referring to the /stand/vmunix file, I would not advise to remove it. However 18GB is enormous. Check that nobody has, by mistake, created a false kernel.
Start with a simple file /stand/vmunix
Look at the ownership and date of the file.
Also check that it is really 18GB, ours is approx 30Mb for example

[Sunil Sharma_1]

I can't believe it. vmunix file of 18GB. paste the output of ll /stand here.

[Bill Hassell]

It's not possible to generate a multi-gigabyte kernel file. Normally, /stand (where the vmunix file is located) is only a few hundred megs so an 18Gb file can't be srored in that location. Even the root filesystem is only a few hundred megs. Please post the output of these commands so we can help:

bdf -l
ll /stand
du -kx / | sort -rn | head -20

[Srini Jay]

Aridam,
Like others have mentioned 18GB is way too high for a kernel!
Like Bill had mentioned, /stand filesystem is normally less than a Gig.
And also /stand normally doesn't have largefile option turned on.

And I'm not sure if you are referring to /stand/vmunix or someother file that someone created under a different directory by mistake(?)!

[Kent Ostby]

I suspect that someone has done something like:

tar -f /stand/vmunix and forgot the /dev/rmt/ file.

More than likely it is now a tar archive.

I would suggest that you restore it from a known backup and check your permissions.

[James R. Ferguson]

Hi:

My thinking goes along the same line as Kent's. I suspect that someone specified '/dev/rmt/om' instead of /dev/rmt/0m' when doing a backup. Thus the '/dev' file system has a very large, regular file named '/dev/rmt/om' --- that's the letter "o" instead of the number "0".

Look for non-special (regular) files in '/dev' as the culprit.

Regards!

...JRF...

[Devender Khatana]

Hi,

I think it is a slightly misunderstood scenario. The size of /stand/vmunix can never be 18GB, and that too of a running system. Can you post the output of

#ll /stand
&
#bdf

Also as vmunix for newer versions of HPUx is always in a seperate file system shall not cause root to become full. Moreover neither /stand nor root is generally much less than 18GB.

HTH,
Devender

[Muthukumar_5]

I hope other files are making an image that / file system with 18GB. You can specifically find the size /stand/vmunix file with ls -l or ll command.

Post the,

# bdf
# ls -l /stand/vmunix

information.

you can also find the most active usage of directory or file in / as,

# du -k / | sort -rnk 1 | more

-Muthu

[Arunvijai_4]

Hello, Please post the result of following commands,

# bdf
# ll /stand/vmunix

/stand is different FS and it wont be 18GB ..

-Arun