Cron and log file cleanup 7

[stewm]

I introduced a new log file approach for an application that gets run in Solaris.

It basically is just an historical view of logs for a process that gets run weekly. Each log file has a timestamp embedded in the file name.

I wanted to create a cron job to delete files older then 2 months. I'm not sure how cron works or how to script this.

Any suggestions?

Thanks,

Mark Stewart
Senior Analyst
Consultants Club Corp.
Windsor, Ontario
Canada

http://www.consultantsclub.biz

 

[PHV]

man find

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[stewm]

Thanks PHV, but if I wanted to read man pages I wouldn't have submitted the question.

Mark Stewart
Senior Analyst
Consultants Club Corp.
Windsor, Ontario
Canada

http://www.consultantsclub.biz

 

[vgersh99]

I gather you do not want to read, so you submitted a question?

vlad
+----------------------------+
| #include<disclaimer.h> |
+----------------------------+

 

[Chacalinc]

ok men, everybody calm down...

stewm: what PHV tryed to tell you is you need to use the [tt]find[/tt] command with [tt]-mtime[/tt] or [tt]-ctime[/tt] option (don't remember exaclty) pls the [tt]-exec[/tt] option in order to [tt]find /path/to/logs[/tt] all files older (mtime or ctime) than say 14 days and [tt]-exec rm[/tt] to that found files.

As you can see it is only one command, so you can edit your crontab ([tt]crontab -e[/tt]) in order to add this [tt]find[/tt] command in the cron.

Cheers.

Personal Note: I know that it is quite confortable to put a questions here instead to read the manual or man pages, but -pls- read at least the man pages before to put a questions, you will get more knowlegde than geting a simple answer.

 

[KenCunningham]

Personal Note: I know that it is quite confortable to put a questions here instead to read the manual or man pages, but -pls- read at least the man pages before to put a questions, you will get more knowlegde than getting a simple answer.[/quote chacalinc]

Particularly if one has aspirations to the title 'Senior Analyst' ;-)

 

[chipperMDW]

if I wanted to read man pages I wouldn't have submitted the question

You don't have to read man pages. With PHV's help, you now have a specific man page to read.

Your remark makes it seem like you can't be bothered to look anything up, even when someone narrows down your reading significantly. When people think that's your attitute, it tends to annoy them.

Most people don't want to play fetch from manual pages just because you don't feel like doing it. Instead, they usually refer you to a specific page or section that should get you started. If you have questions after that, you can still ask them.


Man pages know much more than we do... or at least more than we're likely to be willing to write. You can also read them much faster than you can ask a question and get a response. They can, however, be a bit dense when you're looking for something specific, so skimming is a useful skill to acquire when dealing with them.

If you absolutely can't find anything in a man page, try looking for the equivalent GNU Texinfo Manual. If you don't have one on your system, they're usually available online as HTML, and they tend to be written in a format that's meant to be readable, while man pages are written in a format meant to squeeze in information. This might be a good idea if you don't like the [tt]find[/tt] man page, which is admittedly a bit long.


You mentioned not knowing how to use cron. The most useful files to read can be viewed by running

[tt]man crontab[/tt]

and

[tt]man 5 crontab[/tt]

The former describes how to update per-user crontab files ("cron jobs"), and the latter describes the format of a crontab file.

 

[KenCunningham]

If it's of any use, I find it helpful to put the following aide-memoir at the top of each of my crontabs:

#Crontab field order:
#minute (0-59),
#| hour (0-23),
#| | day of the month (1-31),
#| | | month of the year (1-12),
#| | | | day of the week (0-6 with 0=Sunday).
#| | | | | commands

(Note each line is commented out).

This assists me in recalling the exact field order, and their contents even when (as happens to us all occasionally), the brain freezes over.

 

[stewm]

Thanks for the quick replys folks. I have to get a pile of newly upgraded multidimenional OLAP Cubes out there running against the newly upgraded 9i database. With the help of the unix admin he and were able to find I quick solution so I could continue to meet deadlines.

Mark Stewart
Senior Analyst
Consultants Club Corp.
Windsor, Ontario
Canada

http://www.consultantsclub.biz

 

[hfaix]

find / -mtime +60 -exec rm {} \; (I didn't test this)

I'd probably try :

find / -mtime +60 -exec ls -ld {} \;

 

[KenCunningham]

Whoa!!! Just to add to hfaix's warning, DON'T RUN find / -mtime +60 -exec rm {} \;

This will delete any file under root (ie all files) that hasn't been modified for 60 days, which you will probably find includes most of your OS. It's safer to specify the starting directory specifically, eg

find <path to directory to be searched> -mtime +60 -exec ls {} \;

(as hfaix points out) to get a listing of affected files before trying it with an rm.

As someone pointed out in these fora before, "think twice, press return once.

 

[hfaix]

"think twice, press return once."

I like that.