Station output from the DataRecoveryService

When left at the default “message” log level, the DataRecoveryService produces minimal station output related to operation. Primarily, related messages are seen at station startup, especially if following a power loss event or reboot command.
MESSAGE [11:18:15 13-Aug-10 EDT][sys.registry] Up-to-date [250ms]
MESSAGE [11:18:20 13-Aug-10 EDT][sys.registry] Loaded [2935ms]
MESSAGE [11:18:29 13-Aug-10 EDT][sys] Baja runtime booted ("/ffs0/niagara")
MESSAGE [11:18:29 13-Aug-10 EDT][sys] Loading "/ffs0/niagara/stations/J6_TestW/
config.bog"...
MESSAGE [11:19:34 13-Aug-10 EDT][sys] Loaded (64809ms)
MESSAGE [11:19:56 13-Aug-10 EDT][alarm.database] Loading...
MESSAGE [11:19:58 13-Aug-10 EDT][alarm.database] Loaded [2196ms, 32 alarms, 104 pages]
WARNING [11:19:58 13-Aug-10 EDT][platDataRecovery.service] data recovery detected,
replaying...
MESSAGE [11:20:11 13-Aug-10 EDT][sys] DataRecoveryService restoration 
check complete (18368ms)
MESSAGE [11:20:12 13-Aug-10 EDT][sys] Services Initialized (1010ms)
MESSAGE [11:20:12 13-Aug-10 EDT][sys.mixin] Updated [112ms]
MESSAGE [11:20:14 13-Aug-10 EDT][history.db] Starting async warmup of history 
config index...
MESSAGE [11:20:14 13-Aug-10 EDT][history.db] Async history config index warmup
completed in 342 ms.
MESSAGE [11:20:37 13-Aug-10 EDT][web.server] HTTP Server started on port 80
MESSAGE [11:20:38 13-Aug-10 EDT][fox] Service started on port 1911
MESSAGE [11:20:39 13-Aug-10 EDT][sys] Niagara Runtime Environment: 3.6.20
MESSAGE [11:20:39 13-Aug-10 EDT][sys] *** Station Started (27273ms) [153291ms total]
*** niagara>
MESSAGE [11:20:41 13-Aug-10 EDT][sys] Saving station...
MESSAGE [11:20:55 13-Aug-10 EDT][history.db] Saved history archive (4197ms)
MESSAGE [11:21:02 13-Aug-10 EDT][sys] Saved /ffs0/niagara/stations/J202_TestW/
config.bog (19654ms)

The example above shows related messages mixed in with other station startup entries.

Using “spy”, you can increase the station’s log level, by setting it to “trace” on items:

  • platDataRecovery.manager
  • platDataRecovery.service

This produces much more debug information in station output. An example small snippet below reflects trace level output when an SRAM data block “flushes” to a flash file.

 CAUTION: Turning trace logging on either of the logs above may produce extremely large levels of output, and should not be left in this log level state. This applies particularly to large stations. 
TRACE [10:31:12 13-Aug-10 EDT][platDataRecovery.service] External append(history:,
	encoded key bytes: appended /J202_TestW/AuditHistory... 
TRACE [10:31:12 13-Aug-10 EDT][platDataRecovery.manager] Size of used block exceeds
	free space, forcing flush of block 
TRACE [10:31:12 13-Aug-10 EDT][platDataRecovery.service] Narcissistic append 
	(encoded key bytes: AA==, data bytes: 0000b10b000e... 
TRACE [10:31:12 13-Aug-10 EDT][platDataRecovery.service] Attempt to append data with 
	key encoded as bytes: AA== successful 
TRACE [10:31:12 13-Aug-10 EDT][platDataRecovery.service] Flush operation successful.
TRACE [10:31:12 13-Aug-10 EDT][platDataRecovery.service] Attempt to append data with 
	key encoded as bytes: appended /J202_TestW/AuditHistory...

You can also increase the log level of other items related to (or used by) the DataRecoveryService, including the following:

  • alarm.dataRecovery — For logs about the AlarmService’s use of the DataRecoveryService
  • history.critical — For logs about the HistoryService’s use of the DataRecoveryService

    As well as these additional DataRecoveryService related items:

  • sys.critical
  • sys.critical.load.item (item = add, change, facetsChange, flagsChange, recategorize, remove, rename, reorder)
  • sys.critical.progObj
  • sys.critical.save.item (item = add, change, facetsChange, flagsChange, recategorize, remove, rename, reorder)
 NOTE: The same caution applies as before about trace level on these items—some may produce very large levels of station output.