[rsyslog] rsyslog 4.5.x queue file cleanup?

[Marc Schiffbauer]

[ 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