how to truncate /var/adm/messages?
Bryan Levin
(from a running system, that is).
thanks,
--
.bl
<a href=" http://www.best.com/~bryan "> Bryan Levin </a>
Elmar Haag
--
I don't know if that's the best solution, but how about:
kill -STOP <pid of syslogd>
cp /var/adm/messages <wherever-you-want>
cat > /var/adm/messages
^D
kill -CONT <pid of syslogd>
I think it's a bit better to halt the syslogd instead of killing and restarting it.
Better suggestions?
Greetings,
Elmar
------------------------------------------
####### # # ### # # ### # # ### ### # ###
# # # # # # # # # # # # # # #
# # # # # # # # # # # # # # #
# # # # # # # # # # # # # # #
#### # # # ## # ###### # #### ####### #
# # # # ## # # # # ## # # #
# # # # # # # # # # # # # # #
# # # # # # # # # # # # # # #
# # # # # # # # # # # # # # #
# ### ### # # ### # # ### # # # # ###
-------------------------------------------
Elmar Haag Medical Informatics at Fachhochschule Heilbronn, Germany
EMail: elh...@jupiter.rz.fh-heilbronn.de (preferred)
elh...@hermes.stud.fh-heilbronn.de
Ph
Larry Daffner
>I don't know if that's the best solution, but how about:
>kill -STOP <pid of syslogd>
>cp /var/adm/messages <wherever-you-want>
>cat > /var/adm/messages
>^D
>kill -CONT <pid of syslogd>
>I think it's a bit better to halt the syslogd instead of killing and restarting it.
>Better suggestions?
You need to kill and restart syslogd. The above may cause problems,
such as disappearing messages from the time it is done until the next
reboot, as it still has the old filehandle (STOP and CONT are
basically the same as a ^Z and won't change the filehandle). So, the
proper thing to do would be:
cat /var/adm/messages >> /var/adm/messages.old
kill -TERM <syslogd PID>
syslogd
Actually, the optimal solution would be to have syslogd catch SIGHUP
and then close all open files, reread the syslog.conf and reopen any
files. This is a pretty standard UNIX-style thing for daemons to do,
at least on the systems I've had the opportunity to admin on.
HTH
-Larry
--
Larry Daffner - Software Engineer | email: ldaf...@convex.com |
Convex Computer Corporation | tel: (214)497-4274 / home: (214)380-4382 |
It's better to be silent and be thought a fool than to speak and remove all
doubt. --Abraham Lincoln
Mats Andtbacka
>what is the proper way to close and reopen a new /var/adm/messages file?
`>messages` should work.
Myself, I wrote up a Perl script that pipes the contents of various
log files through gzip and out to datestamped archive files, then runs
the Perl function truncate() on the files. Works for me.
(no, i'm not going to post it - Perl is a simple enough language that
most people can easily learn to write such a thing themselves. only
took me a week of very occasional hacking to get that far. do a Yahoo
search on Perl, there's _lots_ of good tutorials out there.)
>(from a running system, that is).
I'm still not sure what might happen if you truncate wtmp while
somebody's logged in, or (worse still) in the process of logging in or
out. Might want to write some form of script to do it, and schedule it
to be run in the middle of night when nobody's likely to be logged on.
...That said, I've never really bothered to do that myself, I've just
chopped off my wtmp whenever it's gotten too big, any time of day. No
permanent system damage yet that I've noticed...
--
" ... this is the first day of my last days ... " -- nin
gr...@gregpc.dbnonline.co.za
>what is the proper way to close and reopen a new /var/adm/messages file?
>
Just type:
> /var/adm/messages
(with the '>')
Alex
>what is the proper way to close and reopen a new /var/adm/messages file?
>(from a running system, that is).
>thanks,
>--
>.bl
><a href=" http://www.best.com/~bryan "> Bryan Levin </a>
Step one: rename the file. Syslog will still be writing in it after
renameing so you don't loose messages.
Step two: create a new one. After reinitialising syslogd it will be
used.
Step three: Make syslog use the new file. Do not restart it, just
reinitialise.
1) mv /var/adm/messages /var/adm/messages.prev
2) touch /var/adm/messages
3) kill -1 pid-of-syslogd
This should work on a decent unix(like) system, and I know linux is
one of them.
Bryan J. Phillippe
> Bryan Levin wrote:
> > what is the proper way to close and reopen a new /var/adm/messages file?
> > (from a running system, that is).
> >
> I don't know if that's the best solution, but how about:
> kill -STOP <pid of syslogd>
> cp /var/adm/messages <wherever-you-want>
> cat > /var/adm/messages
> ^D
> kill -CONT <pid of syslogd>
>
I have a setup that I've heard is very similar to RedHat(?) root's
crontab contains entries that use find to get the names of the log files
I want to delete, by their size, and then mail them to my admin account,
then copy /dev/null to them.. So, like this...
0 */4 * * * /usr/bin/nice -19 /root/bin/log_trim.sh
And the script /root/bin/log_trim.sh looks like this (only a piece of it,
to save bw, but you get the idea..)
#!/bin/sh
# - log-trim.sh
# FIND_CMD: This command is what get's called to check the sizes
# of the log files.
FIND_CMD="/usr/bin/find"
$FIND_CMD /var/log/messages -size +10k \
-exec /bin/mail -s "{}" root < /var/log/messages ";" \
-exec /bin/cp /dev/null "{}" ";"
$FIND_CMD /var/log/mg-log.ttyS1 -size +2k \
-exec /bin/mail -s "{}" root < /var/log/mg-log.ttyS1 ";" \
-exec /bin/cp /dev/null "{}" ";"
$FIND_CMD /var/log/sudo.log -size +1k \
-exec /bin/mail -s "{}" root < /var/log/sudo.log ";" \
-exec /bin/cp /dev/null "{}" ";"
etc, etc, etc.
Hope this helps in some way, and good day to you.
Bryan J. Phillippe mailto:br...@eternity.aa.net
Kickin' it since 1.1.59 http://www.ecst.csuchico.edu/~bryanxms
/* Do not distribute this message across the Microsoft(tm) Network */
Darcy Boese
: lines beginning at line 1 to line ? so to periodically shorten the file.
A better solution, and one that translates to other operating systems,
is to simply 'rotate' the log files. I've got a Linux system that logs
to both /var/adm/messages and /var/adm/syslog. So a simple-ish rotation
script could look something like this:
==================================
#!/bin/sh
PATH=/bin
cd /var/adm
a=`date +%y.%m.%d`
mv messages messages.$a
mv syslog syslog.$a
touch messages
touch syslog
killall -HUP syslogd
gzip -9 messages.$a
gzip -9 syslog.$a
==================================
Note that I haven't actually tested this script myself.. I just wrote
it now off the top of my head. But I generally perform something
similar by hand.
Also note that you don't want to run this script more than once a day..
or else your old(er) logs can get overwritten by your new(er) logs.
--
Darcy Boese pos...@niagara.com | Author of Columns Shareware
the *official* roadkill on the i-way | http://www.niagara.com/~possum/columns
--
My opinions are my own, and as such, they do not necessarily reflect reality.
Robert Buscemi
beginning at line 1 to line ? so to periodically shorten the file.
**********************************************************
Robert Buscemi
rb6...@pegasus.cc.ucf.edu
University of Central Florida
Orlando, Florida USA
**********************************************************
Todd Ginther
: A better solution, and one that translates to other operating systems,
: is to simply 'rotate' the log files. I've got a Linux system that logs
: to both /var/adm/messages and /var/adm/syslog. So a simple-ish rotation
: script could look something like this:
<munch><munch>
: Note that I haven't actually tested this script myself.. I just wrote
: it now off the top of my head. But I generally perform something
: similar by hand.
I just tried the script out. Seems to work great, thanks!
-Todd
Joel Boring
: I just open /var/adm/messages with vi, then use vi to remove the range of lines
: beginning at line 1 to line ? so to periodically shorten the file.
I have the following in /etc/rc.d/rc.inet2, it runs just before the
syslog daemon is kicked in. All it does is gzips the messages and
syslog files by month, if you reboot often you might want to change
all the "/bin/date %y%m" to "/bin/date %y%m%d", this will gzip by day
instead, and also cut down about 10 seconds at boot time.
----------------------------------------------------------
# gzip old message and syslog file by month so they don't get too big
# this should appear sometime BEFORE the syslogd daemon starts,
# otherwise deleting /var/log/messages or /var/log/syslog will kill
# the daemon and you won't get logging to a file anymore.
echo "Saving syslog file..."
/usr/bin/gunzip /var/log/slog.`/bin/date +%y%m` > /dev/null 2>&1
/usr/bin/cat /var/log/syslog >> /var/log/slog.`/bin/date +%y%m`
/bin/gzip -9 /var/log/slog.`/bin/date +%y%m`
/bin/rm /var/log/syslog
echo "Saving messages file..."
/usr/bin/gunzip /var/log/msgs.`/bin/date +%y%m` > /dev/null 2>&1
/usr/bin/cat /var/log/messages >> /var/log/msgs.`/bin/date +%y%m`
/bin/gzip -9 /var/log/msgs.`/bin/date +%y%m`
/bin/rm /var/log/messages
--------------------------------------------------------------------
--
Joel Boring aka Derek Wildstar <dw...@starforce.com>
----------------------------------------------------------
This message is not to be sent over the Microsoft Network.
Jon Wright
Here is a script that I have been using on my machines for the last 3 years.
I don't remember who wrote it first, but it does work very nicely. It reads
the syslog.conf file and rolls every log file that syslog handles. The
variables that are defined should be changed to fit your situation. Then place
the command to run this script in your rc.X script of choice. It keeps the
last seven logs I believe. It will only execute when you reboot the machine,
so for long lasting boxes it might be better to run it from cron. I use it
here at work on a production machine that regularly goes 3+ weeks between
reboots.
If you have any questions, send me mail.
Jon
=====
From here to end of post is a korn shell script that runs fine underpdksh
+++++
#!/bin/ksh
#
# rotate-logfiles - keep the last 7 days logfiles around
# automagically...
CONF="/etc/syslog.conf"
SYSLOGDIR="/var/adm"
# grab all the lines in the syslog conf file that don't go to another host
# oooooohhhhh - aren't we just sooooooo slick ?
#
# skip over /var/adm/news (INN news.daily does it) and devices and anything not /path/filename
FILENAMES=`grep -v "^#" $CONF | awk '{print $2}' | sort | uniq | grep "^/" | grep -v "news" | grep -v "debug" | grep -v "/dev"`
LOGMODE="755"
LOGOWN="root.root"
TOUCH="/bin/touch"
CHMOD="/bin/chmod"
CHOWN="/bin/chown"
# go there, do that
cd $SYSLOGDIR
for FILE in $FILENAMES
do
/bin/echo -n "processing $FILE -"
# make 'em to shut up initial warning messages
$TOUCH $FILE $FILE.1 $FILE.2 $FILE.3 $FILE.4 $FILE.5 $FILE.6 $FILE.7
/bin/echo -n " moving old files -"
mv $FILE.6 $FILE.7
mv $FILE.5 $FILE.6
mv $FILE.4 $FILE.5
mv $FILE.3 $FILE.4
mv $FILE.2 $FILE.3
mv $FILE.1 $FILE.2
mv $FILE $FILE.1
/bin/echo -n " touching new logfile -"
$TOUCH $FILE
$CHMOD $LOGMODE $FILE
$CHOWN $LOGOWN $FILE
/bin/echo " done"
done
# /bin/echo -n " restarting syslog"
# kill -1 `cat /etc/syslog.pid`
/bin/echo " done"
--
Jon Wright | "Suicide is painless,
Armstrong State College | And all in life is gainless,
Savannah, Ga | And I can take or leave it as I choose.
j...@armstrong.edu | Theme song from "M.A.S.H."
Martin Gallant
designed to be run on live machines, a reboot is *not* required. Just
schedule a periodic run through root's crontab. I run these monthly.
Comments, suggested improvements, are welcome.
Here is the basic script:
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
#!/bin/sh
# CLEANLOG <log-file>
# Periodically tidy and archive archive system log files
if [ ! -f $1 ]; then
echo "Could not find log file $1"
exit 1
fi
dir=`/usr/bin/dirname $1`
log=`/usr/bin/basename $1`
# Cycle the existing archives
rm -f $dir/$log.3.gz
if [ -f $dir/$log.2.gz ]; then /bin/mv -f $dir/$log.2.gz $dir/$log.3.gz; fi
if [ -f $dir/$log.1.gz ]; then /bin/mv -f $dir/$log.1.gz $dir/$log.2.gz; fi
# Copy the log file and zero it
/bin/cp $dir/$log $dir/$log.1
/bin/cp /dev/null $dir/$log
# Compress the most recent archive
/bin/gzip $dir/$log.1
exit 0
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
And the wrapper I run from cron:
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
#!/bin/sh
/root/cleanlog /var/adm/messages
/root/cleanlog /var/adm/wtmp
/root/cleanlog /var/adm/syslog
/root/cleanlog /var/adm/xferlog
/root/cleanlog /var/adm/sudo.log
exit 0
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
--
Marty
Alex
>what is the proper way to close and reopen a new /var/adm/messages file?
>(from a running system, that is).
>thanks,
>--
>.bl
><a href=" http://www.best.com/~bryan "> Bryan Levin </a>
First, rename the file. This way messages will still be sent to the
old file since it's not closed. Create a new file, /var/adm/messages.
Send a SIGHUP to syslogd
Thomas McKearney
Alex <al...@ergens.op.het.net> wrote:
>br...@shellx.best.com (Bryan Levin) wrote:
>
>>what is the proper way to close and reopen a new /var/adm/messages file?
>
>>(from a running system, that is).
>
>>thanks,
cp /dev/null > /var/adm/messages (that will kill the file and let the system
keep running)
Thomas R. Stevenson
Because emptying files is such a common operation, the above command
can be shorted to:
> /var/adm/messages
the `cp /dev/null` is not required.
--
____ __ __ EMail: t...@tom.cc.wayne.edu
/ /_/ /_ VMail: (313) 577-4742
/. /\. __/. Fax: (313) 577-5626
Home Page: http://tom.cc.wayne.edu
Anon FTP: ftp://tom.cc.wayne.edu
For my PGP PUBLIC KEY BLOCK,
finger t...@tom.cc.wayne.edu
"A common mistake that people make when trying
to design something completely foolproof was Douglas Adams
to underestimate the ingenuity of complete Mostly Harmless
fools."
Robert Tsai
: Thomas McKearney (t...@tmckearn.smart.net) wrote:
: > cp /dev/null > /var/adm/messages (that will kill the file and let the system
: Because emptying files is such a common operation, the above command
: can be shorted to:
: > /var/adm/messages
: the `cp /dev/null` is not required.
What if I don't want to get rid of the whole thing, but just want to keep,
say, the last 500 lines or something?
--
--Rob
--------------------------------------------------------------------------
Robert Tsai http://rtsai.student.harvard.edu/~rtsai/
Eric Vought
> say, the last 500 lines or something?
I have a crontab entry (comes with RedHat actually) that will mail
var/adm messages to root after it passes a certain size, then truncates
the file. That way, you can review the file and delete it it
periodically.
To save just the last few lines, try something like the following:
tail -500 messages > foo
> messages
cat foo > messages
rm foo
This takes the last 500 lines, saves it to another file, truncates the
file, then puts the saved portion back. This should work, anyway.
Reality is a point of view
| can be shorted to:
|
| > /var/adm/messages
|
| the `cp /dev/null` is not required.
Not with all shells. BTW, the cp redirection isn't necessary.
cp /dev/null /var/adm/messages
--
Gary Johnson "I'd a done sumpin too, but I ain't no Peckerton Ditinctive."
gjoh...@season.com
CAMPAIGN '96: Juck 'em if they can't fake a toke.
TonyK Lindstroom
rt...@rtsai.student.harvard.edu (Robert Tsai) writes:
>
>What if I don't want to get rid of the whole thing, but just want to keep,
>say, the last 500 lines or something?
:> tail -500 /var/adm/message > /tmp/tmp.messages
:> cat /var/adm/messages >! /var/adm/messages
(t)csh
--
** Work:t...@ray.fi (Sparc SunOS 4.1.3)/Pelika RAY Oy - Espoo **
** Home:to...@pulpuri.pp.fi (AMD Linux 1.2.13) /Eestintaival - Espoo **
******http://www.xgw.fi/~tonyk to...@pelikaani.fi [Tony Lindström]******
Robert Nichols
Robert Tsai <rt...@rtsai.student.harvard.edu> wrote:
:
:What if I don't want to get rid of the whole thing, but just want to keep,
:say, the last 500 lines or something?
The simplest thing to do is periodically save the current log file and
start a new one. Here's the quick & dirty method:
cd /var/adm
cp -p messages messages.o
: >messages
That method has the chance of losing any message that arrives after
the file is copied but before it is truncated. Do you really care?
OK, here's another way:
cd /var/adm
mv messages messages.o
umask 077 # if you want it private
: >messages
killall -HUP syslogd
Prior to the 'killall' command, 'syslogd' still has the old file open.
Sending a SIGHUP tells 'syslogd' to close its current log files and
restart. This second method does not handle any currently running
programs other than 'syslogd' writing to the messages file. You will
have to figure out how to get them to start using the new log file.
I've attached the script that I run twice a week.
--
Bob Nichols rnic...@interaccess.com
========================================================================
#!/bin/bash
# Maintain the log files in /var/adm and /var/log. The current log file
# will be saved and restarted if its size exceeds MAXSIZE, or if 30 days
# or more has elapsed since the file was last saved and its current size
# is non-zero.
# You can override MAXSIZE for any individual file by following the
# file name with ":nnnnn" where nnnnn is the desired maximum, e.g.:
# PARAMS="auth chat.log cron:10000 debug messages"
PARAMS="auth chat.log cron debug messages notice syslog wtmp news.log"
MAXSIZE=50000
savelog() {
FILE="$1"
LIM="$2"
if [ -r "$FILE" -a ! -L "$FILE" ]
then if [ -f "$FILE.o" ]
then if [ -n "`find \"$FILE.o\" -mtime +29`" ]
then LIM=1
fi
else touch "$FILE.o"
fi
set -- `ls -l -- "$FILE"`
if [ "$5" -ge $LIM ]
then rm -f "$FILE.oo"
test -e $FILE.o && mv "$FILE.o" "$FILE.oo"
cp -p -- "$FILE" "$FILE.o" && : >"$FILE"
fi
fi
}
for D in /var/adm /var/log
do for X in $PARAMS
do SLIMIT=$MAXSIZE
NAME="${X%:*}"
test x"$NAME" != x"$X" && SLIMIT="${X#*:}"
savelog "$D/$NAME" "$SLIMIT"
done
done
========================================================================
Kevin Benton
> > Alex <al...@ergens.op.het.net> wrote:
> > >br...@shellx.best.com (Bryan Levin) wrote:
> > >
> > >>what is the proper way to close and reopen a new /var/adm/messages file?
> > >>(from a running system, that is).
>
>
> Because emptying files is such a common operation, the above command
> can be shorted to:
>
> > /var/adm/messages
>
> the `cp /dev/null` is not required.
>
#!/bin/sh
#
# Post log files at midnight each night, maintaining permissions, but
mailing
# log to sysadmin.
#
post_logfile() {
if [ ! -f $1 ]
then
return
fi
temp=`cat $1`
if [ -z "$temp" ]
then
return
fi
mail -s "postlogs: $1" $ADMIN_USER <$1
cat </dev/null >$1
}
ADMIN_USER=<***set to your own liking***>
export ADMIN_USER
post_logfile /var/log/cron
post_logfile /var/log/debug
post_logfile /var/log/lastlog
post_logfile /var/log/messages
post_logfile /var/log/ppp-log
post_logfile /var/log/sudo.log
post_logfile /var/log/syslog
for i in /var/log/mgetty/log_mg.* ; do post_logfile $i ; done
---cut---cut---cut---
---
Catch me on IRC (EFNet) on #!!!!LetsTalk live and in person as s1kevin!
InterNet: s1k...@sota-oh.com (the 1 is a one, not an l - el).
*** NOTE: Please be sure that the reply address matches the address
above,
otherwise, mail will be lost in the bit-bucket.
Ian Brown
Here it is
#! /usr/bin/perl
#
# agelog n file [file ...]
#
# "age" a logfile by renaming it file.1 .. file.n as it ages
#
if( $#ARGV < 1 ) {
print "Insufficient number of arguments to agelog\n";
exit 1;
}
$num = shift(@ARGV);
while( $file = shift(@ARGV) ) {
if( $file =~ /old$/ ) {
next;
}
for( $new = $num, $old = $num - 1; $new > 1; $new--, $old-- ) {
rename( "$file.$old", "$file.$new" );
}
if( -f "$file.old" ) {
# deal with syslog "feature"
system "mv $file.old $file.1; cat $file >> $file.1";
system "rm $file";
} else {
rename( $file, "$file.1" );
}
system "touch $file";
($dev,$ino,$mode,$nlink,$uid,$gid) = stat( "$file.1" );
chmod( $mode, $file );
chown( $uid, $gid, $file );
}
# Local Variables:
# mode:perl
# End:
In my roots crontab file I have:
0 0 * * * /usr/local/bin/agelog 7 /var/adm/messages
# restart syslog to connect to new files
1 0 * * * /usr/local/bin/syslog.hup
The syslog.hup looks like this:
if [ -f /etc/syslog.pid ]
then
pids=`cat /etc/syslog.pid`
fi
if [ "$pids" ]
then
kill -HUP $pids >/dev/null 2>&1
fi
This will agelog my messages file and give syslog a HUP signal to attach to
the new messages file.
The beauty of this method is that I can automagically keep log files for
seven days at which time they are discarded.
Enjoy.
--
Ian Brown
Ian....@ibrown.mgl.ca
Ian....@Waterloo.NCR.com
Claus Geyer
>What if I don't want to get rid of the whole thing, but just want to keep,
>say, the last 500 lines or something?
tail -500 filename > /tmp/$$trunc
cat /tmp/$$trunc > filename
rm /tmp/$$trunc
This script will do what you want
Claus Geyer
Jason Uhlenkott
> What if I don't want to get rid of the whole thing, but just want to keep,
> say, the last 500 lines or something?
Try the "tail" command. For instance:
#!/bin/sh
tail 500 /var/adm/messages>/var/adm/messages.temp
rm /var/adm/messages
mv /var/adm/messages.temp /var/adm/messages
Wim Vandeputte
no! cat /var/adm/messages.temp > /var/adm/messages
rm /var/adm/messages.temp
Fred Ringel
>>Robert Tsai wrote:
>>> What if I don't want to get rid of the whole thing, but just want to keep,
>>> say, the last 500 lines or something?
>>
>>Try the "tail" command. For instance:
>>
>>#!/bin/sh
>>tail 500 /var/adm/messages>/var/adm/messages.temp
>>rm /var/adm/messages
>>mv /var/adm/messages.temp /var/adm/messages
>>
>>
Ar4e you sure this won't screw up the daemon by moving the
message out from under it while its running? I just use a text editor
like joe to block out the old messages and delete them, save the new
file then delete the "messages~" file with the old stuff in it.
I have a related question. How do I trim the "wtmp" file? A
text editor will not work on that.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Fred B. Ringel Rivertown.Net
Systems Administrator P.O. Box 532
and General Fixer-upper Hastings, New York 10706
Voice/Support: 914.478.2885 Data: 914-478-4988
Westchester's Rivertown's Full Service Flat-Rate Internet Access Provider
balthazaar
>On Wed, 17 Apr 1996, Jason Uhlenkott wrote:
>
>>>Robert Tsai wrote:
>>>> What if I don't want to get rid of the whole thing, but just want to keep,
>>>> say, the last 500 lines or something?
>>>
>>>Try the "tail" command. For instance:
>>>
>>>#!/bin/sh
>>>tail 500 /var/adm/messages>/var/adm/messages.temp
>>>rm /var/adm/messages
>>>mv /var/adm/messages.temp /var/adm/messages
>>>
>>>
> Ar4e you sure this won't screw up the daemon by moving the
>message out from under it while its running? I just use a text editor
>like joe to block out the old messages and delete them, save the new
>file then delete the "messages~" file with the old stuff in it.
>
> I have a related question. How do I trim the "wtmp" file? A
>text editor will not work on that.
No, it won't hurt anything.
cp wtmp wtmp.old
cat /dev/null>wtmp
if you are saving the old wtmp.
anything more requires more than a simple shell script.
--
se...@comp.tamu.edu
Microsoft: Official Sponsor of the 1996
Self-Replicating Program Olympics
Makers of Windows NeTravesty
Obryan Anthony H
: : Try the "tail" command. For instance:
: :
: : #!/bin/sh
: : tail 500 /var/adm/messages>/var/adm/messages.temp
: : rm /var/adm/messages
: : mv /var/adm/messages.temp /var/adm/messages
: rm /var/adm/messages.temp
Actually the rm/mv combo works just as well.
Tom McGlynn
: I have a related question. How do I trim the "wtmp" file? A
: text editor will not work on that.
I believe you need to:
cat /dev/null > wtmp
This will truncate the file and I think it's what I did the last time
wtmp got too large.
--
The preceding is my opinion and not necessarily the opinion of my
employer.
Wim Vandeputte
with rebooting or kill -HUP syslog?
hmmm I should really check this.
anyways, open files resetting (with the program still running) nearly
crashed our system when the news admin did the rm/mv combo thingy.
really dumb: so ok there was a new file but the program kept feeding the
logs to the old (now gone) file. But it still took diskspace!
Wim Vandeputte
: Fred Ringel (fr...@rivertown.net) wrote:
: : I have a related question. How do I trim the "wtmp" file? A
: : text editor will not work on that.
:
: I believe you need to:
:
: cat /dev/null > wtmp
:
: This will truncate the file and I think it's what I did the last time
: wtmp got too large.
I truncate the file every night like this, but is there a way to (binary)
rewrite the file so that the older logins (like > 2months ago) would be nuked?
> wtmp just leaves you with a *new* empty file.
Dave Close
> cp wtmp wtmp.old
> cat /dev/null>wtmp
> if you are saving the old wtmp.
> anything more requires more than a simple shell script.
Last I looked, wtmp had fixed-length records. You might use
dd if=/etc/wtmp bs=56 skip={some number} of={some file}
Doesn't look like something other than a shell script to me...
--
Dave Close, Compata, Costa Mesa CA "Politics is the business of getting
da...@compata.com, +1 714 434 7359 power and privilege without
dhc...@alumni.caltech.edu possessing merit." - P. J. O'Rourke
Thomas Michener
On Sat, 20 Apr 1996, Fred Ringel wrote:
> On Wed, 17 Apr 1996, Jason Uhlenkott wrote:
>
> >>Robert Tsai wrote:
> >>> What if I don't want to get rid of the whole thing, but just want to keep,
> >>> say, the last 500 lines or something?
> >>
> >>Try the "tail" command. For instance:
> >>
> >>#!/bin/sh
> >>tail 500 /var/adm/messages>/var/adm/messages.temp
> >>rm /var/adm/messages
> >>mv /var/adm/messages.temp /var/adm/messages
> >>
> Ar4e you sure this won't screw up the daemon by moving the
> message out from under it while its running? I just use a text editor
> like joe to block out the old messages and delete them, save the new
> file then delete the "messages~" file with the old stuff in it.
>
I use a script similar to the one above. BUT, I use a different
parameters.
1. I use the --lines=xxx and the -q (quiet) options.
2. I only use the -f (force) option of mv. This eliminates the need for
the rm line.
The new script is as follows:
#!/bin/sh
tail -q --lines==500 /var/adm/messages > /var/adm/messages.temp
mv -f /var/adm/messages.temp /var/adm/messages
Why not keep it simple.
Tom Michener
Bryan Levin
The best response was: kill syslog FIRST, then truncate the file (copy, save,
etc).
Its NEVER a good idea to kill an OPEN file. Close it properly (via killing
syslog) and then do what you want with the CLOSED file.
The 'rename' thing may work - but if you catch it at the wrong time, well,
you've been warned ;-) ;-)
--
Bryan Levin
<a href="http://www.hal.com/services/juggle/home/ble...@netcom.com"> BL </a>
balthazaar
>I remember asking this very question, several months ago.
>
>The best response was: kill syslog FIRST, then truncate the file (copy, save,
>etc).
>Its NEVER a good idea to kill an OPEN file. Close it properly (via killing
>syslog) and then do what you want with the CLOSED file.
>The 'rename' thing may work - but if you catch it at the wrong time, well,
>you've been warned ;-) ;-)
>
Why would the file be open? It only needs to be open if
syslogd is writing to it. I'd be surprised if you would
be able to do something to it during that time. Even if
you edit the file, you're working with a copy until you
actually write it back. Ditto for messages. The only
problem with wtmp is it's not an ascii file or you could
do that as well. You only lose the additions made during the
time you edit, since you over write with your copy.
>Bryan Levin
><a href="http://www.hal.com/services/juggle/home/ble...@netcom.com"> BL </a>
--
se...@comp.tamu.edu
"The only way to rid oneself of"
"temptation is to yield to it"
Jason Uhlenkott
> : :
> : : #!/bin/sh
> : : tail 500 /var/adm/messages>/var/adm/messages.temp
> : : rm /var/adm/messages
> : : mv /var/adm/messages.temp /var/adm/messages
> : no! cat /var/adm/messages.temp > /var/adm/messages
> : rm /var/adm/messages.temp
>
> Actually the rm/mv combo works just as well.
I just did it that way because I remember writing a dos batch file a
while back that screwed up royally when I did something in the format
"type filename>filename".
Jong-Min Park
> The best response was: kill syslog FIRST, then truncate the file (copy, save,
> etc).
> Its NEVER a good idea to kill an OPEN file. Close it properly (via killing
> syslog) and then do what you want with the CLOSED file.
This is true.
> The 'rename' thing may work - but if you catch it at the wrong time, well,
> you've been warned ;-) ;-)
I think it is open only while being written to, then syslogd closes
it. In the worst case when it is renamed while being open, since the
file descriptor is associated with the inode and not the filename
(my guess), it will still write to a renamed file until close.
I never had problems with mv/touch combination running as cron job
for two years (also for solaris). Since it is running regularly,
keeping a backup (using mv) didn't waste much space.
But again, just truncating/killing the file in the first place may
be bad.
How about
mv /var/adm/messages /var/adm/messages.old
touch /var/adm/messages
[wait until we are sure syslogd now uses /var/adm/messages]
[start doing whatever you want with /var/adm/messages.old]
Hugh Bonney
: The best response was: kill syslog FIRST, then truncate the file
: (copy, save, etc).
: Its NEVER a good idea to kill an OPEN file. Close it properly (via
: killing syslog) and then do what you want with the CLOSED file.
: The 'rename' thing may work - but if you catch it at the wrong time,
: well, you've been warned ;-) ;-)
This job should be done by syslogd itself, shouldn't it?
The max size of the file should be an invocation parameter.
For files like wtmp with fixed length records the file
could be circular; for the admin file automating one of
these change proceedures is possible. If someone wants to
backup the files the interval could be often enough that
the backstop truncation process doesn't ordinarily kick in.
It should never be possible to jam a system with admin files
either neglected or running amok because of some malfunction.
Of course for debugging you want all the information you can
get, but for, say, server operation there has to be a limit.
For most mishaps, a repeated error message will be close to
the last thing in the error file anyway.
H. ---
Jules d'Entremont
Jong-Min Park wrote:
>
> Bryan Levin (ble...@netcom.com) wrote:
> > I remember asking this very question, several months ago.
>
> > The best response was: kill syslog FIRST, then truncate the file (copy, save,
> > etc).
>
> > Its NEVER a good idea to kill an OPEN file. Close it properly (via killing
> > syslog) and then do what you want with the CLOSED file.
>
Not necessarily. The semantics of unlinking (what does it mean to kill
a file?) an open file are well-defined; i.e. the file contents are
removed only after the file is closed [ref.: Stevens, Advanced
Programming in the Unix Environment]. Says Stevens: "This property of
unlink is often used by a program to assure that a temporary file it
creates won't be left around in case the program crashes." Clearly if
it's often used, it can't be that bad an idea.
--
Jules d'Entremont ju...@icons.net
1491 Walkley Road, Ottawa Ont.
Random song lyric du jour:
"All the diamonds in this world that mean anything to me
Are conjured up by wind and sunlight sparkling off the sea"
Frank Smith
In article <hbonneyD...@netcom.com>,
Hugh Bonney <hbo...@netcom.com> wrote:
>Bryan Levin (ble...@netcom.com) wrote:
>: I remember asking this very question, several months ago.
>
>: The best response was: kill syslog FIRST, then truncate the file
>: (copy, save, etc).
>
>: Its NEVER a good idea to kill an OPEN file. Close it properly (via
>: killing syslog) and then do what you want with the CLOSED file.
>
>: well, you've been warned ;-) ;-)
>
> This job should be done by syslogd itself, shouldn't it?
> The max size of the file should be an invocation parameter.
> For files like wtmp with fixed length records the file
> could be circular; for the admin file automating one of
> these change proceedures is possible. If someone wants to
> backup the files the interval could be often enough that
> the backstop truncation process doesn't ordinarily kick in.
> It should never be possible to jam a system with admin files
> either neglected or running amok because of some malfunction.
>
perform the operation until it is closed even though it appears to
have done it immediately. If you rm /var/adm/messages an ls will
show it gone, but a df will show that the space is still used (and
growing) until syslog is killed.
I generally 'mv messages messages.todaysdate' folowed by a
'kill -HUP syslog_pid' (of course with the numeric PID of syslog),
which starts a new messages file.
frank
--
Frank Smith -- System Administrator E-mail: fsm...@spec.com
Systems & Processes Engineering Corp. (SPEC) Voice:(512) 306-1100 x154
401 Camp Craft Road Fax: (512) 306-1122
Austin, TX 78746-6558 Web: http://www.spec.com
Bruce Cook
I found that the most straight forward is:
# Kill the old backup off
rm /var/adm/messages.o
# Move the current into .o (Syslog is attached to the inode,
# and so diesn't care what the name of the file is, and so
# the output will be going to the .o file)
mv /var/adm/messages /var/adm/messages.o
# Create a new one, and start using it - syslog will create
# the log file if it doesn't already exist
kill -HUP `cat /etc/syslog.pid`
This has the advantage that it does no copying, and the
syslog is ALWAYS pointed at a file, and therefore no
messages get lost.
I've got a script which does this to all the log files in
/var/adm, keeping a two-stage backup. This script gets
run once a week from crontab.
Christian Duehl
Bryan Levin (ble...@netcom.com) wrote:
: I remember asking this very question, several months ago.
:
: The best response was: kill syslog FIRST, then truncate the file (copy, save,
: etc).
:
: Its NEVER a good idea to kill an OPEN file. Close it properly (via killing
: syslog) and then do what you want with the CLOSED file.
:
: The 'rename' thing may work - but if you catch it at the wrong time, well,
: you've been warned ;-) ;-)
Indeed, _be_ careful! I think you should kill more daemons than only syslogd.
(Because other write messages to /var/tmp/messages too, I think)
I think thyt deamons are klogd,... (I don't remember exatly and I'm working
under Unix in the moment).
I had to do this procedure too much times, now I have added a small (15MB)
partition only vor /var/adm.
Christian.
--
------------------------------------------------------------------------------
Christian Duehl e-mail: du...@math.uni-hamburg.de, du...@tu-harburg.d400.de
WWW-Homepage: http://www.math.uni-hamburg.de/home/duehl/homepage.html
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Bob Wickline
br...@nevyn.realize.com.au (Bruce Cook) wrote:
Gee I just do the following:
cat /dev/null >/var/adm/messages
Seems to do the trick!
__ /-----\ __ __ _____ ___ _ __
(__\/ _____ \/__) Bob "Wick" Wickline \ \ / /_ _/ __| |/ /
=( \___/ )= \ \/\/ / | | (__| ' <
\ ___ / wi...@galileo.net \_/\_/ |___\___|_|\_\
| / _ \ |
\ || || / http://www.why.net/users/wick
\|| ||/
\| |/
|_|
Gilles Seguin
ms5...@GEOMAT.math.uni-hamburg.de (Christian Duehl) wrote:
>Bryan Levin (ble...@netcom.com) wrote:
>: I remember asking this very question, several months ago.
>:
>: The best response was: kill syslog FIRST, then truncate the file (copy, save,
>: etc).
>:
>: Its NEVER a good idea to kill an OPEN file. Close it properly (via killing
>: syslog) and then do what you want with the CLOSED file.
>:
>: The 'rename' thing may work - but if you catch it at the wrong time, well,
>: you've been warned ;-) ;-)
If you look at the man page syslog.conf
# man syslog.conf
others files are in the same situations,
possible solution copy the file /etc/syslog.conf to
/etc/syslog.conf.old, an a others to /etc/syslog.conf.edit than modify
the last one. This file contains lines terminated by path file name.
For example:
in the file /etc/syslog.conf.edit modify the line
*.=debug /usr/adm/debug
to
*.=debug /var/log/debug.edit
after finishing modification copy /etc/syslog.conf.edit to
/etc/syslog.conf
#cp /etc/syslog.conf.edit /etc/syslog.conf
reboot
modify the offending files
#cp /etc/syslog.conf.old /etc/syslog.conf
reboot
gilles
Jason L Saunders
I find I haven't had any trouble doing
cat /dev/null > /var/adm/messages
to make it zero length.
Regards,
Jason
Hactar
In article <319D3454...@rpkhp9.mach.uni-karlsruhe.de>,
Andreas Muck <mu...@rpkhp9.mach.uni-karlsruhe.de> wrote:
>Gilles Seguin wrote:
>> #cp /etc/syslog.conf.edit /etc/syslog.conf
>> reboot
>> modify the offending files
>> #cp /etc/syslog.conf.old /etc/syslog.conf
>> reboot
>
>
># crontab -l | grep syslog
>00 00 1 * * /bin/killall klogd; /bin/killall syslogd;
>do.what.you.want.with.the.log-files; /usr/sbin/syslogd; /usr/sbin/klogd
Yeah, but then you might miss some messages while your messing with the
files. How about:
copy the files
modify the copies
rename the originals
rename the copies
kill -HUP syslogd klogd
HUP is the signal to make the daemon start over, right?
--
Eb...@Gate.Net / An idea that is not dangerous is unworthy
Eben King / of being called an idea at all. Oscar Wilde
He who will not reason is a bigot; he who cannot is a fool;
and he who dares not is a slave. Sir William Drummond
Wim Vandeputte
Hactar (eb...@gate.net) wrote:
: In article <319D3454...@rpkhp9.mach.uni-karlsruhe.de>,
: Andreas Muck <mu...@rpkhp9.mach.uni-karlsruhe.de> wrote:
: >Gilles Seguin wrote:
: >> #cp /etc/syslog.conf.edit /etc/syslog.conf
: >> reboot
: >> modify the offending files
: >> #cp /etc/syslog.conf.old /etc/syslog.conf
: >> reboot
: >
: >I am doing it like this:
: >
: ># crontab -l | grep syslog
: >00 00 1 * * /bin/killall klogd; /bin/killall syslogd;
: >do.what.you.want.with.the.log-files; /usr/sbin/syslogd; /usr/sbin/klogd
:
: Yeah, but then you might miss some messages while your messing with the
: files. How about:
yes... but for me cutting the logs means
cp /var/adm/messages /var/adm/messages1
> /var/adm/messages
1 becomes 2 2 becomes 3...... keep 'm for a week
: copy the files
: modify the copies
: rename the originals
: rename the copies
: kill -HUP syslogd klogd
:
: HUP is the signal to make the daemon start over, right?
yes, but there is no need for that.
you manipulate your logs (whatever)
then you cat /tmp/newlogs > /var/adm/messages
you 'pour them in the old ones' but the important part is that it's still
'the same file' technicaly speaking (inode?) the syslog process is writing to.
don't cp
don't mv
(well, I've seen some weird behaviour: news logs get pretty big here because
of multiple feeds so the logs were trimmed every night. The mistake made by
they news admin was to mv instead of cat. Result: the inn process kept
writing to the 'old file' all though its not listed any more in the dir listings
*but* still exists on disk.... result: I got suspicious to loose 30 megs every
day and couldn't find it... even diffed ls -laR listings and such...
ah... :-)