redirect console error to email?
Nathan Kahn
display on a terminal instead. But is there a way to redirect them
to an email message?
If I had my druthers I would have all console errors emailed to me,
rather than displayed on the console screen. (Or in addition to being
display in the console screen.)
??
Nathan
Bela Lubkin
Console messages get sent through syslog; with the default
configuration, they end up in /usr/adm/syslog. You could write a
program that watches for new lines in /usr/adm/syslog and emails them
somewhere.
>Bela<
Nathan Kahn
> Nathan Kahn wrote:
>
> > Checking old messages here I see that console errors can be made to
> > display on a terminal instead. But is there a way to redirect them
> > to an email message?
> >
> > If I had my druthers I would have all console errors emailed to me,
> > rather than displayed on the console screen. (Or in addition to being
>
> Console messages get sent through syslog; with the default
> configuration, they end up in /usr/adm/syslog. You could write a
> program that watches for new lines in /usr/adm/syslog and emails them
> somewhere.
Ah that's a good idea. Except I would want to use /usr/adm/messages,
since syslog includes other stuff I don't want to know about.
Emailing 'tail messages' to me would be great.
So I think I'd want to run something hourly in cron that would do, in
essence:
1. Look at date for /usr/adm/messages
2. If it's > 60 minutes from the current date, do nothing
3. If it's < 60 minutes (i.e. if it's changed in the last hour), send
email to nathan that includes the text from 'tail messages'
But I haven't a clue how to get started with this script. Pointers?
I've never written an If/Then script, now that I think about it. Done
other rudimentary stuff, but never this.
Nathan
Jukka Inkeri
>
>
> Ah that's a good idea. Except I would want to use /usr/adm/messages,
> since syslog includes other stuff I don't want to know about.
>
> Emailing 'tail messages' to me would be great.
>
> So I think I'd want to run something hourly in cron that would do, in
> essence:
>
> 1. Look at date for /usr/adm/messages
> 2. If it's > 60 minutes from the current date, do nothing
> 3. If it's < 60 minutes (i.e. if it's changed in the last hour), send
> email to nathan that includes the text from 'tail messages'
>
try something about ...
#!/usr/sh
# start this ex with rc2
# name this script ex. /etc/rc2.d/S99myalert
mailit()
{
echo "$*" | mail -s "alert:message $(hostname)" so...@xx.xxx
}
#--main body---
# open log file with tail -f and pipe all new messages
tail -c 1 -f /var/adm/messages | while read line
do
# parse interesting lines ex. with case and mailit
case "$line" in
*someinteresting*) mailit "$line" ;;
*some_else_message*) mailit "$line" ;;
*) ;; # not interesting
esac
done
-jukka-
# my email ? try next cmd
echo "jukka_xnkerx:1wot_biz" | tr "_:x1" ".@ia"
UBW
wrote:
You may wish to get these messages from the output of the dmesg
command, either only the most recent message or all messages since
dmesg was run last. man dmesg for usage.
UBW
Nathan Kahn
> command, either only the most recent message or all messages since
> dmesg was run last. man dmesg for usage.
> UBW
I didn't know that command existed - it's perfect.
I'll just run that out of cron at regular intervals then, output
mailed to me. Problem solved :-)
I wish they could all be this painless . . .
Nathan
Nathan Kahn
> command, either only the most recent message or all messages since
> dmesg was run last. man dmesg for usage.
> UBW
Question - that man page references also /dev/error, and I noticed
that /dev/error specifically doesn't log "panic" messages. Will dmesg
still show me panic messages?
Nathan
Bela Lubkin
`dmesg` is an _old_ utility, by which I mean: it came on the tape from
AT&T when SCO got the rights to ship Unix, back in 1988 or so. The
makefiles tell it to compile, so it gets compiled; it's "always been
there", so we ship it. But it is not integrated with the rest of the
system, has not been actively maintained. I was surprised to find that
it does seem to do what it claims; I would not be at all surprised to
find a bunch of caveats, like "but when you run it, those messages fail
to get logged to /usr/adm/messages or syslog"; or "but if more than
[some very small amount, like 1K] worth of messages have gone by since
the last run, the excess are lost". I don't _know_ that any such issues
exist, I just have a vague sense that they probably do.
There are many other OSes that were originally based on some rev of AT&T
Unix -- SCO UnixWare, for instance, and Solaris -- where `dmesg` is a
well-known and well supported utility. This is one of those instances
where people moving from one system to another can be tricked by what
are, essentially, false cognates.
Again, I do not specifically _know_ of any problem with `dmesg`. I just
want to point out that it hasn't been actively maintained and many
things have changed around it.
Now, specifically about panics: none of the logging utilities captures
panic messages. During a panic the kernel tries to avoid using all
complex facilities like the filesystem code, for fear that it might be
that very code which is corrupted and causing the panic. Most panics
will write a crash dump (which is done with a small bit of code that
relies only on itself and the disk driver to be functioning -- much
smaller critical code path than if it relied on the filesystem and
buffer cache). The panic message can be found in the dump, e.g. by
running `crash` on it. After a panic, you can automatically capture the
panic message by doing something like:
echo panic | crash -d /dev/swap
You can find code that decides whether a panic dump is in /dev/swap, in
/etc/dumpsave. You might also want a strategy for deciding whether
panic information about a particular dump has already been captured
(that is, suppose you panic, reboot, capture the panic message, then do
a normal shutdown, reboot again -- if you haven't swapped during that
sequence, the dump will still be there and you'll capture another panic
message. It would be better to only capture each panic once.)
>Bela<
Rainer Zocholl
>Nathan Kahn wrote:
>>
>> Emailing 'tail messages' to me would be great.
>>
>#!/usr/sh
># start this ex with rc2
># name this script ex. /etc/rc2.d/S99myalert
>mailit()
>{
> echo "$*" | mail -s "alert:message $(hostname)" so...@xx.xxx
>}
>#--main body---
># open log file with tail -f and pipe all new messages
>tail -c 1 -f /var/adm/messages | while read line
>do
> # parse interesting lines ex. with case and mailit
> case "$line" in
> *someinteresting*) mailit "$line" ;;
> *some_else_message*) mailit "$line" ;;
> *) ;; # not interesting
> esac
>done
Just a hint:
Be careful with a "tail -f" if you use somekind
of log rotate utilities.
Some renames the "message" to a new name and hup syslog...
The "tail" will of cause not follow the new generated file
called "messages" but still the old, which is now no more active.
This can happen, but must n't. So be sure to check it.
There are special tools that handles that problem right
without missing any line. (Sorry have no link present).