Original Question:
-----------------
I was wondering about syslogd on v5.0 tru64 unix.
I noticed that the logs were being rotated every 24 hours, but
not at any specific time. On any one given machine, the rotation
time would be the same. However on different machines the time was
different.
Summary:
-------
Turn out my suspicions were correct. It is syslogd that handles the
rotation of the files found in /usr/adm/syslog.dated
and maintains the link 'current' in the same directory.
Further, syslogd rotates every 24 hours from the time it was started, so
each machine being last booted at various times had various log rotation
times.
The problem is that the man pages for syslogd do not explicitly state that
the daemon is responsible for the log rotation and maintenance of
'current' link. Dr Blinn suggests that the 'current' link is a new feature
added to v5.0 as a response to customer requests. The man page does
discuss the existence of this link, but does not say who/what/when about its
creation, etc.
So, to get the logs to rotate on a more 'daily' schedule, a simple line
in the root crontab will do it. Send the daemon a HUP signal and it will
rotate the logs and update the 'current' link.
This is best achieved via the following:
1 0 * * * /sbin/kill -HUP `cat /var/run/syslog.pid`
This will rotate the logs at 12:01 every night, even if the machine is
rebooted at some other arbitrary time.
This ensures that any one day's logs has entries from that calendar day,
not a mix of the last 24 hour period.
Also, there is another line in the stock root crontab that removes the
same log files if they are more than seven days old. Some may wish to keep
the logs around for longer, so modification of this line will keep more
days worth of logs around.
Addendum:
--------
The following is from the indispensable Dr Blinn, who suggests how one may
go about getting this fixed, assuming its not in the sys admin book.
I haven't checked.
"You are correct that most of this behavior is not documented in the reference
page, and I don't think it's in the system admin book either (but please check).
If you really want the documentation fixed, and you have a service
contract, then PLEASE open a formal problem report and STRESS the business
case for an update; people tend to ignore things like this because few customers
ever make any formal complaints. (I could go and try to find a product manager
who is responsible for "serviceability" or "system management" and try to
get him or her to have a clue, but it's a hopeless and thankless task, and
a slew of customer complaints coming into the support centers is much more
likely to get attention focused on the issue.) "
Thanks to all that responded,
Russ
O===========================================O
| R U S S E L L G A U L D |
| +------------------+------------------+ |
| Computational Fluid Dynamics Group |
| Department of Mechanical Engineering |
| P.O. Box 116300 |
| University of Florida |
| Gainesville, FL 32611 |
| 352.392.4442 |
| * * * |
O===========================================O
Received on Thu Feb 24 2000 - 22:52:41 NZDT