Root partition filling up [Complete]

[rodgoslin]

I had a problem, some time back, when I found that the root partion was gradually filling up. There didn't seem to be any reason for it, but the available room gradually disappeared. In the end, I reformatted the root partition, and reloaded the operating system , and all was well. later, I came to the conclusion that a security camera, that I'd installed, was, all unbeknownst to me , continually adding camera shots, in the root partition. How, or why, I never found out. To my mind the root partition is a place where user files are never, never put. But now, I find that as a matter of course, user files find their way in via /run/, a very dubious idea to my mind. However, to the point. Earlier on installing a minor update, I was surprised to get a note to the effect that the root partiton was full. My practise, has been, in these days of hefty HDD's to allocate lots of space to the root partition. In this case 16GB, for an anticipated OS load of some 7 0r 8GB. Now the system tells me that usage in the root partition stands at 100%. In earlier Windows days, I had a utility, Tree Size Pro which graphically showed where the stuff was and how much of the available space it used. I've not found anything in Linux to match it. Does anyone know have any ideas? Everything, on the surface looks fine, but 8Gb of unwanted stuff has to be somewhere. I could do as I did before, but I didn't like doing it before, and I'll less like doing it again, this time. I've not put in any details, but I can supply, if required .

[benmc]

old ones but maybe:

viewtopic.php?f=7&t=6187&p=40629&hilit=journal+size#p40629

viewtopic.php?f=7&t=6019&p=39669&hilit=journal+size#p39669

[doktor5000]

To my mind the root partition is a place where user files are never, never put. But now, I find that as a matter of course, user files find their way in via /run/, a very dubious idea to my mind.

/run is a tmpfs which is not located on the root partition but in your RAM. It contains what was previously contained in /var/run - which was located on the root partition.

Code: Select all

df -P /run
Filesystem     1024-blocks  Used Available Capacity Mounted on
tmpfs             16444888  1316  16443572       1% /run

In earlier Windows days, I had a utility, Tree Size Pro which graphically showed where the stuff was and how much of the available space it used. I've not found anything in Linux to match it.

Not sure where you looked, there are plenty of alternatives. See e.g. http://alternativeto.net/software/trees ... form=linux for a list.
I like baobab for checking user folders or external disks. For checking the root partition I simply use

Code: Select all

du

E.g. to show root filesystem, folder sized summed up and sorted desendingly by size:

Code: Select all

du -smx /*|sort -rn

Or if you want to see 10 biggest folders

Code: Select all

du -mx /|sort -rn|head

[rodgoslin]

Thanks for the replies. While they're not pointing me to a solution, they're giving me more information. One snag, with looking at the root system, is that practically everything else is mounted in it, so obscuring what I'm looking for. Since my sytem comprises four HDD's . A 2TB drive with the root and home systems on it, a 4TB drive for backups (Back-in-Time), a 2TB drive for overspill and a 450MB unit slated for replacement in the near future. Added to that is mounted a Drobo unit with a capacity of 14TB. The root system at 15GB, is insignificant in comparison. A small needle in a very big haystack. The command line function du -mx...etc is helpful, particularly since it ignores the Drobo, and the reuslts of this I've posted below.

[root@down tmp]# du -smx /*|sort -rn
du: cannot access ‘/proc/16605/task/16605/fd/3’: No such file or directory
du: cannot access ‘/proc/16605/task/16605/fdinfo/3’: No such file or directory
du: cannot access ‘/proc/16605/fd/3’: No such file or directory
du: cannot access ‘/proc/16605/fdinfo/3’: No such file or directory
3314372 /home4
1835368 /home3
1610622 /home
10838 /usr
2753 /var
502 /root
195 /opt
125 /boot
36 /etc
1 /tmp
1 /srv
1 /run
1 /mnt
1 /media
1 /lost+found
1 /initrd
1 /home2
0 /sys
0 /sbin
0 /proc
0 /lib64
0 /lib
0 /dev
0 /bin
[root@down tmp]#

On the face of it /usr seems to be hogging most of the disk space. Benmc's second link has a useful suggestion to delete one of the log files in /var, the next likely candidate. In my case that would eliminate 1.6GB, and art least give me a breathing space. At the moment, I'm unable to add any more software, since there's no space for it.

[doktor5000]

One snag, with looking at the root system, is that practically everything else is mounted in it, so obscuring what I'm looking for.

No, the -x option will prevent du from traversing filesystem boundaries.
Although if used liked you did, due to the shell globbing /* if there are filesystems mounted directly at / those will be traversed on their own.

It might help if you could provide the output of

Code: Select all

df -Pm /
du -mx /|sort -rn|head -35

[rodgoslin]

As requested.

Code: Select all

[root@down tmp]# df -Pm /
Filesystem     1048576-blocks  Used Available Capacity Mounted on
/dev/sda1               15437 14630         0     100% /
[root@down tmp]# du -mx /|sort -rn|head -35
14447   /
10838   /usr
4604    /usr/src
2753    /var
2221    /usr/lib64
1955    /usr/share
1607    /var/log
1545    /var/log/journal/d2989e3c112e47ce81f33a44bfaf036f
1545    /var/log/journal
1323    /usr/lib
612     /usr/bin
584     /var/tmp
579     /usr/src/kernel-4.1.8-1.mga5
579     /usr/src/kernel-4.1.15-2.mga5
579     /usr/src/kernel-4.1.15-1.mga5
579     /usr/src/kernel-4.1.13-2.mga5
579     /usr/src/kernel-4.1.12-1.mga5
573     /usr/src/kernel-3.19.8-3.mga5
573     /usr/src/kernel-3.19.8-2.mga5
571     /var/tmp/kdecache-rod
569     /usr/src/kernel-3.19.4-2.mga5
502     /root
497     /root/.local/share/Trash/files/BEAN_MOVIE_G52/BDMV
497     /root/.local/share/Trash/files/BEAN_MOVIE_G52
497     /root/.local/share/Trash/files
497     /root/.local/share/Trash
497     /root/.local/share
497     /root/.local
494     /root/.local/share/Trash/files/BEAN_MOVIE_G52/BDMV/STREAM
441     /usr/lib/modules
333     /usr/src/kernel-4.1.8-1.mga5/drivers
333     /usr/src/kernel-4.1.15-2.mga5/drivers
333     /usr/src/kernel-4.1.15-1.mga5/drivers
333     /usr/src/kernel-4.1.13-2.mga5/drivers
333     /usr/src/kernel-4.1.12-1.mga5/drivers
[root@down tmp]#


[doktor5000]

Code: Select all

4604    /usr/src
571     /var/tmp/kdecache-rod
497     /root/.local/share/Trash/files/BEAN_MOVIE_G52/BDMV


Nearly 6GB to clean up, including multiple 500MB'ish kernel sources.
And don't even get my started why you have something in the trash in root's home.
Running a filemanager as root and then you put something in the trashbin and forget about it?

That's half of your / partition.

[jiml8]

You should not be using root for anything other than system administration. You certainly should not be watching movies as root; if the movie file contains a malicious macro, you are toast.

Take a look at ncdu. You will probably find it to be helpful in sorting out your problems.

Also, consider using tmpwatch to clean up /var/tmp from time to time.

[rodgoslin]

I did note, after running the du -mx command, that the old kernel files were still there, and a possible source of the problem. But then, I still thought that the kernel files were held in the /boot directory, and that was still small.. I also , perhaps naively, that issuing the command 'remove' in the boot setup function of the the Control Centre, would actually remove the unwanted kernel structures. Perhaps I was thinking too rationally. As to the use of root, I have, since data Robotics introduced the 2nd generation of the Drobo unit, used them for long time bulk storage. Unfortunately whilst the units ran on a version of Linux, DR made a point of declaring that they were uninterested in supporting their use by Linux users. My current unit, the Drobo-fs, is even less amenable to be used under Linux, but as root, I can move files in and out, with ease. The alternative was to use a Windows box as intermediary, which was not on..Sending files to root trash was an earlier mistake, in sending files to 'trash' without finding out how to empty the trash directory, wherever root has it installed. And no. I do not watch films as root. but I've not come up with a way to easily transfer files, except as root. I'll manually delete the old kernel files and that would seem to solve the problem.

[doktor5000]

I did note, after running the du -mx command, that the old kernel files were still there, and a possible source of the problem. But then, I still thought that the kernel files were held in the /boot directory, and that was still small.. I also , perhaps naively, that issuing the command 'remove' in the boot setup function of the the Control Centre, would actually remove the unwanted kernel structures.

/boot contains the bootable kernel images. /usr/src contains kernel sources.
Removing any bootloader entries in MCC will not remove the respective kernel packages but only the bootloader entries.

For how to transfer files as non-root, best open a new thread and describe what you want to transfer to where.

[rodgoslin]

Thanks for the assist in this. I'll keep in mind the necessity to separately delete the kernel source packages, in future. As to root assisted file transfer, Ill try another thread on the matter. The main snag here, is that on the Drobo, all files are owned by root, with root as the group, with full permissions. 'rest' is read only. On the older Drobo unit, it was possible to gain root access and to create users, which facilitated file transfers. With the newer units, this option does not seem to be open by any means that I've been able to locate. Windows, on the other hand, sees the Drobo as a mounted drive with full access to storage. How they do this, I've no idea. I'll indicate this thread as complete

[doktor5000]

Thanks for the assist in this. I'll keep in mind the necessity to separately delete the kernel source packages, in future.

Well, why install them in the first place?