A Solaris 8 (Bourne Shell) Scripting question, regarding a log rotation script

A Solaris 8 (Bourne Shell) Scripting question, regarding a log rotation script

Post by Matt Clayt » Mon, 07 Oct 2002 02:06:37



I've inherited a script which I'm supposed to use to rotate all logs
that are kept on the unix system, which aren't rotated automatically
by any other method.

The idea is to run the script from cron, using the synatx and usage
details shown below.

The program isn't working as expected... it's producing more files
than it should and doesn't seem to handle "^M" characters properly.

Also the script seems to be long winded in what it's trying to
achieve.

I haven't scripted anything substantial for quite sometime and
wondered what you experts thought of the program and if anyone has any
suggestions on what I can change to (a) make it work correctly and (b)
improve the coding!

My only constraint is that it must be written as a shell script and
not in perl and that it must work on Sun Solaris 8!

Any help will be gratefully received and I'll reciprocate by helping
answer some questions in any other areas of unix!

The details of the script are below.

Many thanks,

Matt Clayton.
Sun Solaris 8 SysAd

-------------------------------------------------------------------------------
Log rotation script usage
#/usr/local/util/log_rotate.sh FULL_PATH_NAME_OF_LOG roll |  trim
NUMBER_OF_LOGS_TO_ARCHIVE

Where;
FULL_PATH_NAME_OF_LOG= The explicit path name and file name of the
logs to be rotated.
roll | trim = option of rolling the logs, a new log is created for
each log and all other logs are rolled by increasing the extension id
of each file. T* of logs does not roll the logs but takes the
last 500 lines or part there of, and discards all other lines previous
to that point. These options (roll or trim) are mutually exclusive.
NUMBER_OF_LOGS_TO_ARCHIVE=the number of days to retain online. All
files after this number of files are deleted. Note; if you run this
script multiple times in a day, it is the total number of files on
line not the number of days to be retained.

NOTE: The script must be executed as a user of applicable privileges
to use the script correctly. Ie; you must have the privileges to
modify the file as you would on the CLI. No NUMBER_OF_LOGS_TO_ARCHIVE
argument is required when t* logs.

--------------------------------------------------------------------------------

The existing script is shown in full below:

#!/bin/sh
###  Author: Mike McLaughlin
### Purpose: To roll any given log and not interupt the application
### Usage: log_rotate.sh FULL_PATH_FILENAME roll|trim  

LOG_TO_ROTATE=$1
COMPRESS="/usr/local/bin/gzip -f"
OPTION=$2
DAYS_TO_KEEP=$3

###check to see that is a ascii file and that it exists
[ -f ${LOG_TO_ROTATE} ] && /usr/bin/file ${LOG_TO_ROTATE} | egrep
'ascii|text' > /dev/null
STATUS=$?
case $STATUS in

0)
LOG_DIR=`dirname $1`
LOG_NAME=`basename $1`
;;

*)
echo "Could not roll file; \n"
[ ! -s ${LOG_TO_ROTATE} ] && echo "File is zero length." ; exit 1
[ ! -f ${LOG_TO_ROTATE} ] && echo "File does not exist." ; exit 1
[ $STATUS -gt 0 ] && echo "File does not exist" ; exit 1

exit 1
;;

esac

case ${OPTION} in

TRIM|trim)
/usr/bin/tail -500 ${LOG_TO_ROTATE} > /tmp/${LOG_NAME}
/usr/bin/cat /dev/null > ${LOG_TO_ROTATE}
/usr/bin/cat /tmp/${LOG_NAME} > ${LOG_TO_ROTATE}
/usr/bin/rm /tmp/${LOG_NAME}
;;

ROLL|roll)
##Each line is twice in case a lazy admin does not tidy up after
inspecting logs.
##Clean up oldest of logs;

[ -f ${LOG_TO_ROTATE}.${DAYS_TO_KEEP} ] && /usr/bin/rm -f
${LOG_TO_ROTATE}.${DAYS_TO_KEEP}
[ -f ${LOG_TO_ROTATE}.${DAYS_TO_KEEP}.gz ] && /usr/bin/rm -f
${LOG_TO_ROTATE}.${DAYS_TO_KEEP}.gz

##Set inital working values
WORKING_ID=${DAYS_TO_KEEP}
DAYS_KEPT=0
WORKING_DEC=${DAYS_TO_KEEP}
### Roll over the mass files
while [ ! ${DAYS_TO_KEEP} -lt ${DAYS_KEPT} ]
do
        ##Used only for flow control
        DAYS_KEPT=`expr ${DAYS_KEPT} + 1`
        ##Used for file naming
        WORKING_INC=${WORKING_DEC}
        WORKING_DEC=`expr ${WORKING_DEC} - 1`
        [ -f ${LOG_TO_ROTATE}.${WORKING_DEC} ] && ${COMPRESS}
${LOG_TO_ROTATE}.${WORKING_DEC}
        [ -f ${LOG_TO_ROTATE}.${WORKING_DEC}.gz ] && /usr/bin/mv
${LOG_TO_ROTATE}.${WORKING_DEC}.gz ${LOG_TO_ROTATE}.${WORKING_INC}.gz

done

[ -f ${LOG_TO_ROTATE} ] && cp -p ${LOG_TO_ROTATE} ${LOG_TO_ROTATE}.0
[ -f ${LOG_TO_ROTATE} ] && /usr/bin/cat /dev/null > ${LOG_TO_ROTATE}
;;
esac

 
 
 

A Solaris 8 (Bourne Shell) Scripting question, regarding a log rotation script

Post by /dev/nul » Mon, 07 Oct 2002 03:21:32



> I've inherited a script which I'm supposed to use to rotate all logs
> that are kept on the unix system, which aren't rotated automatically
> by any other method.

Rather than use your inherited script, just modify the Solaris
"newsyslog," script that lurks in root's crontab. Log rotation seldom
needs to be any more complex than that.

HTH.

 
 
 

A Solaris 8 (Bourne Shell) Scripting question, regarding a log rotation script

Post by Dan Logche » Mon, 07 Oct 2002 09:18:09




> > I've inherited a script which I'm supposed to use to rotate all logs
> > that are kept on the unix system, which aren't rotated automatically
> > by any other method.

> Rather than use your inherited script, just modify the Solaris
> "newsyslog," script that lurks in root's crontab. Log rotation seldom
> needs to be any more complex than that.

Oh I disagree.  I've been asked by developers to archive months of
logs.  It is sometimes necessary to rotate logs to dated filenames in
a seperate location.  I had to do this for a Netegrity server because
the logs were over 1GB a day, and they need to review logs some
times going back over 20-30 days.

--
Dan

 
 
 

A Solaris 8 (Bourne Shell) Scripting question, regarding a log rotation script

Post by /dev/nul » Mon, 07 Oct 2002 16:08:36



> Oh I disagree.  I've been asked by developers to archive months of
> logs.  It is sometimes necessary to rotate logs to dated filenames in
> a seperate location.  I had to do this for a Netegrity server because
> the logs were over 1GB a day, and they need to review logs some
> times going back over 20-30 days.


 > just modify the Solaris "newsyslog," script
        ^^^^^^

Hence my suggestion was that newsyslog could be modified accordingly. A
rotation of $LOG to $LOG.$MYDATE isn't particularly taxing :-)

 
 
 

A Solaris 8 (Bourne Shell) Scripting question, regarding a log rotation script

Post by Dan Logche » Mon, 07 Oct 2002 23:42:07




> > Oh I disagree.  I've been asked by developers to archive months of
> > logs.  It is sometimes necessary to rotate logs to dated filenames in
> > a seperate location.  I had to do this for a Netegrity server because
> > the logs were over 1GB a day, and they need to review logs some
> > times going back over 20-30 days.


>  > just modify the Solaris "newsyslog," script
>         ^^^^^^

> Hence my suggestion was that newsyslog could be modified accordingly. A
> rotation of $LOG to $LOG.$MYDATE isn't particularly taxing :-)

It could, but then the apache installation wouldn't be movable.  I put the
new script with apache, since they may want to move it to another server.

--
Dan

 
 
 

A Solaris 8 (Bourne Shell) Scripting question, regarding a log rotation script

Post by Dimitri Maziu » Tue, 08 Oct 2002 03:51:07


thus spake Dan Logcher:



>> > Oh I disagree.  I've been asked by developers to archive months of
>> > logs.  It is sometimes necessary to rotate logs to dated filenames in
>> > a seperate location.  I had to do this for a Netegrity server because
>> > the logs were over 1GB a day, and they need to review logs some
>> > times going back over 20-30 days.


>>  > just modify the Solaris "newsyslog," script
>>         ^^^^^^

>> Hence my suggestion was that newsyslog could be modified accordingly. A
>> rotation of $LOG to $LOG.$MYDATE isn't particularly taxing :-)

> It could, but then the apache installation wouldn't be movable.  I put the
> new script with apache, since they may want to move it to another server.

RedHat's logrotate compiles on Solaris with a couple of
obvious fixes -- if you don't want to use the binary from
sunfreeware.

Dima
--
We're sysadmins. Sanity happens to other people.                  -- Chris King