core files

sulekha


recently i read in a book delete all core files with rm because they are a waste of space.
when i searched for core files as follows:-

find / -name core

find: /etc/lvm/archive: Permission denied
find: /etc/lvm/backup: Permission denied
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
find: /etc/firestarter/inbound: Permission denied
find: /etc/firestarter/outbound: Permission denied
find: /var/lib/cups/certs: Permission denied
find: /var/lib/gdm: Permission denied
find: /var/lib/slocate: Permission denied
find: /var/lib/fetchmail: Permission denied
find: /var/cache/setup-tool-backends/debug: Permission denied
find: /var/cache/setup-tool-backends/backup: Permission denied
find: /var/lock/lvm: Permission denied
find: /var/log/squid: Permission denied
find: /var/run/sudo: Permission denied
find: /var/spool/cron/crontabs: Permission denied


macemoneta


Quote:
there is quite a large no: of core files,from this listing how will i know which are the files to be deleted??? I don't think all these files are created as a result of program crash.

First, there were only 12 'core' files. None of them were files you should delete. Most distributions these days disable the creation of core files so there shouldn't be any unless you specifically enable them.

code

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
max nice (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 8185
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
max rt priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 8185
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited


If you want to search the entire system, you need to do that as root. That's why you received the "permission denied" messages; as a user you don't have access to those directories.

wjevans_71

Actually, there isn't much evidence of core files there.

The "permission denied" messages are telling you that you don't have the rights to look in the named directory to check for core files or for anything else. Run the find command as root, and you'll get rid of these messages.

The other lines are most likely special case files which are not core dumps, and should be left alone.

jerrill

From what I understand a core dump happens when the kernel has a significant fault, usually causing the computer to crash. When you reboot, the file would be in your home directory.


bouncer

Quote:
From what I understand a core dump happens when the kernel has a significant fault, usually causing the computer to crash. When you reboot, the file would be in your home directory.
Any app can create a core file when it crashes.

Using (s)locate is faster than find, provided that you have upgraded your (s)locate database (updatedb as root, locate as regular user):
Code:

updatedb

then find
Code:

locate core

anyway like said, you should not have core files there.

As a sidenote, when posting, don't post that excessive outputs. If you need to post an output from some program, cut it and paste only the important parts (we don't need those lines that say you don't have permissions into some directory in this case).



sulekha

I searched for core files in my home directory. i didn't find any.

can any one give features/properties of core files so that i can quickly find them using find command.??

macemoneta

They are named 'core'. If they are from an application that you ran, they will be in your home directory. Did you run the ulimit command above? Are core files even enabled on your system?


wjevans_71

Quoth jerril:
Quote:
From what I understand a core dump happens when the kernel has a significant fault, usually causing the computer to crash.
A core dump (in the current context) happens when the kernel has found a significant fault in a running program, always causing the program to stop running. The system as a whole keeps running merrily.

And.

Quoth jerril:
Quote:
the file would be in your home directory
Quoth macemoneta:
Quote:
If they are from an application that you ran, they will be in your home directory.


No, guys. When an application dies and leaves a core file, it is in whatever directory was the process's current directory when the application died, which is usually the process's current directory when the application started, but not necessarily the user's home directory.

macemoneta

Unless a user is root, the home directory and /tmp are the only directories that a user (normally) has write access to. A core file will not be created in a directory that the user process cannot write to.


wjevans_71

Quoth the highly esteemed macemoneta:
Quote:
A core file will not be created in a directory that the user process cannot write to.
Quite correct, as far as it goes. But the following is a bit shy of the mark:
Quote:
Unless a user is root, the home directory and /tmp are the only directories that a user (normally) has write access to.

Most developers I know, and most others I know who are not developers, will not keep their files directly in their home directories, but will create subdirectories so their files are a bit more organized. This provides far more directories than the two you mentioned. If any one of them is the current working directory, that is where any core file will go.



jiliagre


Quote:
Originally Posted by macemoneta
Unless a user is root, the home directory and /tmp are the only directories that a user (normally) has write access to.
Actually quite a few more can be found under /var (/var/tmp, /var/preserve, /var/mail, /var/spool/.../, ...)
Quote:
A core file will not be created in a directory that the user process cannot write to.
Correct. However don't forget a process may have higher privileges that the user who launched it if its suid and/or sgid bits are set. The user won't be able to remove a core file created under that situation though.