System /proc folder consuming space

[NoWorries]

I have just realized that I only have 408MiB of root space left out of 11GiB. When I used Dolphin's file properties option on /proc I got weird results saying that there were about 128 TiB used. In /proc there are folders listed from 1 to 3680. I cannot delete any of these folders as I get permission denied when I issue the command for any one of these folders, eg

sudo rm -r -f /proc/2

.
Is there anything that I can do to recover my space under these circumstances?

[GreyGeek]

System /proc folder consuming space

/proc is the mount point for procfs and there aren't any files in it. When processes don't terminate cleanly they leave inodes open. You can find out which processes own the virtual files using
lsof | grep deleted
Or
lsof -Nr 2 -- /proc
That will give you the PIDs, which you can use to identify the process, and start and stop the process


Sent from my iPhone using Tapatalk

[NoWorries]

Thanks for your suggestion GG. I was able to get "some" of the files in /proc deleted without any dire consequences.

I had a closer look at my Wife's Laptop "sybil" which is similarly configured with packages. I found that the /proc folder had similar characteristics to the one on my system "basil". I used Dolphin's file properties to find the size of all folders excluding /home and /proc. On "basil" I had 11.00GiB used out of 11.0GiB!!!! On "sybil" there was 5.6GiB out of 10.9GiB, which is what I would expect.

On closer inspection, I found that /var on "sybil" was 815.1GiB while on "basil" is was 4.5GiB. I then found that my system had a /var/log of 4GiB. I removed this folder and my system created a new /var/log. Now I have 4.4GiB of free space in my system area.

So I am now relieved that my system in not going belly up, and I can fulfill my responsibilities.

[GreyGeek]

You may want to look at the man page of logrotate.

[NoWorries]

Thanks, I just checked and it is installed on my system. Looks like I will have to configure it so that I do not get caught out again.

[kubicle]

Thanks for your suggestion GG. I was able to get "some" of the files in /proc deleted without any dire consequences.

You shouldn't do that, unless you are really, really sure you know what you are doing.
And the /proc filesystem is a virtual filesystem, it does not reside on disk (and therefore takes no disk space), kernel runs it in memory.

http://tldp.org/LDP/Linux-Filesystem...html/proc.html
http://www.tldp.org/LDP/sag/html/proc-fs.html
https://en.wikipedia.org/wiki/Procfs

[NoWorries]

Thanks for the clarification of the role of /proc. I don't think I made many changes to /proc on my system and all is working well now.

I should point out that I was taking desperate measures to find the reason for my system running out of free space. It gets difficult to do anything when there is just over 300MiB of free space. What surprised me was that /var/log was allowed to have 4.4GiB of log files!

I firmly believe that /var/log should be automatically trimmed without the "average user" having to undertake a seek and destroy mission to get back free system space.

[kubicle]

It gets difficult to do anything when there is just over 300MiB of free space. What surprised me was that /var/log was allowed to have 4.4GiB of log files!

I firmly believe that /var/log should be automatically trimmed without the "average user" having to undertake a seek and destroy mission to get back free system space.

logrotate should usually keep /var/log in a reasonable size (mine is usually smaller than 20MB). If the log files grow excessively, it could indicate a problem with the system (something writing errors to the logs extensively). Unfortunately it's hard to figure out it that is the case since you already removed the old logs (but you should keep an eye out for the log files in case they start to grow large again).

logrotate can be configured to trim logs more often and/or to keep backlogs for a lesser period of time, but like I mentioned, the default settings are usually enough to keep things down to size.

If the log problem rears it's big head again, we can try to analyze the problem more, but the contents of /var/log is vital in deduction...so maybe post again if you see it (and try to catch the problem before it gets so bad the system starts bogging down, maybe when /var/log grows to 1GiB or so?)

[SecretCode]

Glad you've sorted it out. In future the most basic way to find out where space is being consumed is the du command, with the -x flag to avoid following links onto different partitions (filesystems), and some -d flag to avoid your display filling up with every file on the system
e.g. (not tested)

sudo du -x -d 1

Or use xdiskusage (also with sudo to get files you can't see as a user) which uses du and presents a simple treemap that you can navigate.

[vinnywright]

Glad you've sorted it out. In future the most basic way to find out where space is being consumed is the du command, with the -x flag to avoid following links onto different partitions (filesystems), and some -d flag to avoid your display filling up with every file on the system
e.g. (not tested)

sudo du -x -d 1

Or use xdiskusage (also with sudo to get files you can't see as a user) which uses du and presents a simple treemap that you can navigate.

nice ,,,we like that ,,,,,, I added the -h (for human readable sizes) and gave it a start point of /

vinny@vinny-Bonobo-Extreme:/mnt/btrfs/kubuntu/Music/Ministry - Psalm 69$ sudo du -x -d 1 -h /
16M     /bin
659M    /lib
64K     /tmp
4.0K    /srv
11M     /etc
119M    /boot
14M     /root
4.0K    /snap
5.1G    /usr
4.0K    /lib64
4.0K    /mnt
4.0K    /cdrom
3.9M    /lib32
9.2G    /home
8.0K    /media
170M    /opt
16K     /lost+found
865M    /var
19M     /sbin
17G     /

nice

VINNY