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/J202_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.

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)

The same caution applies as before about trace level on these items—some may produce very large levels of station output.