0

As the heading says. I've tracked down which file is growing to fill the filesystem, it's /proc/kcore. Here's a snippet of 'ls /proc'

{ -rw------- 1 root root 140737471590400 Nov 9 02:54 kcore }

I tried 'tail /proc/kcore' but it's obviously a binary file and wouldn't stop until I killed it. Even logged in as root, it wouldn't let me delete it. Heeelp! Peter

OldBikerPete
  • 1
  • 1
  • It's not really a file on a disk. /proc is a virtual filesystem. By simply googling the file, I found this SO question: https://stackoverflow.com/questions/21170795/proc-kcore-file-is-huge – Oskar Skog Nov 10 '23 at 00:41
  • 2
    /proc/kcore being huge is not an issue at all. Are there any real signs of trouble? – Oskar Skog Nov 10 '23 at 00:43
  • Oscar Skog: On my system /proc is a subdirectory of the root filesystem - not a tempfs or virtual filesystem.

    The problem is (if you look at the numbers) is that my approx 45GB installation has produced an approximately 400GB kcore file which only stopped growing because there was no room left on the partition.

     – OldBikerPete Nov 10 '23 at 01:03
  • And BTW most processes which write to the disk repeatedly faled after about 4AM Melbourne AU time because they couldn't write to the disk. 'no room on filesystem'

    If there were a way for me to attach a file, I would attach the syslog and maybe the dmesg log to assist an answer.

     – OldBikerPete Nov 10 '23 at 01:15
  • That makes no sense. /proc should be a virtual file system, I don't think it can even work otherwise. There will of course exist an empty directory proc in the root file system, but that's just the mount point. Can you run du -h /proc to check how much disk storage /proc actually uses? – Oskar Skog Nov 10 '23 at 02:00
  • ran du -h /proc. I got a loooonnngg list of '0 filename'.

    There's no point in pursuing the line that /proc should be a virtual filesystem. On my machine IT IS NOT.

     – OldBikerPete Nov 10 '23 at 02:07
  • I'm going to be incommunicado for a couple of days. – OldBikerPete Nov 10 '23 at 02:09
  • 2
    What is the output of findmnt -T /proc/kcore? Please [edit] and add this information to the question. Note 140737471590400 from the output of your ls is 128T, not 400G; but try ls -ls /proc/kcore and you will most likely see the size on disk (first number) is 0. The problem with your root filesystem lies somewhere else. Try sudo ncdu -x / to track the real culprit; and if there is nothing suspicious there then see this question: 2T file system full! du says only 70G consumed. Where is the rest? – Kamil Maciorowski Nov 10 '23 at 05:21
  • Run mount | grep /proc & post. On my system, it returns proc on /proc type proc (rw,nosuid,nodev,noexec,relatime). The proc type means it is virtual, not real. – Bib Nov 10 '23 at 10:36
  • Kamil maciorowski: Output from findmnt -T /proc/kcore is: TARGET SOURCE FSTYPE OPTIONS /proc proc proc rw,nosuid,nodev,noexec,relatime

    Output from ls -ls /proc/kcore is: 0 -r-------- 1 root root 140737471590400 Nov 12 03:54 /proc/kcore

    du -H produces a looong list of file and directory names all preceded by 0

    Bib: I get that "this is a virtual filesystem' answer .

     – OldBikerPete Nov 12 '23 at 04:31
  • OK. Apologies to Oscar Skog: Just because there is no 'tempfs' line for /proc output from 'df' doesn't mean that proc is NOT a virtual filesystem. – OldBikerPete Nov 12 '23 at 04:34
  • Thank you all for your efforts on my behalf. Each answer shed some light on the problem. Kamil Maciorowski: Thank you for the tip to run (needed to install it!) ncdu. Using this utility I was able to track down the disk hog that was causing the problem. It was a cp command to restore my personal data from a backup. I had directed it to the wrong (too small) disk, realised I'd done that and thought I'd killed that process - not so.

    Now if I could finde a button which activates the 'Solved message, I'd press it.

     – OldBikerPete Nov 13 '23 at 01:00

0 Answers0