I need to check, but I believe that may be an issue. I'll have to check
my kernel/toolchain, and the configure output. I know there was a time
frame when stable rsyslog did not compile due to this issue, and then I
assumed that it had been removed when it started to compile again. I'll
check tomorrow.
thx
On 5/31/2011 11:51 PM, Rainer Gerhards wrote:
I also don't recall if I mentioned this, but this is also on ARM.
I assume everything else works well? I am asking because I want to make sure
we do not have problems with atomic instructions replacements.
Rainer
On 5/31/2011 11:48 PM, Rory Toma wrote:
That did not work, either. Is this behaviour compiled in by default,
or is there a compile/config time flag that I need to set?
On 5/31/2011 11:24 PM, Rainer Gerhards wrote:
Sorry, I was so focused on the bug (which existed anyway) that I did
not notice the config problem. You need to use this directive in a
rule chain. So this should work:
*.* @@<machine>:110
$ActionExecOnlyWhenPreviousIsSuspended on& @@<machine>:143
$ActionExecOnlyWhenPreviousIsSuspended off
Note that the second filter has been replaced by an "&" which means
that the actions are chained (and using the same filter).
Please let me know if that solves the issue (note that on older v5
builds this does NOT work due to the bug).
Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
