mavlogd not processing SITL data correctly

[fnoop]

No description provided.

[fnoop]

2017-08-20 19:26:47,597 - DEBUG - Received IN_CLOSE_WRITE event
2017-08-20 19:26:47,598 - INFO - Processing data from /srv/maverick/data/mavlink/sitl/logs/00000001.BIN
2017-08-20 19:26:47,879 - DEBUG - Binary mavlog detected, creating binary parser
2017-08-20 19:27:24,944 - DEBUG - No more log entries, break from processing loop
2017-08-20 19:27:25,468 - INFO - Processing complete of /srv/maverick/data/mavlink/sitl/logs/00000001.BIN
2017-08-20 19:27:25,469 - INFO - 20400 datapoints inserted.  First timestamp is 2017-08-20 19:19:48.092543Z:1503253188092542976, Last timestamp is 2017-08-20 19:20:45.135550Z:1503253245135549952
2017-08-20 19:27:25,511 - INFO - Archiving file from /srv/maverick/data/mavlink/sitl/logs/00000001.BIN to /srv/maverick/data/mavlink/archive/sitl/00000001.BIN
2017-08-20 19:27:26,636 - DEBUG - Grafana dashboard update:{u'status': u'success', u'version': 1, u'slug': u'flight-logs-index'}
2017-08-20 19:27:27,688 - DEBUG - Grafana error event dashboard update:{u'status': u'success', u'version': 1, u'slug': u'error-events-index'}

Says processed and datapoints inserted, but no data seems to be actually go into influx

[fnoop]

When SITL log processed it's moved into archive/sitl. But oddly SITL seems to hold onto the file even if closed, as the next arming/flight it continues to write to this file even when moved. Also archiving the file means SITL starts the incremental numbering from scratch so there are multiple 00001.bin files that overwrite each other.
Probably simpler to ditch the archiving altogether and just keep files in their original directories. They will not be processed by mavlogd unless specifically opened and closed, or moved.

[fnoop]

Suppressed archiving logic so logfiles stay in place. Now SITL starts writing logfile when armed, closes the file when landed but keeps hold of the file. File then gets processed by mavlogd as expected. Next takeoff SITL starts writing to the file again but next landing it doesn't close it again, so mavlogd never picks it up for processing. Either that or pynotify doesn't re-pick it up.

[fnoop]

Set LOG_FILE_DSRMROT to Enabled to rotate log files on disarm. Mavlogd then behaves as expected. To process a file that keeps being written to, we will need more sophisticated handling of DFReader.

From inotify:

Q: Is it better to use IN_MODIFY or IN_CLOSE_WRITE?
It varies from case to case. Usually it is more suitable to use IN_CLOSE_WRITE because if emitted the all changes on the appropriate file are safely written inside the file. The IN_MODIFY event needn't mean that a file change is finished (data may remain in memory buffers in the application). On the other hand, many logs and similar files must be monitored using IN_MODIFY - in such cases where these files are permanently open and thus no IN_CLOSE_WRITE can be emitted.

[fnoop]

So add a note to documentation about open files, and set SITL parameter LOG_FILE_DSRMROT automatically.

[fnoop]

Continuously reading logfiles is handled in separate issue: #500

[fnoop]

Also if LOG_FILE_DSRMROT is not set, SITL will end up with a single long file with lots of flights and lots of gaps in between. Should be set automatically, however mavlogd doesn't connect to SITL, it just watches directories for files.

[fnoop]

Create params service for sitl with default config to enable LOG_FILE_DSRMROT and disable LOG_DISARMED.
#580

[fnoop]

Params service created, LOG_FILE_DSRMROT enabled in SITL by default