Hi Arturo, unfortunately it looks like myfirst idea for a Debian-side workaround (setting 'copytruncate') is not sufficient to fully solve the problem. Since the suricata.log output file is apparently not opened in append mode, a log rotation will result in a large sparse file with the size of the previous (pre-rotation) content as \0 bytes, followed by the new post-rotation content. It looks like there's no way around either actually recreating the file (as done in my patch) or opening the log file in append mode. Unfortunately both would require modification to upstream's code.
Any comments? Cheers Sascha >>>> BTW I have just finished a patch to Suricata that unifies this behaviour >>>> across event/alert and log output. I'll attach it in a comment to your >>>> bug #1938 in upstream's Redmine once it's tested and polished. >>> >>> I would like to see/test the patch before sending upstream. >> >> Please find the patch attached to this email. Looking forward to any >> comments you may have. >> > > Ok thanks. Upstream they is asking for more info, so I will forward > your patch to them as part of the update. > >> BTW, I noticed that suricata 3.1.2-3 built from git seems to be missing >> /usr/bin/suricata in the 'suricata' binary package, at least for me: > > Yeah thanks, fixed now. Could you please test it? Just commited to git. > > I will re-upload to NEW now. >
