On Thu, 9 May 2013, Axel Rau wrote:
Am 09.05.2013 um 05:30 schrieb David Lang <[email protected]>:
On Wed, 8 May 2013, Axel Rau wrote:
The following configuration produces tcp traffic per event, but nothing is
logged to the file (remote.log) or in the database at the server:
This is the client config (rsyslog 4.6.4 on OpenBSD 5.3):
---
$WorkDirectory /var/rsyslog # where to place spool files
$ActionQueueFileName qf # unique name prefix for spool files
$ActionQueueMaxDiskSpace 10g # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList # run asynchronously
$ActionResumeRetryCount -1 # infinite retries if host is down
$ModLoad omrelp
*.* :omrelp:192.168.220.131:601
--
?and this is the server side (7.2.4 on FreeBSD 9.1):
---
module(load="imrelp")
input(type="imrelp" port="601")
$ModLoad ompgsql.so
if $fromhost-ip != '127.0.0.1' then {
*.* :ompgsql:host,db,login,none;
$ActionQueueFileName dbq # unique name prefix for spool files
$ActionQueueMaxDiskSpace 10g # 10gb space limit (use as much as
possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList # run asynchronously
$ActionResumeRetryCount -1 # infinite retries if host is down
*.* /var/log/remote.log
~
}
---
Wenn I shutdown the server, all missing events are logged to both targets.
So, if I understand what you are saying, log messages are generated and you see
the network traffic for them, but nothing is showing up in postgres or
remote.log until you stop rsyslog on the receiving system, but when you issue
the shutdown, everything is getting logged both in postgres and in remote.log
Is this correct?
Yes. Not always does shutdown trigger recording of the backlog.
Ok thanks, that means I'm understanding the problem properly
How many messages are we talking about being queued?
About 200. (This is a test setup).
How long do you wait to see if they are written?
12 hours.
Is data ending up in the disk queue during the time they are 'missing'?
No, $WorkDirectory is still empty.
Interesting: If I remove the $Action statements, the problem does not go away!
I would be interested to know if doing a kill -HUP on the server causes the
logs to be written.
No, it does not.
What happens if you reverse the placement of the postgres and remote.log lines?
If this causes everything to be written to remote.log immediatly, but nothing
to postgres until shutdown time, I would be looking _very_ closely at the
postgres connection and configuration.
The PostgreSQL configuration is ok, because it receives exactly the same rows
as remote.log.
If I completely remove the ompgsql, nothing changes.
Interesting. I was speculating that it was hanging on the postgres write and
therefor never getting to the actionqueue or local file stuff
The final step I would try would be to run the server in debug mode and see if
the debug messages explain why it's not logging the messages as they arrive.
But I would suggest going through the other things first.
If I start rsyslogd with -d, it just displays lots of internals and then
detaches from the tty.
Is it required to make a debug build?
no, you don't need to do a debug build, but you may need to start it with -n as
well as -d so that it doesn't detach from the tty
David Lang
There is one importing observation on the client side:
netstat shows a lot of packets, queued in the receive queue, until shutdown of
one side:
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 976 0 192.168.220.130.3844 192.168.220.131.601 ESTABLISHED
hmm, this could indicate a problem with RELP. It may be worth trying to use TCP
on port 601 instead of RELP on 601 to see if it makes a difference.
At this point, I'm out of obvious ideas, so the next step is going to be to look
at the debug output. you don't need to run a lot of messages through it, you
will probably see what's going on here with just one or two messages arriving on
the server.
The only thing I'm pretty sure about here is that the problem is not caused by
the mixing of config styles.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
