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.

Station output from the DataRecoveryService

Related Links