63

After experiencing a DDOS attack, somehow /proc/kcore is very huge, I use a small php class to check the current disk space, and how many has been used.

It shows the following:

Total Disk Space: 39.2 GB
Used Disk Space: 98 GB
Free Disk Space: 811.6 MB

My question is, is it safe to delete the /proc/kcore file? Or is there a solution on getting it to an normal size.

The filesize of /proc/kcore is 140.737.486.266.368 bytes

I have hosted my server at DigitalOcean.

If any more information needed to know, please ask ;)

Many thanks!

Edit...

df -h returns:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda         40G   37G  755M  99% /
udev            993M   12K  993M   1% /dev
tmpfs           401M  224K  401M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none           1002M     0 1002M   0% /run/shm

du -shx returns:

du -shx *
8.7M    bin
27M     boot
12K     dev
6.3M    etc
4.8M    home
0       initrd.img
229M    lib
4.0K    lib64
16K     lost+found
8.0K    media
4.0K    mnt
4.0K    opt
du: cannot access `proc/3765/task/3765/fd/3': No such file or directory
du: cannot access `proc/3765/task/3765/fdinfo/3': No such file or directory
du: cannot access `proc/3765/fd/3': No such file or directory
du: cannot access `proc/3765/fdinfo/3': No such file or directory
0       proc
40K     root
224K    run
8.0M    sbin
4.0K    selinux
4.0K    srv
0       sys
4.0K    tmp
608M    usr
506M    var
0       vmlinuz

Results of lsof | grep deleted:

mysqld     1356      mysql    4u      REG              253,0           0    1835011 /tmp/ib4jBFkc (deleted)
    mysqld     1356      mysql    5u      REG              253,0           0    1835012 /tmp/ibcE99rr (deleted)
    mysqld     1356      mysql    6u      REG              253,0           0    1835013 /tmp/ibrxYEzG (deleted)
    mysqld     1356      mysql    7u      REG              253,0           0    1835014 /tmp/ibK95UJV (deleted)
    mysqld     1356      mysql   11u      REG              253,0           0    1835015 /tmp/iboOi8Ua (deleted)
    nginx     30057       root    2w      REG              253,0           0     789548 /var/log/nginx/error.log (deleted)
    nginx     30057       root    5w      REG              253,0 37730323404     268273 /etc/nginx/off (deleted)
    nginx     30057       root    6w      REG              253,0           0     789548 /var/log/nginx/error.log (deleted)
    nginx     30058   www-data    2w      REG              253,0           0     789548 /var/log/nginx/error.log (deleted)
    nginx     30058   www-data    5w      REG              253,0 37730323404     268273 /etc/nginx/off (deleted)
    nginx     30058   www-data    6w      REG              253,0           0     789548 /var/log/nginx/error.log (deleted)
    nginx     30059   www-data    2w      REG              253,0           0     789548 /var/log/nginx/error.log (deleted)
    nginx     30059   www-data    5w      REG              253,0 37730323404     268273 /etc/nginx/off (deleted)
    nginx     30059   www-data    6w      REG              253,0           0     789548 /var/log/nginx/error.log (deleted)
WinEunuuchs2Unix
  • 1,801
  • 1
  • 17
  • 34
Love2Code
  • 898
  • 1
  • 7
  • 13
  • 1
    `/proc` should be a virtual filesystem afaik? You shouldn't get any actual diskspace back if you delete something there... Run a `df -h` to see actual used diskspace. – Wrikken Jan 16 '14 at 19:17
  • @Wrikken I have updated the post, theres 755 mb left. – Love2Code Jan 16 '14 at 19:34
  • Yep, seems like a problem, but not fixed with deleting something in `proc` (see the output of `mount`, it's just `procfs`). It's also a lot smaller then the 127TB you claim to have in `kcore`. There is a bit of cleanup to be done it seems, but not in `/proc`. I usually drill down from the root with `du -shx *`, see what the large directories are, and step further into those with another `du -shx *`, etc, to find the _real_ source. BTW: after a DDOS, it may not be a bad idea to rotate your logs away which could be filled to the brim with nonsense by running `logrotate -f /etc/logrotate.conf ` – Wrikken Jan 16 '14 at 19:42
  • @Wrikken i've updated the post again with the du -shx results, all folders seem to have a normal size, it only gives an error on the proc folders. I have pasted logrotate -f /etc/logrotate.conf in SSH but still have the same amount of mb's available. – Love2Code Jan 16 '14 at 19:55
  • Hm, well, the error in there is not important (just a process that ended between being discovered & checking its size). But that seems quite normal indeed.. What happens if you run it with `du -shx --apparent-size`? It may be sparse files... On a side note: I just noticed the file size of `/proc/kcore` in my Ubuntu install is... 140737486262272.. So, nothing to worry about, at least not _that_ one (officially, the file should be total amount of physical RAM + 4KB, but it seems my `man proc` documentation is lagging somewhwat. – Wrikken Jan 16 '14 at 20:06
  • @Rikken: du -shx --apparent-size returns 1.3G . – Love2Code Jan 16 '14 at 20:07
  • What is the type of the / filesystem? Also, have you looked for . (hidden) files in the root directory? – Chris J. Kiick Jan 16 '14 at 20:12
  • 4
    OK, that would mean there are a lot of actually deleted files, which are still not purged from the filesystem becuase some process keeps them open (their inodes still exist / are not deallocated yet). Could you have a look at `lsof | grep deleted` ? It will tell you which deleted files still exist, and which process id still has references to it. Usually, stopping or restarting that process will clean up the inodes. – Wrikken Jan 16 '14 at 20:15
  • @ChrisJ.Kiick how do I check the / filesystem? I'm not really great with servers, mostly i check guides on google lol. – Love2Code Jan 16 '14 at 20:17
  • @ChrisJ.Kiick: the `du -shx` (so without the `*`) Codemunkie has run doesn't care about whether files are hidden or not, it will still count them. – Wrikken Jan 16 '14 at 20:18
  • @Wrikken I have updated the post with the results and restarted nginx and mysql, which seemed to do the job. Thank you very much for your help. – Love2Code Jan 16 '14 at 20:22
  • Assuming I sufficiently answered your question, any chance you could mark my answer as accepted? TIA! – wally Oct 20 '16 at 14:44
  • 3
    I know this is a bit old, but one solution to tackle huge `/proc/kcore` is to restart the machine, which immediately reduce the size of the "file" to a much smaller size. – Raptor Aug 03 '18 at 02:15

4 Answers4

91

In answer to your original question:

"Is it safe to delete the /proc/kcore file? Or is there a solution on getting it to an normal size."

No, it's not safe. Well, I wouldn't like to bet what would happen if you deleted it anyway!

The /proc directory is the mount point for procfs (run mount and see the output like below: )

proc on /proc type proc (rw)

procfs is a bit of dark magic; no files in it are real. It looks like a filesystem, acts like a filesystem, and is a filesystem. But not one that is stored on disk (or elsewhere).

/proc/kcore specifically is a file which maps directly to every available byte in your virtual memory ... I'm not absolutely clear on the details; the 128TB comes from Linux allocating 47ish bits of the 64bits available for virtual memory.

(There's discussion on the 128TB limit here: https://unix.stackexchange.com/questions/116640/what-is-maximum-ram-supportable-by-linux )

Anyway, putting aside Linux's hard-coded virtual memory limits - what we come to understand in the context of your question is this: /proc/kcore is a system file, provided by the virtual procfs filesystem, and is not a real file.

Don't delete it ;-)


Update: 2016-06-03

My answer here keeps periodically being up-voted - so I assume people are still looking for an explanation of what /proc/kcore is.

There's a helpful Wikipedia article titled Everything is a file which gives a little background. If you're really curious - take a look into the Plan9 OS.

Hopefully my original answer sufficiently explains kcore itself. I'm speculating that people reading this answer may be curious about other files in /proc too - so here are some other "interesting" examples.

  • /proc/sys/* is a mechanism for the user (you) to read/write details from the heart of Linux (the kernel and associated drivers etc). A cute example of a r/w item is "IP forwarding":

    Read: cat /proc/sys/net/ipv4/ip_forward (0 is off, 1 is on)

    Write: echo 1 > /proc/sys/net/ipv4/ip_forward

    As with kcore, this isn't a real file. But it acts like one. So when you write to it, you're actually changing software settings as opposed to bytes on a disk.

  • /proc/meminfo and /proc/cpuinfo are read-only. You can cat or less them, or fopen() from your own application. They show you details about your hardware (memory and CPU).

  • /proc/[0-9]+ are actually process IDs running on your machine! These are (IMHO) by far the coolest feature of /proc. Inside them you will find more fake files like cmdline which tell you what command was used to start the process.

Finally there's some other examples of "interesting filesystems", like /proc. There are purely in-memory and "user-space" to name just two. Again these (generally speaking) do not consume any real disk space, although tools like df and ls may report real file sizes.

tgogos
  • 23,218
  • 20
  • 96
  • 128
wally
  • 3,492
  • 25
  • 31
8

It's completely safe to run the command sudo rm /proc/kcore. It will just say rm: cannot remove '/proc/kcore': Operation not permitted.

All the files in /proc do not actually exist on your hard drive, so they can't be removed. Those files represent information about the system. For example, when you do ls /proc, you're asking the kernel for a list of the processes on the system. If you run ls -l /proc/22/exe, you're asking the kernel for the file path of the executable of process number 22. And so on.

tbodt
  • 16,609
  • 6
  • 58
  • 83
3

Please check your log file's space. I removed all error log and access log files and my Website is running.

Use this command to check which folder is taking more space:

cd /
sudo du -sh * 2>/dev/null | sort -h
Skatox
  • 4,237
  • 12
  • 42
  • 47
Dinesh Gurjar
  • 498
  • 5
  • 17
0

Looks like you need to clean up the disk of files that are deleted but are reserved. You can use the 'tune2fs' command with something like:

tune2fs -m 1 /dev/<drive>

This should free up the reserved block space and give you access to the privileged processes reserved disk space. Note that 1 is the percentage that will be allocated to the privileged processes afterwards, do this only if you have enough disk space for critical processes such as syslog, or ssh.

NOTE: You will never gain disk space by removing files from '/proc'. That is a virtual filesystem that has nothing whatsoever to do with space on your HDD.

Waheed
  • 608
  • 1
  • 5
  • 20
Atari911
  • 183
  • 1
  • 6
  • 1
    The explanation about /proc is correct. I am not familiar with tune2fs; can someone explain what it does (and what's wrong with this answer, if anything)? – Tom Nov 01 '15 at 00:59
  • I can tell you that the reason I posted this answer was because it solved the same problem for me as what I perceived you to have. Not sure why it was down voted but if it solved your issue then that is great... Since the down-vote didn't give a reason, perhaps you could reinforce the answer with an affirmation to whether this was an answer that was useful to you. – Atari911 Nov 03 '15 at 04:46
  • I'm not the OP, nor did I have the same issue, just got here by chance, so I cannot reinforce the answer - I can only say that it seems reasonable to me and that it would be nice if the downvoter had left a comment. Other than that I'm just curious as to what `tune2fs` does. – Tom Nov 03 '15 at 13:56