<div dir="ltr"><div>Hi,<br><br>the issue is that syslog-ng uses the destination IP address/port combination as an identifier to recover the queue when reloading syslog-ng, so it does have some issues (e.g. one borrowing the queue of the other, or using the same queue after reload). This is not good.<br>
<br>This could be solved with a long-discussed, explicit id() parameter, that would let the administrator assign a custom ID, which can be made different for the conflicting drivers, but that hasn&#39;t happened yet.<br><br>
</div><div>Using junctions and log expressions could help you to reorganize your configuration in a way that prevent this kind of conflict:<br><br><a href="https://bazsi.blogs.balabit.com/2012/01/syslog-ng-flexibility-improvements/">https://bazsi.blogs.balabit.com/2012/01/syslog-ng-flexibility-improvements/</a><br>
</div><div><br></div><div>Hope this helps.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 6, 2014 at 4:15 PM, David Hauck <span dir="ltr">&lt;<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">This morning Gergely Nagy wrote:<br>
&gt; David Hauck &lt;<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>&gt; writes:<br>
&gt;<br>
&gt;&gt; Couple things here:<br>
&gt;&gt; 1. If this is an error why doesn&#39;t &#39;syslog-ng -s&#39; indicate it as such?<br>
&gt;<br>
&gt; Because -s checks for syntax only, and this is not a syntax error, it&#39;s one level higher.<br>
<br>
</div>OK.<br>
<div class=""><br>
&gt;&gt; 2. Other than the error, things appear to function correctly. Why is this?<br>
&gt;<br>
&gt; That&#39;d be a bit hard to explain without going into low-level details,<br>
&gt; but I&#39;ll try: it works because of luck, mostly. UDP destinations will<br>
&gt; not trip over each other when used like this. If you&#39;d try that with files, all hell would break loose.<br>
<br>
</div>OK, thanks, having some understanding of how the low level implementation works does help since I don&#39;t remember this constraint being discussed in the manual/docs (but I may have missed something there?). Initially it also wasn&#39;t clear that these destinations weren&#39;t combined at a high level in the implementation so that they, for example, operated within a &quot;pipeline&quot; and thereby enforced a &quot;single-writer&quot; paradigm. Either way, and as you say, this is required for file destinations, but certainly not for network destinations (even in the disconnect case).<br>

<br>
In fact, my log() statements with the referenced destinations are complex enough that I may need to rely on the multiple network destination specification capability anyway since combining these as you suggest would make maintenance of the configuration even more difficult (there&#39;s a tangle of rules/conditions associated with one of the destination log() statements).<br>

<div class=""><br>
&gt;&gt; 3. Other blocks do not require that their contents contain unique<br>
&gt;&gt; statements. For example, I can create filter blocks that have<br>
&gt;&gt; statements that intersect. Why not destination blocks?<br>
&gt;<br>
&gt; Because filters generally don&#39;t have state, so they can&#39;t conflict<br>
&gt; with each other, they can work independently. For destinations, that&#39;s not the case. For example, if you&#39;d have something like this:<br>
&gt;<br>
&gt; destination d_1 { file(&quot;/var/log/some.log&quot;); udp(...); }; destination<br>
&gt; d_2 { file(&quot;/var/log/some.log&quot;); tcp(...); };<br>
&gt;<br>
&gt; That would break horribly, as two threads would try to write to the<br>
&gt; same file, and would write over each other, resulting in garbage. That<br>
&gt; doesn&#39;t happen with network destinations, but those have different<br>
&gt; issues. For example, if a network target goes down, and you had<br>
&gt; duplicates in your config, then they&#39;d notice the target being down separately, increasing the chance you&#39;ll loose logs. If you had one target, and bound it to various sources in a log{} statement instead, then you&#39;d only have one instance of the driver.<br>

<br>
</div>I&#39;m wondering if there might be other issues associated with multiple (common) network destinations (you only mention one as an example)? The example you mention isn&#39;t relevant in my case. Whether the network destination is a combined statement/driver or not the payload includes single packets, which are written separately, no? If this is the case it wouldn&#39;t matter which packet send detected the network error - one or the other would get lost in both cases.<br>

<br>
Thanks,<br>
-David<br>
<div class="HOEnZb"><div class="h5">______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Bazsi
</div>