Weblogs for oxtan
#4
Posted by oxtan on Sat 21 Jan 2006 at 21:38
Hi,
just got back from a nice dinner and see this email from logcheck:
Jan 21 13:54:48 tux kernel: e: [<c013e777>] [<c013e860>] [<c0135273>] [<c010726b>]
Jan 21 13:54:48 tux kernel: nmbd S D15E4560 4996 2814 1 2816 2817 25577 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01068a9>] [<c0111098>] [<c0111020>] [<c013ed07>] [<c0144c09>]
Jan 21 13:54:48 tux kernel: [<c01450a9>] [<c010726b>]
Jan 21 13:54:48 tux kernel: nmbd S C137E1E0 3404 2816 2814 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c013623f>] [<c013e777>] [<c013e860>] [<c0135273>] [<c010726b>]
Jan 21 13:54:48 tux kernel: smbd S CF21CA60 1376 2817 1 2818 32518 2814 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c012e965>] [<c01110e5>] [<c0106d41>] [<c013ed07>] [<c0144c09>]
Jan 21 13:54:48 tux kernel: [<c01450a9>] [<c010726b>]
Jan 21 13:54:48 tux kernel: smbd S 00000000 0 2818 2817 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c010cc72>] [<c010726b>]
Jan 21 13:54:48 tux kernel: bash S 000001F0 1632 32518 1 21592 32603 2817 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01176b1>] [<c0117995>] [<c010726b>]
Jan 21 13:54:48 tux kernel: bash S 000001F0 488 32603 1 21591 26817 32518 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01176b1>] [<c0117995>] [<c010726b>]
Jan 21 13:54:48 tux kernel: bash S C02D97F8 1632 21591 32603 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c013e777>] [<c01457c8>] [<c0145921>] [<c01344ed>] [<c0134418>]
Jan 21 13:54:48 tux kernel: [<c01347c3>] [<c010726b>]
Jan 21 13:54:48 tux kernel: bash S 00001000 0 21592 32518 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c016e8aa>] [<c013e777>] [<c01457c8>] [<c0145921>] [<c01344ed>]
Jan 21 13:54:48 tux kernel: [<c0134418>] [<c01347c3>] [<c010726b>]
Jan 21 13:54:48 tux kernel: tail S 00000000 0 26817 1 20207 32603 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c016e8aa>] [<c013e777>] [<c01457c8>] [<c0145921>] [<c01344ed>]
Jan 21 13:54:48 tux kernel: [<c0134418>] [<c01347c3>] [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld_safe S 000001F0 0 19574 873 19576 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01176b1>] [<c0117995>] [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld S D35FE520 2656 19575 19574 19829 19576 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01110e5>] [<c0278bde>] [<c02167ec>] [<c0144c09>] [<c01450a9>]
Jan 21 13:54:48 tux kernel: [<c010726b>]
Jan 21 13:54:48 tux kernel: logger S C6C69420 824 19576 19574 19575 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c013e777>] [<c013e860>] [<c0135273>] [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld S 00000000 0 19829 19575 21030 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c0111098>] [<c013ed07>] [<c0111020>] [<c0145394>] [<c0145564>]
Jan 21 13:54:48 tux kernel: [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld S 00000286 0 19830 19829 19927 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c0117d5b>] [<c01061ab>] [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld S C2D6E000 0 19927 19829 20215 19830 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01061ab>] [<c010726b>]
Jan 21 13:54:48 tux kernel: apache S C0331B70 0 20207 1 29068 10324 26817 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c0111098>] [<c0111020>] [<c0144c09>] [<c01450a9>] [<c0117995>]
Jan 21 13:54:48 tux kernel: [<c010726b>]
It goes on for about 200 lines, then at 13:55 it stops and everything continues as usually, no other messages. Any clues?
just got back from a nice dinner and see this email from logcheck:
Jan 21 13:54:48 tux kernel: e: [<c013e777>] [<c013e860>] [<c0135273>] [<c010726b>]
Jan 21 13:54:48 tux kernel: nmbd S D15E4560 4996 2814 1 2816 2817 25577 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01068a9>] [<c0111098>] [<c0111020>] [<c013ed07>] [<c0144c09>]
Jan 21 13:54:48 tux kernel: [<c01450a9>] [<c010726b>]
Jan 21 13:54:48 tux kernel: nmbd S C137E1E0 3404 2816 2814 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c013623f>] [<c013e777>] [<c013e860>] [<c0135273>] [<c010726b>]
Jan 21 13:54:48 tux kernel: smbd S CF21CA60 1376 2817 1 2818 32518 2814 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c012e965>] [<c01110e5>] [<c0106d41>] [<c013ed07>] [<c0144c09>]
Jan 21 13:54:48 tux kernel: [<c01450a9>] [<c010726b>]
Jan 21 13:54:48 tux kernel: smbd S 00000000 0 2818 2817 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c010cc72>] [<c010726b>]
Jan 21 13:54:48 tux kernel: bash S 000001F0 1632 32518 1 21592 32603 2817 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01176b1>] [<c0117995>] [<c010726b>]
Jan 21 13:54:48 tux kernel: bash S 000001F0 488 32603 1 21591 26817 32518 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01176b1>] [<c0117995>] [<c010726b>]
Jan 21 13:54:48 tux kernel: bash S C02D97F8 1632 21591 32603 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c013e777>] [<c01457c8>] [<c0145921>] [<c01344ed>] [<c0134418>]
Jan 21 13:54:48 tux kernel: [<c01347c3>] [<c010726b>]
Jan 21 13:54:48 tux kernel: bash S 00001000 0 21592 32518 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c016e8aa>] [<c013e777>] [<c01457c8>] [<c0145921>] [<c01344ed>]
Jan 21 13:54:48 tux kernel: [<c0134418>] [<c01347c3>] [<c010726b>]
Jan 21 13:54:48 tux kernel: tail S 00000000 0 26817 1 20207 32603 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c016e8aa>] [<c013e777>] [<c01457c8>] [<c0145921>] [<c01344ed>]
Jan 21 13:54:48 tux kernel: [<c0134418>] [<c01347c3>] [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld_safe S 000001F0 0 19574 873 19576 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01176b1>] [<c0117995>] [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld S D35FE520 2656 19575 19574 19829 19576 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01110e5>] [<c0278bde>] [<c02167ec>] [<c0144c09>] [<c01450a9>]
Jan 21 13:54:48 tux kernel: [<c010726b>]
Jan 21 13:54:48 tux kernel: logger S C6C69420 824 19576 19574 19575 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c013e777>] [<c013e860>] [<c0135273>] [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld S 00000000 0 19829 19575 21030 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c0111098>] [<c013ed07>] [<c0111020>] [<c0145394>] [<c0145564>]
Jan 21 13:54:48 tux kernel: [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld S 00000286 0 19830 19829 19927 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c0117d5b>] [<c01061ab>] [<c010726b>]
Jan 21 13:54:48 tux kernel: mysqld S C2D6E000 0 19927 19829 20215 19830 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c01061ab>] [<c010726b>]
Jan 21 13:54:48 tux kernel: apache S C0331B70 0 20207 1 29068 10324 26817 (NOTLB)
Jan 21 13:54:48 tux kernel: Call Trace: [<c0111098>] [<c0111020>] [<c0144c09>] [<c01450a9>] [<c0117995>]
Jan 21 13:54:48 tux kernel: [<c010726b>]
It goes on for about 200 lines, then at 13:55 it stops and everything continues as usually, no other messages. Any clues?
#3
Posted by oxtan on Tue 3 Jan 2006 at 19:53
Hi,
I am trying to get a broader view of our network. In order to do that we are already logging everything to a central logserver (even the evil empire servers, amazing).
The next step is logging to a database (mysql). I know that syslog-ng permits logging to a database, but I already have a perl script that parses the logs and fills the database. What I would like to test is logging to a fifo as well as to syslog, and according to the fine manual, this appears to be possible. I do not get it to work though. This is what I do:
# mkfifo /tmp/test
# ls -l /tmp/test
prw-r----- 1 root adm 0 Jan 3 20:38 /tmp/test
And in /etc/syslog.conf I have this:
. | /tmp/test
Obviously, after modifying syslog.conf I stop and start the syslogd daemon.
I should be getting plenty of info in /tmp/test, but it remains empty, syslog logs as usual.
Any clues as to what I am missing here?
I am trying to get a broader view of our network. In order to do that we are already logging everything to a central logserver (even the evil empire servers, amazing).
The next step is logging to a database (mysql). I know that syslog-ng permits logging to a database, but I already have a perl script that parses the logs and fills the database. What I would like to test is logging to a fifo as well as to syslog, and according to the fine manual, this appears to be possible. I do not get it to work though. This is what I do:
# mkfifo /tmp/test
# ls -l /tmp/test
prw-r----- 1 root adm 0 Jan 3 20:38 /tmp/test
And in /etc/syslog.conf I have this:
. | /tmp/test
Obviously, after modifying syslog.conf I stop and start the syslogd daemon.
I should be getting plenty of info in /tmp/test, but it remains empty, syslog logs as usual.
Any clues as to what I am missing here?
#1
Posted by oxtan on Sat 30 Jul 2005 at 08:25
:-)
Sorry, too poor to do that.
Anyway, if you feel bored and would like to share with us (there are lots of people reading this, only too few making part of it, do not despair) how to use lvm with debian, that would be great!
I must check if somebody has already explained how to use autofs and shfs/lufs in here. If not, then I'll try and do that asap.
Sorry, too poor to do that.
Anyway, if you feel bored and would like to share with us (there are lots of people reading this, only too few making part of it, do not despair) how to use lvm with debian, that would be great!
I must check if somebody has already explained how to use autofs and shfs/lufs in here. If not, then I'll try and do that asap.
[0 Comments
|
]
]