Kcore занимает весь диск
После того, как вы столкнулись с DDOS-атакой, как-то /proc/kcore очень сильно, я использую небольшой класс php для проверки текущего дискового пространства и количества используемых.
Мой вопрос: безопасно ли удалить файл /proc/kcore ? Или есть решение по его нормальному размеру.
Размер файла /proc/kcore равен 140.737.486.266.368 байт
Я разместил свой сервер на DigitalOcean.
Если вам нужна дополнительная информация, пожалуйста, спросите;)
df -h возвращает:
du -shx возвращает:
Результаты lsof | grep deleted :
В ответ на ваш оригинальный вопрос:
“Сохраняется ли удаление файла /proc/kcore ? Или есть решение? на получение его до нормального размера.”
Нет, это не безопасно. Ну, я не хотел бы делать ставки, что бы произошло, если бы вы все равно удалили его!
Каталог /proc – это точка монтирования для procfs (запустите mount и посмотрите вывод, как показано ниже:)
procfs – это немного темной магии; никакие файлы в нем не являются реальными. Он выглядит как файловая система, действует как файловая система и является файловой системой. Но не тот, который хранится на диске (или в другом месте).
/proc/kcore В частности, это файл, который отображается непосредственно на каждый доступный байт в вашей виртуальной памяти… Я не совсем понимаю подробности; 128TB поставляется из Linux, выделяющего 47 бит бит из 64 бит, доступных для виртуальной памяти.
В любом случае, откладывая ограничения Linux на жестком диске Linux, мы понимаем в контексте вашего вопроса следующее: /proc/kcore – это системный файл, предоставляемый файловой системой виртуальных файлов procfs, и не является реальным файлом.
Обновление: 2016-06-03
Мой ответ здесь периодически повторяется, поэтому я предполагаю, что люди все еще ищут объяснение того, что /proc/kcore .
Там есть полезная статья в Википедии под названием Все это файл, который дает немного фона. Если вам действительно интересно – загляните в Plan9 OS.
Надеюсь, мой оригинальный ответ достаточно объясняет сам kcore . Я предполагаю, что людям, читающим этот ответ, может быть интересно узнать о других файлах в /proc тоже – вот некоторые другие “интересные” примеры.
/proc/sys/* – это механизм для пользователя (вас) для чтения/записи деталей из ядра Linux (ядро и связанные с ним драйверы и т.д.). Симпатичным примером элемента r/w является “ пересылка IP“:
Чтение: cat /proc/sys/net/ipv4/ip_forward ( 0 выключено, 1 включено)
Пишите: echo 1 > /proc/sys/net/ipv4/ip_forward
Как и в случае с kcore , это не настоящий файл. Но он действует как один. Поэтому, когда вы пишете на него, вы фактически меняете настройки программного обеспечения, а не байты на диске.
/proc/meminfo и /proc/cpuinfo доступны только для чтения. Вы можете cat или less их, или fopen() из своего собственного приложения. Они показывают вам детали вашего оборудования (память и процессор).
/proc/1+ – это фактически идентификаторы процессов на вашем компьютере! Это (IMHO), безусловно, самая крутая особенность /proc . Внутри них вы найдете больше поддельных файлов, таких как cmdline , которые расскажут вам, какая команда была использована для запуска процесса.
Наконец, есть еще несколько примеров “интересных файловых систем”, например /proc . Есть чисто в памяти и “user-space” чтобы назвать только два. Опять же, эти (вообще говоря) не потребляют никакого реального дискового пространства, хотя такие инструменты, как df и ls , могут сообщать о реальных размерах файлов.
Полностью безопасно запускать команду sudo rm/proc/kcore . Он просто скажет rm: cannot remove '/proc/kcore': Operation not permitted .
Все файлы в /proc самом деле не существуют на вашем жестком диске, поэтому их нельзя удалить. Эти файлы представляют информацию о системе. Например, когда вы выполняете ls/proc , вы запрашиваете ядро для списка процессов в системе. Если вы запустите ls -l/proc/22/exe , вы запрашиваете ядро путь к файлу исполняемого файла процесса 22. И так далее.
Похоже, вам нужно очистить диск от файлов, которые удалены, но зарезервированы. Вы можете использовать команду ‘tune2fs’ с чем-то вроде:
Это должно освободить зарезервированное пространство блока и предоставить вам доступ к зарезервированному дисковому пространству привилегированных процессов. Обратите внимание, что 1 – это процент, который впоследствии будет выделен привилегированным процессам, делайте это только в том случае, если у вас достаточно дискового пространства для критических процессов, таких как syslog или ssh.
ПРИМЕЧАНИЕ. Вы никогда не получите свободного места на диске, удалив файлы из /proc. Это виртуальная файловая система, которая не имеет ничего общего с пространством на жестком диске.
пожалуйста, проверьте ваше пространство файла журнала. Я удалил все журналы ошибок и получил доступ к файлам журналов, и мой сайт работает.
Используйте эту команду, чтобы проверить, какая папка занимает больше места.
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:
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 ;)
Results of lsof | grep deleted :
/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.
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
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.
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.
1 Answer 1
/dev/kmem gives access to the kernel's virtual memory space, and /dev/mem gives access to physical memory.
/proc/kcore is a pseudofile in ELF core format, of the kernel's virtual memory space. You should be able to examine it with standard ELF utilities, like objdump and gdb - although you will likely better off to make a regular file copy of it and work on that.
@user567879: The virtual memory address space corresponds to the addresses as seen by the program in question (in this case, the kernel). The physical memory address space corresponds to the actual memory addresses that are placed on the system bus. The MMU within the CPU translates virtual addresses into physical addresses.
@caf Kernel virtual memory does not really make sense. Virtual memory is relative to a process, and the kernel is not a process. In fact, every process' virtual memory contain the same kernel part on top (higher addresses), which is only accessible after a switch in kernel context. /proc/kcore is the physical memory.
@ysomane: I would argue that it does make sense - as you point out the 'kernel' part of every process's page tables is the same, and is only accessible in kernel mode. Those are the addresses "seen" by the kernel - the addresses of kernel objects are virtual addresses in that constant kernel part of the address space. /proc/kcore covers the kernel virtual address space region, not physical memory - though depending on kernel configuration this might well include a mapping of all physical memory.
@caf You're right on this, my point was in reply to your first comment, which sounds like you considered the kernel as some process. The kernel virtual memory may be considered as the kernel part of the current process's virtual space. What would be odd may be to talk about the kernel 's virtual memory. For the other point, every documentation I saw talk about physical memory for /proc/kcore .
После того, как испытал DDOS-атаку, как-то /proc/kcore очень большой, я использую небольшой класс php, чтобы проверить текущее дисковое пространство и сколько было использовано.
Он показывает следующее:
У меня вопрос, безопасно ли удалить /proc/kcore файл? Или есть решение довести его до нормального размера.
Размер файла /proc/kcore составляет 140.737.486.266.368 байт.
Я разместил свой сервер в DigitalOcean.
Если вам нужна дополнительная информация, спрашивайте;)
df -h возвращает:
du -shx возвращает:
Результаты lsof | grep deleted :
/proc должна быть виртуальная файловая система афаик? Вы не должны получить обратно какое-либо фактическое дисковое пространство, если что-то там удалите . Запустите a, df -h чтобы увидеть фактическое использованное дисковое пространство.
Хорошо, это будет означать, что есть много фактически удаленных файлов, которые все еще не удалены из файловой системы, потому что какой-то процесс держит их открытыми (их inodes все еще существуют / еще не освобождены). Не могли бы вы взглянуть lsof | grep deleted ? Он сообщит вам, какие удаленные файлы все еще существуют, и какой идентификатор процесса все еще ссылается на него. Обычно остановка или перезапуск этого процесса очищает inodes.
В ответ на ваш исходный вопрос:
"Is it safe to delete the /proc/kcore file? Or is there a solution on getting it to an normal size."
Нет, это небезопасно. Что ж, я бы не хотел спорить, что произойдет, если вы все равно удалите его!
/proc Каталог является точкой для PROCFS монтирования (бег mount и увидеть результат , как показано ниже:)
procfs - это немного темной магии; в нем нет файлов настоящих. Он выглядит как файловая система, действует как файловая система и является файловой системой. Но не тот, что хранится на диске (или где-то еще).
/proc/kcore в частности, это файл, который отображается непосредственно на каждый доступный байт в вашей виртуальной памяти . Я не совсем понимаю детали; 128 ТБ поступает из Linux, в котором 47 бит из 64 битов, доступных для виртуальной памяти.
В любом случае, если отбросить жестко заданные ограничения виртуальной памяти Linux - в контексте вашего вопроса мы пришли к пониманию следующего: /proc/kcore это системный файл, предоставляемый виртуальной файловой системой procfs, а не реальный файл.
Не удаляйте его ;-)
Обновление: 2016-06-03
Мой ответ здесь периодически получает одобрение - поэтому я предполагаю, что люди все еще ищут объяснения того, что /proc/kcore есть.
В Википедии есть полезная статья под названием « Все - это файл», в котором дается небольшая подоплека. Если вам действительно интересно - загляните в ОС Plan9.
Надеюсь, мой первоначальный ответ достаточно объясняет kcore сам себя. Я предполагаю, что людям, читающим этот ответ, могут быть любопытны и другие файлы /proc - так что вот еще несколько «интересных» примеров.
/proc/sys/* - это механизм, с помощью которого пользователь (вы) может читать / записывать данные из самого сердца Linux (ядра и связанных драйверов и т. д.). Симпатичный пример элемента ar / w - " IP forwarding ":
Чтение: cat /proc/sys/net/ipv4/ip_forward ( 0 выключено, 1 включено)
Напишите: echo 1 > /proc/sys/net/ipv4/ip_forward
Как и в случае kcore , это не настоящий файл. Но действует как единое целое. Поэтому, когда вы пишете в него, вы фактически меняете настройки программного обеспечения, а не байты на диске.
/proc/meminfo и /proc/cpuinfo доступны только для чтения. Можно cat либо less их, либо fopen() из собственного приложения. Они показывают вам подробную информацию о вашем оборудовании (памяти и ЦП).
/proc/3+ на самом деле являются идентификаторами процессов, запущенных на вашем компьютере! Это (ИМХО), безусловно, самая крутая особенность /proc . Внутри них вы найдете больше фальшивых файлов, например, cmdline которые сообщают вам, какая команда была использована для запуска процесса.
Наконец, есть еще несколько примеров «интересных файловых систем», например /proc . Есть только в памяти и "пользовательское пространство", чтобы назвать только два. Опять же, они (вообще говоря) не занимают реального дискового пространства, хотя такие инструменты, как df и ls могут сообщать реальные размеры файлов.
После того, как испытал DDOS-атаку, как-то /proc/kcore очень большой, я использую небольшой класс php, чтобы проверить текущее дисковое пространство и сколько было использовано.
Он показывает следующее:
У меня вопрос, безопасно ли удалить /proc/kcore файл? Или есть решение довести его до нормального размера.
Размер файла /proc/kcore составляет 140.737.486.266.368 байт.
Я разместил свой сервер в DigitalOcean.
Если вам нужна дополнительная информация, спрашивайте;)
df -h возвращает:
du -shx возвращает:
Результаты lsof | grep deleted :
/proc должна быть виртуальная файловая система афаик? Вы не должны получить обратно какое-либо фактическое дисковое пространство, если что-то там удалите . Запустите a, df -h чтобы увидеть фактическое использованное дисковое пространство.
Хорошо, это будет означать, что есть много фактически удаленных файлов, которые все еще не удалены из файловой системы, потому что какой-то процесс держит их открытыми (их inodes все еще существуют / еще не освобождены). Не могли бы вы взглянуть lsof | grep deleted ? Он сообщит вам, какие удаленные файлы все еще существуют, и какой идентификатор процесса все еще ссылается на него. Обычно остановка или перезапуск этого процесса очищает inodes.
В ответ на ваш исходный вопрос:
"Is it safe to delete the /proc/kcore file? Or is there a solution on getting it to an normal size."
Нет, это небезопасно. Что ж, я бы не хотел спорить, что произойдет, если вы все равно удалите его!
/proc Каталог является точкой для PROCFS монтирования (бег mount и увидеть результат , как показано ниже:)
procfs - это немного темной магии; в нем нет файлов настоящих. Он выглядит как файловая система, действует как файловая система и является файловой системой. Но не тот, что хранится на диске (или где-то еще).
/proc/kcore в частности, это файл, который отображается непосредственно на каждый доступный байт в вашей виртуальной памяти . Я не совсем понимаю детали; 128 ТБ поступает из Linux, в котором 47 бит из 64 битов, доступных для виртуальной памяти.
В любом случае, если отбросить жестко заданные ограничения виртуальной памяти Linux - в контексте вашего вопроса мы пришли к пониманию следующего: /proc/kcore это системный файл, предоставляемый виртуальной файловой системой procfs, а не реальный файл.
Не удаляйте его ;-)
Обновление: 2016-06-03
Мой ответ здесь периодически получает одобрение - поэтому я предполагаю, что люди все еще ищут объяснения того, что /proc/kcore есть.
В Википедии есть полезная статья под названием « Все - это файл», в котором дается небольшая подоплека. Если вам действительно интересно - загляните в ОС Plan9.
Надеюсь, мой первоначальный ответ достаточно объясняет kcore сам себя. Я предполагаю, что людям, читающим этот ответ, могут быть любопытны и другие файлы /proc - так что вот еще несколько «интересных» примеров.
/proc/sys/* - это механизм, с помощью которого пользователь (вы) может читать / записывать данные из самого сердца Linux (ядра и связанных драйверов и т. д.). Симпатичный пример элемента ar / w - " IP forwarding ":
Чтение: cat /proc/sys/net/ipv4/ip_forward ( 0 выключено, 1 включено)
Напишите: echo 1 > /proc/sys/net/ipv4/ip_forward
Как и в случае kcore , это не настоящий файл. Но действует как единое целое. Поэтому, когда вы пишете в него, вы фактически меняете настройки программного обеспечения, а не байты на диске.
/proc/meminfo и /proc/cpuinfo доступны только для чтения. Можно cat либо less их, либо fopen() из собственного приложения. Они показывают вам подробную информацию о вашем оборудовании (памяти и ЦП).
/proc/6+ на самом деле являются идентификаторами процессов, запущенных на вашем компьютере! Это (ИМХО), безусловно, самая крутая особенность /proc . Внутри них вы найдете больше фальшивых файлов, например, cmdline которые сообщают вам, какая команда была использована для запуска процесса.
Наконец, есть еще несколько примеров «интересных файловых систем», например /proc . Есть только в памяти и "пользовательское пространство", чтобы назвать только два. Опять же, они (вообще говоря) не занимают реального дискового пространства, хотя такие инструменты, как df и ls могут сообщать реальные размеры файлов.
4 Answers 4
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: )
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.
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.
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/7+ 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.
What is the difference between /dev/mem , /dev/kmem and /proc/kcore ?
Can I disassemble its contents using tools like objdump and gdb ?
Читайте также: