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. > > 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. > > One thing that I will note. If I am understanding the configuration > correctly, what you are doing is writing to the database, then setting up a > disk queue for the write to the file (with the old style config, they > parameters only affect things after them in the config file) I see. The file was only for testing. > > 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. > > 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? > > 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 Thanks for answering, Axel --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius _______________________________________________ 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.
