command syntax for the find command

[Andrew Kaplan]

Hi there --

I am writing a script that will go through the filesystem of our server, and search for core files. The output of the search will be saved to an output file, which, in turn, will be e-mailed to the administrator.

The find command is what I was planning on using to do the search. What would the correct syntax be in order to have all occurrences of 'core' be listed in the output file? Thanks.

[Pete Randall]

In it's simplest form:

find / -type f -name core


Pete

[Andrew Kaplan]

Hi Pete --

Thanks for your reply. I entered the command syntax that you suggested, but there were no listings in the file after it ran. I know there are several core files on the server, so I might need to have the command be more specific. Any suggestions? Thanks.

[James R. Ferguson]

Hi Andrew:

#!/usr/bin/sh
MYLOG=/var/tmp/corefilelist
find /path -xdev -type f -name core -exec ls -l {} + > ${MYLOG}
# [ -s "${MYLOG}" ] && mailx root -s "Core Files" < ${MYLOG}

...

This will look for files named "core" in the '/path' or paths you list. The '-xdev' option prevents crossing mountpoints. Rathter than searching the whole filesystem (with '/') it is better to specify the directories you want to search. You can do:

# find /path1 /path2 /path3 ...

The '-exec ls -l {} +' tells 'find()' to execute the 'ls -l' command using the 'find' output. The '+' terminator causes as many arguments as possible to be bundled together for each instantiation of the 'ls' command. This is very efficient.

The output is written to a file. If the file exists and is not empty, an email message is generated and the file (list) mailed.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Andrew:

> there were no listings in the file after it ran. I know there are several core files on the server, so I might need to have the command be more specific.

Please give an example of these. If you are running 11.31 then you should evaluate your 'coreadm' parameters.

If you have appended a pid to the core file, we could do:

# find /path -xdev -type f -name core -o -name "core.[0-9][0-9]*" -exec ls -l {} +

...which finds both "core" and files named "core.12" but skips files like '/usr/share/man/man4.Z/core.4' (which you might want).

Regards!

...JRF...

[Andrew Kaplan]

Hi James --

Thanks for your reply. Your script, and explanations about it, are really helpful. The only comment I have is an explanation as to why I wanted to do the search from the / filesystem.

My thinking is this: Since I don't know where the core files would be generated, a blanket search of the entire filesystem would cover all possible areas. While this would take longer to complete, running the script during off-hours would, in theory, alleviate that concern.

What do you think?

[Bill Hassell]

Here's the basic answer:

find / -name core > /var/tmp/mycorefilelisting

Then mailx the file to the sysadamin.

But there are bigger questions:

Are these core files unexpected? Do you have developers that need these files to debug their applications? Do you know what program caused the core file?

For the last question, change the above find command to:

find / -name core -exec file {} \; > /var/tmp/mycorefilelisting

Now you have the full name of the core file and also the name of the process that crashed and created the core file. This is much more useful.

And finally, you can disable core file creation completely by adding this line to /etc/profile:

ulimit -Sc 0

Now, every time a user logs in, if a process crashes, no core file will be created. However, developers may need a core file to debug an application so developers will add: ulimit unlimited to .profile in their $HOME directories.

[Pete Randall]

Andrew,

As Jim suggested, can you give us an example of one of these core files that you know are there? The only reason the command I gave you wouldn't find them would be if the name of the file was not literally "core".


Pete

[James R. Ferguson]

Hi (again) Andrew:

> My thinking is this: Since I don't know where the core files would be generated, a blanket search of the entire filesystem would cover all possible areas. While this would take longer to complete, running the script during off-hours would, in theory, alleviate that concern.

Yes, that would be acceptable ( to drop the '-xdev' option and search '/' ) as you noted.

If you _know_ that user programs aren't going to run in filesystems like '/tmp', '/var', etc. then why search these filesystems(?).

Regards!

...JRF...