<div dir="ltr">It seems that when using deltacount after a log statement with a 'find' in it like in the example below causes a seg fault in logfetch:<br><div><br>log:`find /opt/tomcat/logs/myapp.$(date +%F).log`:10240<br># deltacount after a find causes a seg fault.<br>deltacount WarningDeltaCount "WARNING"<br></div><div><br></div><div>It does not seem to matter if the find statement is actually in a different higher up log line that should not be affecting this deltacount. The workaround to that is to re-order the log statements such that your find is below the deltacount, but that still means they can not be used together, which means we can not use deltacount in the example above.</div><div><br></div><div>This core backtrace does not look very helpful to me, but maybe because I am using a non-debug version of the 4.3.28 xymon-client RPM (<a href="https://terabithia.org/rpms/xymon/el6/x86_64/xymon-client-4.3.28-1.el6.x86_64.rpm">https://terabithia.org/rpms/xymon/el6/x86_64/xymon-client-4.3.28-1.el6.x86_64.rpm</a>):<br></div><div><pre class="gmail-raw_message_text" id="gmail-raw_message_text">core_backtrace:
:{ "signal": 11
:, "executable": "/usr/bin/logfetch"
:, "stacktrace":
: [ { "crash_thread": true
: , "frames":
: [ { "address": 4217378
: , "build_id": "40398b05a94e8227d573537651e7f595e5ef0d96"
: , "build_id_offset": 23074
: , "file_name": "/usr/bin/logfetch"
: } ]
: } ]
:}</pre></div><div>It was the same on 4.3.26-1 RPM.</div><div><br></div><div><b>Separately</b>, I believe that even when there is no segfault (because I hard code the filename), and the clientlog is all present and correct, that deltacount actually returns the wrong number of lines - it always seems to be 0 in my tests (with --debug, run from command line):</div><div><br></div><div>550 2017-11-14 13:12:38.042701 logfetch: -> logdata (/opt/tomcat/logs/myapp.2017-11-14.log)<br>550 2017-11-14 13:12:38.043112 - fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 0, loc 2558853<br>550 2017-11-14 13:12:38.043133 - fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 1, loc 2557130<br>550 2017-11-14 13:12:38.043149 - fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 2, loc 0<br>550 2017-11-14 13:12:38.043181 - fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 3, loc 0<br>550 2017-11-14 13:12:38.043199 - fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 4, loc 0<br>550 2017-11-14 13:12:38.043224 - fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 5, loc 0<br>550 2017-11-14 13:12:38.043240 - fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 6, loc 0<br>550 2017-11-14 13:12:38.043274 logfetch: Current size (ending): 2560538 bytes. Last end was 2558853. Looking 6 spots before that, which is 0. bytestocurrent: 2558853<br>550 2017-11-14 13:12:38.043322 - compiling DELTACOUNT regex: "WARNING"<br>550 2017-11-14 13:12:38.064073 - Last position was 2558853, found curpos location at 2558853 in current buffer.<br>550 2017-11-14 13:12:38.064121 - line forced as a trigger: <...CURRENT...><br>14-Nov-2017 13:11:09.259 FINE [pool-1-thread-6923] [edited out]<br>550 2017-11-14 13:12:38.064135 - first trigger line encountered; preparing trigger START & END positioning store<br>550 2017-11-14 13:12:38.064146 - new trigger anchor START position set<br>550 2017-11-14 13:12:38.064164 - trigger END position set<br>550 2017-11-14 13:12:38.064194 Marked 1 pairs of START and END anchors for consideration.<br>550 2017-11-14 13:12:38.064206 Found 1674 bytes of trigger data, 8566 bytes available space for non-trigger data; last trigger ended 961 bytes from end. Max bytes allowed is 10240.<br>550 2017-11-14 13:12:38.064222 Staging replacement buffer, 10272 bytes.<br>550 2017-11-14 13:12:38.064233 Copying buffer content for trigger 1.<br>550 2017-11-14 13:12:38.064247 logfetch: More space was available than between last trigger and eof; reducing to 961 bytes<br>550 2017-11-14 13:12:38.064259 logfetch: Delta from end of final trigger to beginning of final section: 0 bytes<br>550 2017-11-14 13:12:38.064268 Copying 961 final bytes of non-trigger content<br>550 2017-11-14 13:12:38.064351 -- fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 0, loc 2560538<br>550 2017-11-14 13:12:38.064362 -- fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 1, loc 2558853<br>550 2017-11-14 13:12:38.064372 -- fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 2, loc 2557130<br>550 2017-11-14 13:12:38.064382 -- fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 3, loc 0<br>550 2017-11-14 13:12:38.064394 -- fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 4, loc 0<br>550 2017-11-14 13:12:38.064403 -- fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 5, loc 0<br>550 2017-11-14 13:12:38.064413 -- fn: /opt/tomcat/logs/myapp.2017-11-14.log, pos 6, loc 0<br>550 2017-11-14 13:12:38.064424 logfetch: <- logdata (/opt/tomcat/logs/myapp.2017-11-14.log)<br>[msgs:/opt/tomcat/logs/myapp.2017-11-14.log]<br></div><div><br></div><div>Can anyone help? Thanks,</div><div><br></div><div>SebA<br></div></div>