Lo and behold, I created /var/log/rsyslog directory, restarted the process as documented earlier and I'm already seeing logs dumped to files in that subdirectory
[root@client rsyslog]# pwd /var/log/rsyslog [root@client rsyslog]# ls -al total 6556 drwxr-x--- 2 root wheel 4096 Feb 12 16:29 . drwxr-xr-x 6 root root 4096 Feb 12 16:08 .. -rw------- 1 root root 1048956 Feb 12 16:18 failqueue-loghost2.00000001 -rw------- 1 root root 1048713 Feb 12 16:20 failqueue-loghost2.00000002 -rw------- 1 root root 1048662 Feb 12 16:23 failqueue-loghost2.00000003 -rw------- 1 root root 1048680 Feb 12 16:26 failqueue-loghost2.00000004 -rw------- 1 root root 1048961 Feb 12 16:27 failqueue-loghost2.00000005 -rw------- 1 root root 1048956 Feb 12 16:29 failqueue-loghost2.00000006 -rw------- 1 root root 352328 Feb 12 16:29 failqueue-loghost2.00000007 What a beautiful thing it is. Sorry for the false alarm. On Feb 12, 2011, at 4:22 PM, Todd Michael Bushnell wrote: > I configured reliable forwarding in accordance with instructions here: > http://www.rsyslog.com/doc/rsyslog_reliable_forwarding.html > > Version: rsyslog-3.22.1-3.el5_5.1 > > Configuration: > > # forward to remote host, queueing to local disk if host is down and memory > fills up > # work (spool) files directory > $WorkDirectory /var/log/rsyslog > # start forwarding rule - loghost2 > # in-memory queue; set for asynchronous processing (?) > $ActionQueueType LinkedList > # failover queue filename; also enables disk mode > $ActionQueueFileName failqueue-loghost2 > # infinite retries on insert failure > $ActionResumeRetryCount -1 > # save in-memory data if rsyslog shuts down > $ActionQueueSaveOnShutdown on > # remote logging of everything > *.* @@loghost2:5140 > > I wanted to test its functionality before going into production. > > First, I used iptables to block access to the syslog port on the central > syslog (syslog-ng) server, simulating a down syslog server: > # on loghost2 > /sbin/iptables -I INPUT -p tcp --destination-port 5140 -j REJECT > --reject-with icmp-admin-prohibited > > I then ran logger through a loop to start creating a pile of messages on the > rsyslog client: > for i in {1..1000000}; do logger -t tmbtest -p local1.info "this is a test > $i"; done > > I ran this loop twice in an effort to sufficiently fill up memory and > initiate dump to disk. While this loop was running I verified that memory > consumption for the rsylogd process on the client was increasing. It > eventually got to this point: > root 20263 0.2 77.8 2537008 1603712 ? Sl Feb10 6:09 > /sbin/rsyslogd -c 3 > > To be honest, I don't know how much memory it will consume before dumping to > disk (feel free to school me on this) so I figured I'd keep going until I saw > /var/log/rsyslog directory and files created. This never happened and my > second iteration stopped at about 600k and I saw some memory fork errors > (though they dumped only to standard error, not log, so I lost them (sorry)). > > Dump to disk having failed, I next wanted to see if rsyslog would at least > resume forward to remote host when it came back up (dumping whatever was in > memory to central syslog server). I restarted iptables on the syslog server > to restore access to the port, but no logs were forwarded from the rsyslog > client. > > Lastly, I restarted rsyslog, hoping that I would see a dump to disk but this > failed as well. > > I'm sure it's something I'm doing incorrectly. Would appreciate some > guidance. Who knows, maybe I just need to create the /var/log/rsyslog > directory (assumed rsyslog would create it). While I'm waiting for feedback, > I'll probably give that a shot. Thanks. > > Todd > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
