hi

I have an sun ultra 5 running a firewall which has logging enabled (essential). The disk is sliced up with /proc on / (c0t0d0s0). / is sliced at 3 gig. My problem is this, one afternoon, a manager asked me to retrieve some firewall logs, so i went into the relevant directory (also on the / slice) and typed 'ls -l', for some reason the last 6 days logs were empty (0 bytes), so my first instinct was to run 'df -k' to see how much space was left on /, as i thought it was at 100%, so at root i used 'du -sk *' to check what was eating the space, everything was fine apart from /proc which reported 2.6 gig. I delved deeper and indeed found directories ie 156 and 24967 which both came in at nearly a gig each.

Everthing I have read has said that /proc is virtual and these direcotries dont actuall eat any space, but if this is the case how come DF and DU report on it and how come when DF reports 100% on / because of these so called virtual files, It doesnt allow me to write anything to the disk, Ive even tried to create afile on /
using 'touch file' with no joy

Any help on this extremely frustrating matter would be greatly appreciated

regards
Gary

Look at it this way... If your root filesystem filled up and you ran "du -sk *" from /, I'll bet that you will get some large number for /var, and /usr among other too. But you know to ignore those because they're a seperate filesystem. You can see what filesystem they are on by doing:
df -k /usr
df -k /var

So run the following command:
df -k /proc
What do you get? How much of that zero do you think that you need to recover? If you're bummed out at how big the subdirectories 156 and 24967 seem to be...it's this easy:
kill -9 156 24967

Once the process is dead the subdirectory will no long appear.

As for your problem...do I understand that you are storing firewall logs on the root filesystem and then you are wondering why root is full??!! Don't store stuff in the root filesystem! Use other filesystems for that.

Thanks perdarabo

I inherited this firewall, and believe me, i am in total agreement about the logs on root thing, but at the moment the logs are extremely minimal in size and were used as an example of my inability to write to the disk. I also accept that df is reporting ok after trying df -k /proc, my apologies. However why when i run du -sk * on root does it report 2.6 gig on /proc and subsequently stop me writing to that disk. If /proc is virtual and is a reflection of processes running, does that mean that 2.6 gig of my disk space on root is being used by o/s and firewall daemons/processes, because that is all thats running on the box ( the o/s has been hardened and stripped down to basics), if so, i would find that hard to comprehend. (the firewall manufacturer does not indicate anything about 3 gig of space to run in its minimum spec).With all due respect to your suggestion of using kill -9 on the process ids, im sure you can appreciate that in a production environment this is not something i can do. Put basically, if there are 2.6 gigs being used by a few processes then something must be wrong, and I still need a workable suggestion if anyone has one

Any help would be greatly appreciated

/proc is a seperate filesystem. Just like /usr ot /var is a seperate filesystem. /var is a mount point. Do a "du -sk /var/*". I'll bet that you find some files there. Do you understand that the files in /var have no bearing at all in the space consumed in root? /proc is the same way. It is a mount point. What's more the filesystem that is mounted there is not real. If you can't grasp that, just ignore it. You don't look in /var for files to delete when root is full do you? Well don't look in /proc either. Or /usr. Or /tmp. And so on. You need to find files in root to delete. Removing a file from /var does not return space to the root fileststem. Neither would /proc.

If you want more space in your root filesystem, you must delete some files that reside there. Deleing files in other filesystems won't help. The space in root is consumed by files that reside in root. When a file resides somewhere else it doen't eat up space in root.

As for how it works, type:
df -n / /proc
and you can see the filesystem type. When you open a file on / the open system call see that / is a ufs filesystem. So it calls the ufs code to open the file. The ufs code really does read a disk somewhere to get its info. On the other hand, when you open a file in /proc, the open system call sees that the file is in a proc filesystem so it calls the proc code. The proc code scans the currently running processes instead of reading a physical disk. And the read, stat, and write system calls do the same thing. This is called the filesystem switch. It was first used to put nfs into the kernel.