summaryrefslogtreecommitdiffstats
path: root/doc/v5compatibility.html
blob: fc4289c507df50fa60504307e3a8e82b7e1709fd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>Compatibility notes for rsyslog v5</title>
</head>
<body>
<h1>Compatibility Notes for rsyslog v5</h1>
<p><small><i>Written by <a href="http://www.gerhards.net/rainer">Rainer Gerhards</a>
(2009-07-15)</i></small></p>
<p>The changes introduced in rsyslog v5 are numerous, but not very intrusive.
This document describes things to keep in mind when moving from v4 to v5. It 
does not list enhancements nor does it talk about compatibility concerns introduced
by earlier versions (for this, see their respective compatibility documents).
<h2>HUP processing</h2>
<p>The $HUPisRestart directive is supported by some early v5 versions, but has been removed
in 5.1.3 and above.  That means that restart-type HUP processing is no longer
available. This processing was redundant and had a lot a drawbacks. 
For details, please see the
<a href="v4compatibility.html">rsyslog v4 compatibility notes</a> which elaborate
on the reasons and the (few) things you may need to change.
<p>Please note that starting with 5.8.11 HUP will also requery the local hostname.
<h2>Queue on-disk format</h2>
<p>The queue information file format has been changed. When upgrading from v4 to
v5, make sure that the queue is emptied and no on-disk structure present. We did
not go great length in understanding the old format, as there was too little demand
for that (and it being quite some effort if done right).
<h2>Queue Worker Thread Shutdown</h2>
<p>Previous rsyslog versions had the capability to &quot;run&quot; on zero queue worker
if no work was required. This was done to save a very limited number of resources. However,
it came at the price of great complexity. In v5, we have decided to let a minium of one
worker run all the time. The additional resource consumption is probably not noticable at
all, however, this enabled us to do some important code cleanups, resulting in faster
and more reliable code (complex code is hard to maintain and error-prone). From the
regular user's point of view, this change should be barely noticable. I am including the
note for expert users, who will notice it in rsyslog debug output and other analysis tools.
So it is no error if each queue in non-direct mode now always runs at least one worker
thread.
</body></html>