|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Log Rotation in Solaris Using Logadm
Starting from Solaris 9, there is a standard tool, called
logadm, to
rotate logs. Logadm is an independent Utility, unlike integrated
in syslog daemon capability that can be found in AIX. The logadm command is a preconfigured entry in
the default crontab file supplied with Solaris 9 and Solaris 10. The /usr/lib/newsyslog
script is no longer used.
Note: Before Solaris 9 there was FreeBSD-style tool
newsyslog located at /usr/lib/ and Perl script
rotatelog written
by Shaun Rowland. It meant to be run from cron, with a configuration file and
documentation available. For Solaris 8 and earlier you can download the tar.gz file and untar it. Then go in
the new directory, and execute make install. It will install everything
by default under /usr/local/ (mainly /usr/local/sbin/rotatelog and /usr/local/etc/rotatelog.conf).
logadm uses a configuration file
logadm.conf. The latter specifies the schedule for log rotation and
options with which rotation will be performed. In the default configuration of
logadm.conf the
/var/adm/messages file is already configured to be
rotated:
The syntax of the
logadm.conf file is as follows:
logname <space> options
A very simple configuration to rotate these files. Insert the
following line:
/var/adm/sshdlog -C 7 -P 'Sat Jan 21 08:10:00 2006' -a 'pkill sshd2'
As you can see from the line above, we specified /var/adm/sshdlog
as our log to rotate.
The options (see
Reference for the full list).:
-C -- count Delete the oldest versions until there are not more than count
files left. This option specifies the maximum number of
log files to keep. If exceeded, the oldest file will be deleted to keep the
total
number at specified value -P -- period Rotate a log file after the specified time period (period)
.This option is used to specify a timestamp
for the particular log last rotation. Specify period as a number followed by d for days, w
for weeks, m for months (really 30 days) or y for years.
There are also two special values for period: now and never.
-p now forces log rotation. -p
never forces no log rotation. -a -- This option is used to specify a post
command that is run once after all logs have been rotated. The command can send
HUP signal to a daemon or restart it. It also can be used to compress the
rotated log with non standard compressor (-z option can be used for standard
compressor) and or send message to sysadmin- -s size Rotate the log file only if its size is greater than or equal to
size. Specify size as a number followed by the letter
b for
bytes, k for kilobytes, m for megabytes, or g for
gigabytes.
Like with cron, the -w option to logadm(1M) is the preferred way to modify
the configuration file, but if you do edit it by hand. In this case use "logadm -V" to
check it for errors and to activate changes.
For example, one entry in the /etc/logadm.conf file
specifies that the /var/log/syslog file is rotated weekly unless the
file is empty. The most recent syslog file becomes syslog.0,
the next most recent becomes syslog.1, and so on. Eight previous
syslog log files are kept. The /etc/logadm.conf file also contains time stamps of when the last
log rotation occurred. It is written in the field defined by -P flag.
You can use the logadm command to customize system logging and to
add additional logging in the /etc/logadm.conf file as needed.
For example, to rotate the Apache access and error logs, use the following
commands:
# logadm -w /var/apache/logs/access_log -s 100m
# logadm -w /var/apache/logs/error_log -s 10m
In this example, the Apache access_log file is rotated when it
reaches 100 Mbytes in size, with a .0, .1, (and so on) suffix,
keeping 10 copies of the old access_log file. The error_log is rotated
when it reaches 10 Mbytes in size with the same suffixes and number of copies as
the access_log file.
The /etc/logadm.conf entries for the preceding Apache log rotation
examples look similar to the following:
# cat /etc/logadm.conf
...
/var/apache/logs/error_log -s 10m
/var/apache/logs/access_log -s 100m
For more information, see logadm(1M).
You can use the logadm command as superuser or by assuming an
equivalent role (with Log Management rights). With role-based access control (RBAC),
you can grant non-root users the privilege of maintaining log files by providing
access to the logadm command. For example, add the following entry to the /etc/user_attr file to
grant user andy the ability to use the logadm command:
andy::::profiles=Log Management
Or, you can set up a role for log management by using the Solaris Management
Console. For more information about setting up a role, see "Role-Based Access
Control (Overview)" in System Administration Guide: Security Services.
The log rotation problem exists on any server but it is the most acute on log
consolidation servers (LOGHOST servers) that collect logs from other servers.
The volume of logs on a busy Solaris loghost system grow over 50G in a week. On
a typical loghost just log for /var/adm/messages
can easily be large then 1G in one day.
Among log files which should be rotated on a typical Solaris box: :
/var/adm/syslog -- Logs common system events
/var/adm/messages -- Miscellaneous log file for
most events on a system /var/cron/log -- Logs all jobs run in crontab
/var/lp/logs/lpsched -- Logs information
related to the print services /var/adm/pacct -- Used for process accounting
Notes:
- Those pages are written by people for
whom English is not a native language.
Some amount of grammar and spelling errors should be expected.
- This is a Spartan WHYFF (We Help You For
Free) site. It cannot replace the
best teachers and
the best books.
- The site contain some obsolete pages as
it develops like a living tree... Some links on older pages
are broken. Please try to use
Google, Open directory, etc. to find a replacement link (see
HOWTO search the WEB for details). We would appreciate if
you can
mail us a correct link.
|
|
|
|
BigAdmin - Submitted Tech Tip System Log Rotation Utilizing logadm (for Solaris
9, Solaris 10) by Kristopher March
Today, most system administrators are looking for ways to maximize
their time at work and are always finding new and efficient ways of
carrying out their daily tasks: The built-in Solaris tool,
logadm, is one way to do so. New in the
Solaris 9 Operating System, logadm is found
in /usr/sbin.
Monitoring logs of all types found on a Solaris OS-based machine is a
role most system administrators assume on a daily basis. The most
typical system log of interest would be /var/adm/messages.
On a busy system, this log file tends to grow rather quickly, thus
making log examination a burdensome task. Numerous other log files could
exist on a Sun server running the Solaris OS, all depending on the
configuration. Other applications send information to a log file.
Whether it is informational or critical, the text notices contained
within these log files often provide pertinent data that should be
viewed frequently.
Other log files to note:
/var/adm/syslog -- Logs common system
events
/var/adm/messages -- Miscellaneous
log file for most events on a system
/var/cron/log -- Logs all jobs run in
crontab /var/lp/logs/lpsched -- Logs
information related to the print services
/var/adm/pacct -- Used for process
accounting
In this Tech Tip, we will discuss the appropriate steps needed to set
up and utilize logadm. In the default
configuration, the /var/adm/messages file is
already configured to be rotated. Therefore, we will use the
sshdlog as our example. For most
environments, running SSH is a critical component to secure machines.
With the combination of Secure FTP and many users logging in, there is
the potential for this file to grow rather quickly over a 24-hour
period. Also, the policies of some computer centers require these files
to be archived for a certain amount of time.
Configuration
logadm is an ideal tool to be run from
cron. logadm uses a configuration file found
in the /etc directory. It is called
logadm.conf, and there are a couple of ways
to customize this file to best suit your needs.
In this example, we will edit the file directly using the VI editor.
Following the completion of any modification to the /etc/logadm.conf file, we run the
logadm -V
file to check for any errors and to validate the file before going
further in our process.
Follow these steps to get started.
*must be completed as uid: root
1. Verify you are running the correct version of the Solaris OS. It
should be version 9.
% /usr/bin/uname -r # this will show the version number 5.9
2. Determine which files need to be rotated on a daily basis. Again,
we use the sshdlog found under
/var/adm/ in this example. Most other files
will work.
3. Make a copy of the logadm in case you
need to revert back to the default file.
% cp /etc/logadm.conf /etc/logadm.conf.orig
4. Edit the file using VI.
% vi /etc/logadm.conf
5. The syntax for log rotating is as follows:
logname <space> options
Here we use a very simple configuration to rotate these files. Insert
the following line:
/var/adm/sshdlog -C 8 -P 'Sat Dec 6 08:10:00 2003' -a 'kill -HUP `cat \
/var/run/sshd2_22.pid`'
As you can see from the line above, we specified
/var/adm/sshdlog as our log to rotate.
The options I choose to use are explained here:
-C -- This option specifies the maximum
number of log files to keep. If exceeded, the oldest file will be
deleted to keep the number at 8. If you need to keep these files longer,
change the number to a larger value.
-P -- This option is used to specify a
timestamp for the log?s last rotation.
-a -- This option is used to specify a
post command that is run once after all logs have been rotated. Although
not entirely necessary, I send a kill signal to the SSH parent PID to
reread any configuration files and send a message to the
sshdlog.
6. Once finished editing your file, save it and validate the
sshdloglogadm.conf as specified above.
Many other useful options can be used with the
logadm tool. The best reference available is the man pages on
this subject, which are available in the standard man files location:
/usr/bin/man logadm.
Setting Up logadm to Run from cron
Now that you have your logadm
configuration file updated and validated, it's time to set up cron to
automatically run logadm so that your log
file will be rotated.
As root, open the crontab file and start a new line. Note: I chose to
run logadm every night at 11:58 pm.
/usr/bin/crontab -e - Insert the following line.
58 23 * * * /usr/sbin/logadm
Specified in cron without any options, logadm
will use the default configuration file found in /etc/.
Congratulations! You have successfully set up log rotating and are on
your way to adding other log files that you see fit. Any logs now
specified will automatically rotate without any user intervention.
Blog O’ Matty » Compressing
Solaris logfiles
If you run busy Solaris servers, you may have
realized that the logfiles in /var/log and /var/adm can grow pretty large.
These files are periodically rotated with the Solaris logadm utility, but
they are not compress with the default logadm configuration.
To change this behavior, you can add use the
“-z 0″ option to compress logfiles after they are rotated:
$ logadm
-w /var/log/maillog -C 8 -P ‘Wed Dec 21 19:56:59 2005′ -a ‘kill -HUP `cat /var/run/syslog.pid`’
-s 1m -z 0
Once the “-z” option is added, you can check
the configuration by running logadm with the “-V” option:
$ logadm -V | grep maillog
/var/log/maillog -C 8 -P ‘Wed Dec 21 19:56:59 2005′ -a ‘kill -HUP `cat /var/run/syslog.pid`’
-s 1m -z 0
If you would like to compress existing files
and force a rotation, you can invoke logadm with the “-p now” option:
$ logadm
-p now /var/log/maillog
Hopefully this will save folks some disk
space (not that it’s really required with the size of today’s disks).
[users@httpd] Piped Log Rotation
From: na11@daimlerchrysler.com
Subject: [users@httpd] Piped Log Rotation
Date: Mon, 19 May 2003 20:14:27 GMT
Prev
Next
Prev by Thread
Next by Thread
I've written a simple PERL program that I'm using to pipe the CustomLog=
s
that will split our logs into 24hour chunks:
CustomLog "| /usr/local/apache/bin/siphon.pl --file /tmp/access --time
12:00AM" common
=A0It functions very similar to the rotatelogs program that comes with =
Apache
but writes to our standard files names that we use for logs here
(access.15May-12AM). Couple of questions about the piped CustomLog. One=
, is
there anyway to have it pipe to my PERL script without spawning and
intermediate shell? Here's what the process table looks like right now,=
it
spawns an sh process to run the perl process:
# ps -fj -g 25982
=A0 =A0 =A0UID =A0 PID =A0PPID =A0PGID =A0 SID =A0C =A0 =A0STIME TTY =A0=
=A0 =A0TIME CMD
=A0 nobody 25985 25982 25982 25982 =A00 16:02:10 ? =A0 =A0 =A0 =A00:00
/usr/local/apache/bin/httpd
=A0 =A0 root 25983 25982 25982 25982 =A00 16:02:10 ? =A0 =A0 =A0 =A00:0=
0 /bin/sh
-c =A0/usr/local/apache/bin/siphon.pl --file /tmp/norm --time 11:41
=A0 nobody 25988 25982 25982 25982 =A00 16:02:10 ? =A0 =A0 =A0 =A00:00
/usr/local/apache/bin/httpd
=A0 =A0 root 25984 25983 25982 25982 =A01 16:02:10 ? =A0 =A0 =A0 =A00:0=
0 /usr/bin/perl
/usr/local/apache/bin/siphon.pl --file /tmp/norm --time 11:41
=A0 nobody 25987 25982 25982 25982 =A00 16:02:10 ? =A0 =A0 =A0 =A00:00
/usr/local/apache/bin/httpd
=A0 nobody 25989 25982 25982 25982 =A00 16:02:11 ? =A0 =A0 =A0 =A00:00
/usr/local/apache/bin/httpd
=A0 nobody 25986 25982 25982 25982 =A00 16:02:10 ? =A0 =A0 =A0 =A00:00
/usr/local/apache/bin/httpd
=A0 =A0 root 25982 =A0 =A0 1 25982 25982 =A00 16:02:10 ? =A0 =A0 =A0 =A0=
0:00
/usr/local/apache/bin/httpd
Second question is this. If the web admin botches the args for this PER=
L
program, I'd like to kill the HTTPD process so that they know right awa=
y
that there's a problem (rather then just sending a message to STDERR wh=
ich
is going to go unnoticed into the error log unless they check right awa=
y).
Since there is an intermediate shell process in between my program and =
the
parent httpd process, I can't simply kill my parent to kill the web ser=
ver.
Is it safe instead to get the Process Group ID and send a kill to it?
(getpgrp()) This is written specifically for UNIX environments (solaris=
and
aix), not Wintel.
Thanks for the help.
-Norm Ackroyd=
Re Solaris log files
On Sat, 20 Feb 1999, Todd Williams wrote:
>
> I've always considered writing some tool that would allow you to manage
> and age all your log files from one config file. Maybe the config file
> would be a table that lists the base logfile name, the interval at which
> it gets aged, the number of logs or amount of space to keep online before
> deleting them, etc.
>
> Anybody know of any such program? It might be too much work for
> too little gain.
I'm sure there are others but you might check out RedHat's logrotate.
You can get it from them in RPM or SRPM (source) or you can find it in
several places as a tar ball. Here's one:
ftp://gatekeeper.dec.com/pub/linux/redhat/code/logrotate/
It's GNU'ed and is quite flexible. A quote from the man page:
logrotate is designed to ease administration of systems
that generate large numbers of log files. It allows auto-
matic rotation, compression, removal, and mailing of log
files. Each log file may be handled daily, weekly,
monthly, or when it grows too large.
And an example conf from the man page:
# sample logrotate configuration file
errors sysadmin@my.org
compress
/var/log/messages {
rotate 5
weekly
postrotate
/sbin/killall -HUP syslogd
endscript
}
/var/log/httpd/access.log {
rotate 5
mail www@my.org
errors www@my.org
size=100k
postrotate
/sbin/killall -HUP httpd
endscript
}
/var/log/news/* {
monthly
rotate 2
errors newsadmin@my.org
postrotate
kill -HUP `cat /var/run/inn.pid`
endscript
nocompress
}
I haven't tried compiling it for any of the other UNIX flavors I
administer but it does a nice job on my linux systems.
-
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
BigAdmin - Submitted Tech Tip- System Log Rotation Utilizing ...
Blog O’ Matty » Compressing
Solaris logfiles
docs.sun.com System Administration Guide Advanced Administration
In Solaris 9 release, system log files are now rotated by
the logadm command from an entry in the root crontab file.
The /usr/lib/newsyslog script is no longer used.
The new system log rotation is defined in the /etc/logadm.conf
file. This file includes log rotation entries for processes such as
syslogd. For example, one entry in the /etc/logadm.conf file
specifies that the /var/log/syslog file is rotated weekly unless the
file is empty. The most recent syslog file becomes syslog.0,
the next most recent becomes syslog.1, and so on. Eight previous
syslog log files are kept.
The /etc/logadm.conf file also contains time stamps
of when the last log rotation occurred.
You can use the logadm command to customize system
logging and to add additional logging in the /etc/logadm.conf file as
needed.
For example, to rotate the Apache access and error logs, use
the following commands:
# logadm -w /var/apache/logs/access_log -s 100m
# logadm -w /var/apache/logs/error_log -s 10m
|
In this example, the Apache access_log file is rotated when it
reaches 100 Mbytes in size, with a .0, .1, (and so on)
suffix, keeping 10 copies of the old access_log file. The error_log
is rotated when it reaches 10 Mbytes in size with the same suffixes and number
of copies as the access_log file.
The /etc/logadm.conf entries for the preceding
Apache log rotation examples look similar to the following:
# cat /etc/logadm.conf
.
.
.
/var/apache/logs/error_log -s 10m
/var/apache/logs/access_log -s 100m
|
For more information, see logadm(1M).
You can use the logadm command as superuser or by
assuming an equivalent role (with Log Management rights). With role-based
access control (RBAC), you can grant non-root users the privilege of
maintaining log files by providing access to the logadm command.
For example, add the following entry to the /etc/user_attr
file to grant user andy the ability to use the logadm
command:
andy::::profiles=Log Management
|
Or, you can set up a role for log management by using the
Solaris Management Console. For more information about setting up a role, see
"Role-Based Access Control (Overview)" in System Administration Guide:
Security Services.
BigAdmin - Submitted Tech Tip System Log Rotation Utilizing logadm (for Solaris
9 OS Only) by Kristopher March
Today, most system administrators are looking for ways to maximize their time
at work and are always finding new and efficient ways of carrying out their
daily tasks: The built-in Solaris tool, logadm, is
one way to do so. New in the Solaris 9 Operating System,
logadm is found in /usr/sbin.
Monitoring logs of all types found on a Solaris OS-based machine is a role
most system administrators assume on a daily basis. The most typical system log
of interest would be /var/adm/messages. On a busy
system, this log file tends to grow rather quickly, thus making log examination
a burdensome task. Numerous other log files could exist on a Sun server running
the Solaris OS, all depending on the configuration. Other applications send
information to a log file. Whether it is informational or critical, the text
notices contained within these log files often provide pertinent data that
should be viewed frequently.
Other log files to note:
/var/adm/syslog -- Logs common system events
/var/adm/messages -- Miscellaneous log file for
most events on a system /var/cron/log -- Logs all jobs run in crontab
/var/lp/logs/lpsched -- Logs information
related to the print services /var/adm/pacct -- Used for process accounting
In this Tech Tip, we will discuss the appropriate steps needed to set up and
utilize logadm. In the default configuration, the
/var/adm/messages file is already configured to be
rotated. Therefore, we will use the sshdlog as our
example. For most environments, running SSH is a critical component to secure
machines. With the combination of Secure FTP and many users logging in, there is
the potential for this file to grow rather quickly over a 24-hour period. Also,
the policies of some computer centers require these files to be archived for a
certain amount of time.
Configuration
logadm is an ideal tool to be run from cron.
logadm uses a configuration file found in the
/etc directory. It is called
logadm.conf, and there are a couple of ways to customize this file to
best suit your needs.
In this example, we will edit the file directly using the VI editor.
Following the completion of any modification to the /etc/logadm.conf
file, we run the logadm -V file to check for any
errors and to validate the file before going further in our process.
Follow these steps to get started.
*must be completed as uid: root
1. Verify you are running the correct version of the Solaris OS. It should be
version 9.
% /usr/bin/uname -r # this will show the version number 5.9
2. Determine which files need to be rotated on a daily basis. Again, we use
the sshdlog found under /var/adm/
in this example. Most other files will work.
3. Make a copy of the logadm in case you need to
revert back to the default file.
% cp /etc/logadm.conf /etc/logadm.conf.orig
4. Edit the file using VI.
% vi /etc/logadm.conf
5. The syntax for log rotating is as follows:
logname <space> options
Here we use a very simple configuration to rotate these files. Insert the
following line:
/var/adm/sshdlog -C 8 -P 'Sat Dec 6 08:10:00 2003' -a 'kill -HUP `cat \
/var/run/sshd2_22.pid`'
As you can see from the line above, we specified /var/adm/sshdlog
as our log to rotate.
The options I choose to use are explained here:
-C -- This option specifies the maximum number of
log files to keep. If exceeded, the oldest file will be deleted to keep the
number at 8. If you need to keep these files longer, change the number to a
larger value.
-P -- This option is used to specify a timestamp
for the log?s last rotation.
-a -- This option is used to specify a post
command that is run once after all logs have been rotated. Although not entirely
necessary, I send a kill signal to the SSH parent PID to reread any
configuration files and send a message to the sshdlog.
6. Once finished editing your file, save it and validate the
sshdloglogadm.conf as specified above.
Many other useful options can be used with the logadm
tool. The best reference available is the man pages on this subject, which are
available in the standard man files location: /usr/bin/man
logadm.
Setting Up logadm to Run from cron
Now that you have your logadm configuration file
updated and validated, it's time to set up cron to automatically run
logadm so that your log file will be rotated.
As root, open the crontab file and start a new line. Note: I chose to run
logadm every night at 11:58 pm.
/usr/bin/crontab -e - Insert the following line.
58 23 * * * /usr/sbin/logadm
Specified in cron without any options, logadm will
use the default configuration file found in /etc/.
Congratulations! You have successfully set up log rotating and are on your
way to adding other log files that you see fit. Any logs now specified will
automatically rotate without any user intervention.
docs.sun.com man pages section 1M System Administration Commands
logadm(1M)– manage endlessly growing log files
logadm is a general log rotation tool that is suitable for
running from
cron(1M).
Without arguments, logadm reads the /etc/logadm.conf
file, and for every entry found in that file checks the corresponding log file
to see if it should be rotated. Typically this check is done each morning by
an entry in the root's crontab.
If the logname argument is specified, logadm renames
the corresponding log file by adding a suffix so that the most recent log file
ends with .0 (that is, logfile.0), the next most
recent ends with .1 (that is, logfile.1), and so
forth. By default, ten versions of old log files are kept (that is,
logfile.0 through logfile.9) and
logadm automatically deletes the oldest version when appropriate to keep
the count of files at ten.
logadm takes a number of options. You can specify
these options on the command line or in the /etc/logadm.conffile .
The logadm command searches /etc/logadm.conf for lines
of the form logname options
- logname
- Identifies the name of the entry in /etc/logadm.conf, but if
no log file name is given in that entry it is assumed that the logname is
the same as the actual log file name.
- options
- Identifies command line options exactly as they would be entered on the
command line. This allows commonly used log rotation policies to be stored
in the /etc/logadm.conf file. See EXAMPLES.
If options are specified both in /etc/logadm.conf
and on the command line, those in the /etc/logadm.conf file are
applied first. Therefore, the command line options override those in
/etc/logadm.conf.
Log file names specified in /etc/logadm.conf may contain
filename substitution characters such as * and ? that are
supported by
csh(1).
Two options control when a log file is rotated. They are: -s
size -p period.
- When using more than one of these options at a time, there is an implied
and between them. This means that all conditions must be met before the
log is rotated.
- If neither of these two options are specified, the default conditions for
rotating a log file are: -s 1b -p 1w,
which means the log file is only rotated if the size is non-zero and if at
least 1 week has passed since the last time it was rotated.
- By specifying -p never as a rotation condition,
any other rotation conditions are ignored and logadm moves on to
the expiration of old log files. By specifying -p now
as a rotation condition, a log rotation is forced.
- Unless specified by the -o, -g, or
-m options, logadm replaces the log file (after
renaming it) by creating an empty file whose owner, group ID, and permissions
match the original file.
- Three options control when old log files are expired: -A
age -C count -S size. These options expire
the oldest log files until a particular condition or conditions are met. For
example, the combination -C 5 and the
-S 10m options expires old log files until there are no more
than 5 of the and their combined disk usage is no more than 10
megabytes. If none of these options are specified, the default expiration is
-C 10 which keeps ten old log files. If no files
are to be expired, use -C 0 to prevent expiration
by default.
OPTIONS
OPERANDS
EXAMPLES
Example 1 Rotating a File and Keeping Previous Versions
The following example rotates the /var/adm/exacct/proc file,
keeping ten previous versions in /var/adm/exacct/proc.0 through
/var/adm/exacct/proc.9.
Tell logadm to copy the file and truncate it.
example% logadm -c /var/adm/exacct/proc
|
Example 2 Rotating syslog
The following example rotates syslog and keeps eight log files.
Old log files are put in the directory /var/oldlogs instead of
/var/log:
example% logadm -C8 -t'/var/oldlogs/syslog.$n' /var/log/syslog
|
Example 3 Rotating /var/adm/sulog and Expiring Based on Age
The following entry in the /etc/logadm.conf file rotates the
/var/adm/sulog file and expires any copies older than 30 days.
/var/adm/sulog -A 30d
Example 4 Rotating Files and Expiring Based on Disk Usage
The following entry in the /etc/logadm.conf file rotates the
/var/adm/sulog file and expires old log files when more than 100
megabytes are used by the sum of all the rotated log files.
/var/adm/sulog -S 100m
Example 5 Creating an Entry that Stores the Logfile Name
This example creates an entry storing the log file name and the fact that
we want to keep 20 copies in /etc/logadm.conf, but the
-p never means the entry is ignored by the normal logadm
run from root's crontab every morning.
example% logadm -w locallog /usr/local/logfile -C20 -p never
|
Use the following entry on the command line to override the -p
never option:
example% logadm -p now locallog
|
Example 6 Rotating the apache Error and Access Logs
The following example rotates the apache error and access logs monthly to
filenames based on current year and month. It keeps the 24 most recent copies
and tells apache to restart after renaming the logs.
This command is run once, and since the -w option is
specified, an entry is made in /etc/logadm.conf so the apache logs
are rotated from now on.
example% logadm -w apache -p 1m -C 24\
-t '/var/apache/old-logs/$basename.%Y-%m'\
-a '/usr/apache/bin/apachectl graceful'\
'/var/apache/logs/*{access,error}_log'
|
This example also illustrates that the entry name supplied with the
-w option doesn't have to match the log file name. In this
example, the entry name is apache and once the line has been run, the
entry in /etc/logadm.conf can be forced to run by executing the
following command:
example% logadm -p now apache
|
Because the expression matching the apache log file names was enclosed in
quotes, the expression is stored in /etc/logadm.conf, rather than
the list of files that it expands to. This means that each time logadm
runs from cron it expands that expression and checks all the log
files in the resulting list to see if they need rotating.
The following command is an example without the quotes around the log name
expression. The shell expands the last argument into a list of log files that
exist at the time the command is entered, and writes an entry to /etc/logadm.conf
that rotates the files.
example% logadm -w apache /var/apache/logs/*_log
|
FILES
- /etc/logadm.conf
- configuration file for logadm command
ATTRIBUTES
SEE ALSO
NOTES
When logadm applies expire conditions (supplied by the
-A, -C, and -S options), it
deletes files, the oldest first, until the conditions are satisfied. If the
template used for naming the old logs contained $n or $N,
logadm picks the highest value of $n or $N found
in the old log file names first. If the template used is something else,
logadm uses the modification time to determine which files to expire
first. This may not be the expected behavior if an old log file has been
modified since it was rotated.
SunOS 5.9 Last Revised 6 Dec 2001
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
June 02, 2008
