What is /proc/kcore?

[motoslide]

I've got a client with RedHat (unknown revision, sorry). They are having a problem where the / filesystem will get to 100%. The largest culprit is /proc/kcore, to which /dev/core is linked. The file is large and has current date/time.

2 Questions:
What is the purpose of this file?
Should /proc be a seperately mounted FS?

Sorry for the "newbie" question. My UNIX experience is thin on LINUX.

 

[stefanwagner]

I think it's an image of your RAM, and shouldn't be removed.
I guess you may not remove it.

Are messages in /var/log rotated and zipped?

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[jkupski]

/proc isn't a real filesystem--it's a virtual filesystem that makes various bits information about the system available, and allows other bits to be modified for tuning purposes. The idea behind this is an extension of the "everything is a file" UNIX philosophy.

None of the "files" in /proc are taking up any disk space. /dev/core is just a symlink to /proc/kcore, and is also not taking up any disk space.

Your problem, as noted by stefanwagner, is probably related to your logfiles (as evidenced by the continued problem you're having with growth--what grows more regularly than logfiles?) but to be sure, execute 'du -h -c --max-depth=1' from /var/log and see what kind of space they're taking up.

 

[motoslide]

Thanks for the replies. I will investigate further. The issue yesterday was that the "/" filesystem was at 100%, and /proc/kcore was viewed to be about 280MB. From what Stefan says, maybe that was just a reflection of the amount of physical RAM on the system. But, when I did:
# du -s /proc
the system came back with a large number.
So, within the /proc directory, I entered:
# find . -type f -size +50000 -print
That's where "kcore" came to my attention. The "/" filesystem is only about 380MB is size, and I found only another directory with tape backup logs that was about 50MB. Nothing else is large, except for the real application data, which is on a mounted filesystem.

 

[ericbrunson]

Type "mount" and notice that /proc is not part of /, it's a separate file system.

 

[ProbablyDown]

Try using the "fuser" command. If you do a df -h you may have a /var if not then your /var/logs is in / and may also be the culprit. Depends on how you have it set up.

 

[ericbrunson]

find / -type f -size +50000 -mount -print
Will limit the find to a single filesystem.

 

[motoslide]

This is the output for the "mount" command:
/dev/sda5 on / type ext3 (rw)
none on /proc type proc (rw)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/sda1 on /boot type ext3 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda3 on /home type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/sda2 on /usr type ext3 (rw)
/dev/sda7 on /var type ext3 (rw)

The "df -h" produces this:
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 372M 187M 165M 53% /
/dev/sda1 48M 6.0M 39M 13% /boot
/dev/sda3 4.2G 3.8G 163M 96% /home
none 125M 0 124M 0% /dev/shm
/dev/sda2 11G 6.7G 4.1G 62% /usr
/dev/sda7 248M 73M 162M 31% /var


It appears that the /proc/kcore must not have been the problem, although I'm still a bit confused over what I saw on the system yesterday.
I appreciate the feedback. The system is OK for now. I think somebody else found something in the "/" filesystem to remove.

 

[ProbablyDown]

Your /home is the culprit... / is only 53% full. Check to see if any log files are going to a specific user there.

 

[motoslide]

The /home is another issue. We have a user configured with a Roaming Profile and they have a HUGE directory on their desktop. They have been beaten and scoffed at repeatedly. It takes about 45 minutes to log onto that workstation! Yesterday's problem was 100% usage on "/", honest.

 

[ProbablyDown]

Your / is pretty small...

Well if you find the cause to be a file, a simple fix would be to move the file and create a symbolic link.

# mv myhugefile /usr/myhugefiles/myhugefile
# ln -s myhugefile /usr/myhugefiles/myhugefile

Good Luck...

 

[SamBones]

Your problem might be that [tt]/tmp[/tt] is on your [tt]/[/tt] filesystem. Anything that writes a huge file to [tt]/tmp[/tt] (which could be anybody), would eat up [tt]/[/tt]. This could be something as simple as sorting a big file.

The filesystem [tt]/tmp[/tt] should always be on it's own device, just for this very reason. I would add another volume and create [tt]/tmp[/tt] on it.

Hope this helps.

 

[motoslide]

Your / is pretty small...

Yeah, but at least it's pointed in the right direction!
That's getting kind of personal!! Besides, size doesn't matter.

I appreciate the advice. I didn't create this installation, I just inherited the remote support role for this one.

 

[ProbablyDown]

LOL! That's a myth!

Well I think SamBones is onto something as well... But by the sounds of it, you have a few options and directions to look into. I would look at separating tmp to its own fs

 

[dsryan]

G'day all,

motoslide, may I suggest you hunt around google and linux admin sites for info on inodes.

I recall a similar problem someone had a while ago and while df showed space available, they could not create any files due to lack of inodes.

I cannot recall how to check how many are left hence the suggestion above.

Hope this helps, Dave.