<p dir="ltr">A workaround is to use a DNS alias, or different port. The Id generated by syslog-ng contains both.</p>
<div class="gmail_quote">On Jun 11, 2014 5:18 PM, "David Hauck" <<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Evan,<br>
<br>
On Wednesday, June 11, 2014 8:16 AM, <a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a> wrote:<br>
> Reorganizing the log configuration with junctions helps in some<br>
> circumstances. In my case I need to use a different template depending<br>
> on the source of the message (from a specific file source) so I need<br>
> to use the same destination IP/port, but defined with a different<br>
> syslog-ng "destination" specification so that I can use a different template.<br>
><br>
> This results in the same problem that I can't work around by using a<br>
> different junction/log structure.<br>
<br>
Yes, interesting. This restriction is turning out to be somewhat unfortunate. I'm still trying to figure out how to wedge this constraint into my configuration...<br>
<br>
Thanks,<br>
-David<br>
<br>
> Evan.<br>
><br>
> On 06/10/2014 11:51 PM, Balazs Scheidler wrote:<br>
>> Hi,<br>
>><br>
>> the issue is that syslog-ng uses the destination IP address/port<br>
>> combination<br>
> as an identifier to recover the queue when reloading syslog-ng, so it<br>
> does have some issues (e.g. one borrowing the queue of the other, or<br>
> using the same queue after reload). This is not good.<br>
>><br>
>> This could be solved with a long-discussed, explicit id() parameter,<br>
>> that<br>
> would let the administrator assign a custom ID, which can be made<br>
> different for the conflicting drivers, but that hasn't happened yet.<br>
>><br>
>> Using junctions and log expressions could help you to reorganize your<br>
>> configuration in a way that prevent this kind of conflict:<br>
>><br>
>> <a href="https://bazsi.blogs.balabit.com/2012/01/syslog-ng-flexibility-improv" target="_blank">https://bazsi.blogs.balabit.com/2012/01/syslog-ng-flexibility-improv</a><br>
>> em<br>
>> ents/<br>
>><br>
>> Hope this helps.<br>
>><br>
>><br>
>> On Fri, Jun 6, 2014 at 4:15 PM, David Hauck <<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a><br>
>> <mailto:<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>>> wrote:<br>
>><br>
>> This morning Gergely Nagy wrote:<br>
>>> David Hauck <<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a> <mailto:<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>>><br>
>>> writes:<br>
>>><br>
>>>> Couple things here:<br>
>>>> 1. If this is an error why doesn't 'syslog-ng -s' indicate it as such?<br>
>>><br>
>>> Because -s checks for syntax only, and this is not a syntax<br>
>> error, it's one level higher.<br>
>><br>
>> OK.<br>
>>>> 2. Other than the error, things appear to function<br>
>> correctly. Why is<br>
> this?<br>
>>><br>
>>> That'd be a bit hard to explain without going into low-level details,<br>
>>> but I'll try: it works because of luck, mostly. UDP destinations will<br>
>>> not trip over each other when used like this. If you'd try<br>
>> that with files, all hell would break loose.<br>
>><br>
>> OK, thanks, having some understanding of how the low level<br>
> implementation works does help since I don't remember this constraint<br>
> being discussed in the manual/docs (but I may have missed something<br>
> there?). Initially it also wasn't clear that these destinations<br>
> weren't combined at a high level in the implementation so that they,<br>
> for example, operated within a "pipeline" and thereby enforced a<br>
> "single-writer" paradigm. Either way, and as you say, this is required<br>
> for file destinations, but<br>
>> certainly not for network destinations (even in the disconnect case).<br>
>><br>
>> In fact, my log() statements with the referenced destinations<br>
>> are<br>
> complex enough that I may need to rely on the multiple network<br>
> destination specification capability anyway since combining these as<br>
> you suggest would make maintenance of the configuration even more<br>
> difficult (there's a tangle of rules/conditions associated with one of the destination log() statements).<br>
>><br>
>>>> 3. Other blocks do not require that their contents contain unique<br>
>>>> statements. For example, I can create filter blocks that have<br>
>>>> statements that intersect. Why not destination blocks?<br>
>>><br>
>>> Because filters generally don't have state, so they can't conflict<br>
>>> with each other, they can work independently. For<br>
>> destinations, that's<br>
> not the case. For example, if you'd have something like this:<br>
>>><br>
>>> destination d_1 { file("/var/log/some.log"); udp(...); }; destination<br>
>>> d_2 { file("/var/log/some.log"); tcp(...); };<br>
>>><br>
>>> That would break horribly, as two threads would try to write to the<br>
>>> same file, and would write over each other, resulting in garbage. That<br>
>>> doesn't happen with network destinations, but those have different<br>
>>> issues. For example, if a network target goes down, and you had<br>
>>> duplicates in your config, then they'd notice the target<br>
>> being down<br>
> separately, increasing the chance you'll loose logs. If you had one<br>
> target, and bound it to various sources in a log{} statement instead,<br>
> then you'd only have one instance of the driver.<br>
>><br>
>> I'm wondering if there might be other issues associated with<br>
>> multiple<br>
> (common) network destinations (you only mention one as an example)?<br>
> The example you mention isn't relevant in my case. Whether the network<br>
> destination is a combined statement/driver or not the payload includes<br>
> single packets, which are written separately, no? If this is the case<br>
> it wouldn't matter which packet send detected the network error - one<br>
> or the other would get lost in both cases.<br>
>><br>
>> Thanks,<br>
>> -David<br>
> __________________________________________________________<br>
> ____________________<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:<br>
>> <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>
>><br>
>><br>
>> --<br>
>> Bazsi<br>
>><br>
>><br>
>><br>
> __________________________________________________________<br>
> ____________<br>
>> ________ Member info:<br>
>> <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
>> Documentation:<br>
>> <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>
><br>
><br>
______________________________________________________________________________<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>
</blockquote></div>