[ sorry, attachement in first try was too big, next try with shortened debug log ]
Am Dienstag, 13. Oktober 2009 16:35:49 schrieb Rainer Gerhards: > > As it seems, rsyslog will not write a .qi file in all cases. > > not always, but it should always write them when necessary ;) > > > New tests were not all successful (with rsyslog under load): > > OK => spooling while DB is offline > > OK => reconnect to DB > > OK => despooling while still under load and spooling to disk > > > > Now the following produced "stale" queue files and a loss of messages I > > guess: > > NOT OK => despooling while under load and while spooling to disk, > > then stopping rsyslogd > > (stopped via /etc/init.d/syslog stop) > > -> no .qi file has been created! > > after making sure there are no more rsyslog processes I started it > > again. > > The spool files will not be cleared (no load anymore and DB started of > > course) > > > > bug? > > Smells like one. I re-checked your config, I think it does not include a > directive to tell the engine to persist messages on shutdown. Oh, I did not know that there is a directive for it.. good to know. > Even if it > does not do that, it should clean up the files. A debug log would be most > useful. Trying to produce one it seems a difficult task to me because rsyslogd seems to behave completely different when in debug mode... In one console I started: /sbin/rsyslogd -c 4 -f /etc/rsyslog.conf -d &> rsyslog-debug.log Then I stopped postgres: /etc/init.d/postgresql stop Now I started a logger loop: while true; do logger -t spool-test "no real message here... (PID=$$)"; done After the first spool file is being created I stop the loop again. Now I want to stop rsyslogd by calling "killall rsyslogd" I had to call this several times before rsyslogd really did exit. After the first attemots it seemed that it did try to reach the DB in a loop and did not attempt to prepare for exit. See the log attached. Is this helpful? -Marc > > Note that the v4 engine, and more so the v5 engine, has had a number of > important changes, and people only gradually begin to utilize it in > practice. The past couple of month, I had comparatively few bug reports, > but the past three weeks or so people tend to adopt the new features and > consequently the "bug rate" goes up. This is good, as it helps iron out > things, but it is also somewhat bad, because I need to prioritize work and > for some bugs that means I have not to touch too many things at once. > > Looking forward for additional information. > > Rainer > PS: please all keep contributing bug reports! It is really useful to have > them (even better if they are timely ;)) as my lab can not cover everything > practice does ;) > -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux
_______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
