1a96a7948SMatt Spinler# Platform Event Log Message Registry 2a96a7948SMatt SpinlerOn the BMC, PELs are created from the standard event logs provided by 3a96a7948SMatt Spinlerphosphor-logging using a message registry that provides the PEL related fields. 4a96a7948SMatt SpinlerThe message registry is a JSON file. 5a96a7948SMatt Spinler 6a96a7948SMatt Spinler## Contents 7a96a7948SMatt Spinler* [Component IDs](#component-ids) 8a96a7948SMatt Spinler* [Message Registry](#message-registry-fields) 9*d03d3d91SMatt Spinler* [Modifying and Testing](#modifying-and-testing) 10a96a7948SMatt Spinler 11a96a7948SMatt Spinler## Component IDs 12a96a7948SMatt SpinlerA component ID is a 2 byte value of the form 0xYY00 used in a PEL to: 13a96a7948SMatt Spinler1. Provide the upper byte (the YY from above) of an SRC reason code in `BD` 14a96a7948SMatt Spinler SRCs. 15a96a7948SMatt Spinler2. Reside in the section header of the Private Header PEL section to specify 16a96a7948SMatt Spinler the error log creator's component ID. 17a96a7948SMatt Spinler3. Reside in the section header of the User Header section to specify the error 18a96a7948SMatt Spinler log committer's component ID. 19a96a7948SMatt Spinler4. Reside in the section header in the User Data section to specify which 20a96a7948SMatt Spinler parser to call to parse that section. 21a96a7948SMatt Spinler 22a96a7948SMatt SpinlerComponent IDs are specified in the message registry either as the upper byte of 23a96a7948SMatt Spinlerthe SRC reason code field for `BD` SRCs, or in the standalone `ComponentID` 24a96a7948SMatt Spinlerfield. 25a96a7948SMatt Spinler 26a96a7948SMatt SpinlerComponent IDs will be unique on a per-repository basis for errors unique to 27a96a7948SMatt Spinlerthat repository. When the same errors are created by multiple repositories, 28a96a7948SMatt Spinlerthose errors will all share the same component ID. The master list of 29a96a7948SMatt Spinlercomponent IDs is [here](ComponentIDs.md). 30a96a7948SMatt Spinler 31a96a7948SMatt Spinler## Message Registry Fields 32a96a7948SMatt SpinlerThe message registry schema is [here](schema/schema.json), and the message 33a96a7948SMatt Spinlerregistry itself is [here](message_registry.json). The schema will be validated 34a96a7948SMatt Spinlereither during a bitbake build or during CI, or eventually possibly both. 35a96a7948SMatt Spinler 36a96a7948SMatt SpinlerIn the message registry, there are fields for specifying: 37a96a7948SMatt Spinler 38a96a7948SMatt Spinler### Name 39a96a7948SMatt SpinlerThis is the key into the message registry, and is the Message property 40a96a7948SMatt Spinlerof the OpenBMC event log that the PEL is being created from. 41a96a7948SMatt Spinler 42a96a7948SMatt Spinler``` 43a96a7948SMatt Spinler"Name": "xyz.openbmc_project.Power.Fault" 44a96a7948SMatt Spinler``` 45a96a7948SMatt Spinler 46a96a7948SMatt Spinler### Subsystem 47a96a7948SMatt SpinlerThis field is part of the PEL User Header section, and is used to specify 48a96a7948SMatt Spinlerthe subsystem pertaining to the error. It is an enumeration that maps to the 49a96a7948SMatt Spinleractual PEL value. 50a96a7948SMatt Spinler 51a96a7948SMatt Spinler``` 52a96a7948SMatt Spinler"Subsystem": "power_supply" 53a96a7948SMatt Spinler``` 54a96a7948SMatt Spinler 55a96a7948SMatt Spinler### Severity 56a96a7948SMatt SpinlerThis field is part of the PEL User Header section, and is used to specify 57a96a7948SMatt Spinlerthe PEL severity. It is an optional field, if it isn't specified, then the 58a96a7948SMatt Spinlerseverity of the OpenBMC event log will be converted into a PEL severity value. 59a96a7948SMatt Spinler 6017952d94SMatt SpinlerIt can either be the plain severity value, or an array of severity values that 6117952d94SMatt Spinlerare based on system type, where an entry without a system type will match 6217952d94SMatt Spinleranything unless another entry has a matching system type. 6317952d94SMatt Spinler 64a96a7948SMatt Spinler``` 65a96a7948SMatt Spinler"Severity": "unrecoverable" 66a96a7948SMatt Spinler``` 67a96a7948SMatt Spinler 6817952d94SMatt Spinler``` 6917952d94SMatt SpinlerSeverity": 7017952d94SMatt Spinler[ 7117952d94SMatt Spinler { 7217952d94SMatt Spinler "System": "system1", 7317952d94SMatt Spinler "SevValue": "recovered" 7417952d94SMatt Spinler }, 7517952d94SMatt Spinler { 7617952d94SMatt Spinler "Severity": "unrecoverable" 7717952d94SMatt Spinler } 7817952d94SMatt Spinler] 7917952d94SMatt Spinler``` 8017952d94SMatt SpinlerThe above example shows that on system 'system1' the severity will be 8117952d94SMatt Spinlerrecovered, and on every other system it will be unrecoverable. 8217952d94SMatt Spinler 83a96a7948SMatt Spinler### Mfg Severity 84a96a7948SMatt SpinlerThis is an optional field and is used to override the Severity field when a 8517952d94SMatt Spinlerspecific manufacturing isolation mode is enabled. It has the same format as 8617952d94SMatt SpinlerSeverity. 87a96a7948SMatt Spinler 88a96a7948SMatt Spinler``` 89a96a7948SMatt Spinler"MfgSeverity": "unrecoverable" 90a96a7948SMatt Spinler``` 91a96a7948SMatt Spinler 92a96a7948SMatt Spinler### Event Scope 93a96a7948SMatt SpinlerThis field is part of the PEL User Header section, and is used to specify 94a96a7948SMatt Spinlerthe event scope, as defined by the PEL spec. It is optional and defaults to 95a96a7948SMatt Spinler"entire platform". 96a96a7948SMatt Spinler 97a96a7948SMatt Spinler``` 98a96a7948SMatt Spinler"EventScope": "entire_platform" 99a96a7948SMatt Spinler``` 100a96a7948SMatt Spinler 101a96a7948SMatt Spinler### Event Type 102a96a7948SMatt SpinlerThis field is part of the PEL User Header section, and is used to specify 103a96a7948SMatt Spinlerthe event type, as defined by the PEL spec. It is optional and defaults to 1043fb208e3SMatt Spinler"not applicable" for non-informational logs, and "misc_information_only" for 1053fb208e3SMatt Spinlerinformational ones. 106a96a7948SMatt Spinler 107a96a7948SMatt Spinler``` 108a96a7948SMatt Spinler"EventType": "na" 109a96a7948SMatt Spinler``` 110a96a7948SMatt Spinler 111a96a7948SMatt Spinler### Action Flags 112a96a7948SMatt SpinlerThis field is part of the PEL User Header section, and is used to specify the 113a96a7948SMatt SpinlerPEL action flags, as defined by the PEL spec. It is an array of enumerations. 114a96a7948SMatt Spinler 1153fb208e3SMatt SpinlerThe action flags can usually be deduced from other PEL fields, such as the 1163fb208e3SMatt Spinlerseverity or if there are any callouts. As such, this is an optional field and 1173fb208e3SMatt Spinlerif not supplied the code will fill them in based on those fields. 1183fb208e3SMatt Spinler 1193fb208e3SMatt SpinlerIn fact, even if supplied here, the code may still modify them to ensure they 1203fb208e3SMatt Spinlerare correct. 1213fb208e3SMatt Spinler 122a96a7948SMatt Spinler``` 123a96a7948SMatt Spinler"ActionFlags": ["service_action", "report", "call_home"] 124a96a7948SMatt Spinler``` 125a96a7948SMatt Spinler 126a96a7948SMatt Spinler### Mfg Action Flags 127a96a7948SMatt SpinlerThis is an optional field and is used to override the Action Flags field when a 128a96a7948SMatt Spinlerspecific manufacturing isolation mode is enabled. 129a96a7948SMatt Spinler 130a96a7948SMatt Spinler``` 131a96a7948SMatt Spinler"MfgActionFlags": ["service_action", "report", "call_home"] 132a96a7948SMatt Spinler``` 133a96a7948SMatt Spinler 134a96a7948SMatt Spinler### Component ID 135a96a7948SMatt SpinlerThis is the component ID of the PEL creator, in the form 0xYY00. For `BD` 136a96a7948SMatt SpinlerSRCs, this is an optional field and if not present the value will be taken from 137a96a7948SMatt Spinlerthe upper byte of the reason code. If present for `BD` SRCs, then this byte 138a96a7948SMatt Spinlermust match the upper byte of the reason code. 139a96a7948SMatt Spinler 140a96a7948SMatt Spinler``` 141a96a7948SMatt Spinler"ComponentID": "0x5500" 142a96a7948SMatt Spinler``` 143a96a7948SMatt Spinler 144a96a7948SMatt Spinler### SRC Type 145a96a7948SMatt SpinlerThis specifies the type of SRC to create. The type is the first 2 characters 146a96a7948SMatt Spinlerof the 8 character ASCII string field of the PEL. The allowed types are `BD`, 147a96a7948SMatt Spinlerfor the standard OpenBMC error, and `11`, for power related errors. It is 148a96a7948SMatt Spinleroptional and if not specified will default to `BD`. 149a96a7948SMatt Spinler 150a96a7948SMatt SpinlerNote: The ASCII string for BD SRCs looks like: `BDBBCCCC`, where: 151a96a7948SMatt Spinler* BD = SRC type 152a96a7948SMatt Spinler* BB = PEL subsystem as mentioned above 153a96a7948SMatt Spinler* CCCC SRC reason code 154a96a7948SMatt Spinler 155a96a7948SMatt SpinlerFor `11` SRCs, it looks like: `1100RRRR`, where RRRR is the SRC reason code. 156a96a7948SMatt Spinler 157a96a7948SMatt Spinler``` 158a96a7948SMatt Spinler"Type": "11" 159a96a7948SMatt Spinler``` 160a96a7948SMatt Spinler 161a96a7948SMatt Spinler### SRC Reason Code 162a96a7948SMatt SpinlerThis is the 4 character value in the latter half of the SRC ASCII string. It 163a96a7948SMatt Spinleris treated as a 2 byte hex value, such as 0x5678. For `BD` SRCs, the first 164a96a7948SMatt Spinlerbyte is the same as the first byte of the component ID field in the Private 165a96a7948SMatt SpinlerHeader section that represents the creator's component ID. 166a96a7948SMatt Spinler 167a96a7948SMatt Spinler``` 168a96a7948SMatt Spinler"ReasonCode": "0x5544" 169a96a7948SMatt Spinler``` 170a96a7948SMatt Spinler 171a96a7948SMatt Spinler### SRC Symptom ID Fields 172a96a7948SMatt SpinlerThe symptom ID is in the Extended User Header section and is defined in the PEL 173a96a7948SMatt Spinlerspec as the unique event signature string. It always starts with the ASCII 174a96a7948SMatt Spinlerstring. This field in the message registry allows one to choose which SRC words 175a96a7948SMatt Spinlerto use in addition to the ASCII string field to form the symptom ID. All words 176a96a7948SMatt Spinlerare separated by underscores. If not specified, the code will choose a default 177a96a7948SMatt Spinlerformat, which may depend on the SRC type. 178a96a7948SMatt Spinler 179a96a7948SMatt SpinlerFor example: ["SRCWord3", "SRCWord9"] would be: 180a96a7948SMatt Spinler`<ASCII_STRING>_<SRCWord3>_<SRCWord9>`, which could look like: 181a96a7948SMatt Spinler`B181320_00000050_49000000`. 182a96a7948SMatt Spinler 183a96a7948SMatt Spinler``` 184a96a7948SMatt Spinler"SymptomIDFields": ["SRCWord3", "SRCWord9"] 185a96a7948SMatt Spinler``` 186a96a7948SMatt Spinler 187a96a7948SMatt Spinler### SRC words 6 to 9 188a96a7948SMatt SpinlerIn a PEL, these SRC words are free format and can be filled in by the user as 189a96a7948SMatt Spinlerdesired. On the BMC, the source of these words is the AdditionalData fields in 190a96a7948SMatt Spinlerthe event log. The message registry provides a way for the log creator to 191a96a7948SMatt Spinlerspecify which AdditionalData property field to get the data from, and also to 192a96a7948SMatt Spinlerdefine what the SRC word means for use by parsers. If not specified, these SRC 193a96a7948SMatt Spinlerwords will be set to zero in the PEL. 194a96a7948SMatt Spinler 195a96a7948SMatt Spinler``` 196a96a7948SMatt Spinler"Words6to9": 197a96a7948SMatt Spinler{ 198a96a7948SMatt Spinler "6": 199a96a7948SMatt Spinler { 200a96a7948SMatt Spinler "description": "Failing unit number", 201a96a7948SMatt Spinler "AdditionalDataPropSource": "PS_NUM" 202a96a7948SMatt Spinler } 203a96a7948SMatt Spinler} 204a96a7948SMatt Spinler``` 205a96a7948SMatt Spinler 206a96a7948SMatt Spinler### SRC Power Fault flag 207a96a7948SMatt SpinlerThe SRC has a bit in it to indicate if the error is a power fault. This is an 208a96a7948SMatt Spinleroptional field in the message registry and defaults to false. 209a96a7948SMatt Spinler 210a96a7948SMatt Spinler``` 211a96a7948SMatt Spinler"PowerFault: false 212a96a7948SMatt Spinler``` 213a96a7948SMatt Spinler 214a96a7948SMatt Spinler### Documentation Fields 215a96a7948SMatt SpinlerThe documentation fields are used by PEL parsers to display a human readable 216a96a7948SMatt Spinlerdescription of a PEL. They are also the source for the Redfish event log 217a96a7948SMatt Spinlermessages. 218a96a7948SMatt Spinler 219a96a7948SMatt Spinler#### Message 220a96a7948SMatt SpinlerThis field is used by the BMC's PEL parser as the description of the error log. 221a96a7948SMatt SpinlerIt will also be used in Redfish event logs. It supports argument substitution 222a96a7948SMatt Spinlerusing the %1, %2, etc placeholders allowing any of the SRC user data words 6 - 223a96a7948SMatt Spinler9 to be displayed as part of the message. If the placeholders are used, then 224a96a7948SMatt Spinlerthe `MessageArgSources` property must be present to say which SRC words to use 225a96a7948SMatt Spinlerfor each placeholder. 226a96a7948SMatt Spinler 227a96a7948SMatt Spinler``` 228a96a7948SMatt Spinler"Message": "Processor %1 had %2 errors" 229a96a7948SMatt Spinler``` 230a96a7948SMatt Spinler 231a96a7948SMatt Spinler#### MessageArgSources 232a96a7948SMatt SpinlerThis optional field is required when the Message field contains the %X 233a96a7948SMatt Spinlerplaceholder arguments. It is an array that says which SRC words to get the 234a96a7948SMatt Spinlerplaceholders from. In the example below, SRC word 6 would be used for %1, and 235a96a7948SMatt SpinlerSRC word 7 for %2. 236a96a7948SMatt Spinler 237a96a7948SMatt Spinler``` 238a96a7948SMatt Spinler"MessageArgSources": 239a96a7948SMatt Spinler[ 240a96a7948SMatt Spinler "SRCWord6", "SRCWord7" 241a96a7948SMatt Spinler] 242a96a7948SMatt Spinler``` 243a96a7948SMatt Spinler 244a96a7948SMatt Spinler#### Description 245a96a7948SMatt SpinlerA short description of the error. This is required by the Redfish schema to generate a Redfish message entry, but is not used in Redfish or PEL output. 246a96a7948SMatt Spinler 247a96a7948SMatt Spinler``` 248a96a7948SMatt Spinler"Description": "A power fault" 249a96a7948SMatt Spinler``` 250a96a7948SMatt Spinler 251a96a7948SMatt Spinler#### Notes 252a96a7948SMatt SpinlerThis is an optional free format text field for keeping any notes for the 253a96a7948SMatt Spinlerregistry entry, as comments are not allowed in JSON. It is an array of strings 254a96a7948SMatt Spinlerfor easier readability of long fields. 255a96a7948SMatt Spinler 256a96a7948SMatt Spinler``` 257a96a7948SMatt Spinler"Notes": [ 258a96a7948SMatt Spinler "This entry is for every type of power fault.", 259a96a7948SMatt Spinler "There is probably a hardware failure." 260a96a7948SMatt Spinler] 261a96a7948SMatt Spinler``` 26270311203SMatt Spinler 26370311203SMatt Spinler### Callout Fields 26470311203SMatt SpinlerThe callout fields allow one to specify the PEL callouts (either a hardware 26570311203SMatt SpinlerFRU, a symbolic FRU, or a maintenance procedure) in the entry for a particular 26670311203SMatt Spinlererror. These callouts can vary based on system type, as well as a user 26770311203SMatt Spinlerspecified AdditionalData property field. Callouts will be added to the PEL in 26870311203SMatt Spinlerthe order they are listed in the JSON. If a callout is passed into the error, 26970311203SMatt Spinlersay with CALLOUT_INVENTORY_PATH, then that callout will be added to the PEL 27070311203SMatt Spinlerbefore the callouts in the registry. 27170311203SMatt Spinler 27270311203SMatt SpinlerThere is room for up to 10 callouts in a PEL. 27370311203SMatt Spinler 27470311203SMatt Spinler#### Callouts example based on the system type 27570311203SMatt Spinler 27670311203SMatt Spinler``` 27770311203SMatt Spinler"Callouts": 27870311203SMatt Spinler[ 27970311203SMatt Spinler { 28070311203SMatt Spinler "System": "system1", 28170311203SMatt Spinler "CalloutList": 28270311203SMatt Spinler [ 28370311203SMatt Spinler { 28470311203SMatt Spinler "Priority": "high", 28570311203SMatt Spinler "LocCode": "P1-C1" 28670311203SMatt Spinler }, 28770311203SMatt Spinler { 28870311203SMatt Spinler "Priority": "low", 28970311203SMatt Spinler "LocCode": "P1" 29070311203SMatt Spinler } 29170311203SMatt Spinler ] 29270311203SMatt Spinler }, 29370311203SMatt Spinler { 29470311203SMatt Spinler "CalloutList": 29570311203SMatt Spinler [ 29670311203SMatt Spinler { 29770311203SMatt Spinler "Priority": "high", 29870311203SMatt Spinler "Procedure": "SVCDOCS" 29970311203SMatt Spinler } 30070311203SMatt Spinler ] 30170311203SMatt Spinler 30270311203SMatt Spinler } 30370311203SMatt Spinler] 30470311203SMatt Spinler 30570311203SMatt Spinler``` 30670311203SMatt Spinler 30770311203SMatt SpinlerThe above example shows that on system 'system1', the FRU at location P1-C1 30870311203SMatt Spinlerwill be called out with a priority of high, and the FRU at P1 with a priority 30970311203SMatt Spinlerof low. On every other system, the maintenance procedure SVCDOCS is called 31070311203SMatt Spinlerout. 31170311203SMatt Spinler 31270311203SMatt Spinler#### Callouts example based on an AdditionalData field 31370311203SMatt Spinler 31470311203SMatt Spinler``` 31570311203SMatt Spinler"CalloutsUsingAD": 31670311203SMatt Spinler{ 31770311203SMatt Spinler "ADName": "PROC_NUM", 31870311203SMatt Spinler "CalloutsWithTheirADValues": 31970311203SMatt Spinler [ 32070311203SMatt Spinler { 32170311203SMatt Spinler "ADValue": "0", 32270311203SMatt Spinler "Callouts": 32370311203SMatt Spinler [ 32470311203SMatt Spinler { 32570311203SMatt Spinler "CalloutList": 32670311203SMatt Spinler [ 32770311203SMatt Spinler { 32870311203SMatt Spinler "Priority": "high", 32970311203SMatt Spinler "LocCode": "P1-C5" 33070311203SMatt Spinler } 33170311203SMatt Spinler ] 33270311203SMatt Spinler } 33370311203SMatt Spinler ] 33470311203SMatt Spinler }, 33570311203SMatt Spinler { 33670311203SMatt Spinler "ADValue": "1", 33770311203SMatt Spinler "Callouts": 33870311203SMatt Spinler [ 33970311203SMatt Spinler { 34070311203SMatt Spinler "CalloutList": 34170311203SMatt Spinler [ 34270311203SMatt Spinler { 34370311203SMatt Spinler "Priority": "high", 34470311203SMatt Spinler "LocCode": "P1-C6" 34570311203SMatt Spinler } 34670311203SMatt Spinler ] 34770311203SMatt Spinler } 34870311203SMatt Spinler ] 34970311203SMatt Spinler } 35070311203SMatt Spinler ] 35170311203SMatt Spinler} 35270311203SMatt Spinler 35370311203SMatt Spinler``` 35470311203SMatt Spinler 35570311203SMatt SpinlerThis example shows that the callouts were selected based on the 'PROC_NUM' 35670311203SMatt SpinlerAdditionalData field. When PROC_NUM was 0, the FRU at P1-C5 was called out. 35770311203SMatt SpinlerWhen it was 1, P1-C6 was called out. Note that the same 'Callouts' array is 35870311203SMatt Spinlerused as in the previous example, so these callouts can also depend on the 35970311203SMatt Spinlersystem type. 36070311203SMatt Spinler 36170311203SMatt Spinler#### CalloutType 36270311203SMatt SpinlerThis field can be used to modify the failing component type field in the 36370311203SMatt Spinlercallout when the default doesn\'t fit: 36470311203SMatt Spinler 36570311203SMatt Spinler``` 36670311203SMatt Spinler{ 36770311203SMatt Spinler 36870311203SMatt Spinler "Priority": "high", 36970311203SMatt Spinler "Procedure": "FIXIT22" 37070311203SMatt Spinler "CalloutType": "config_procedure" 37170311203SMatt Spinler} 37270311203SMatt Spinler``` 37370311203SMatt Spinler 37470311203SMatt SpinlerThe defaults are: 37570311203SMatt Spinler- Normal hardware FRU: hardware_fru 37670311203SMatt Spinler- Symbolic FRU: symbolic_fru 37770311203SMatt Spinler- Procedure: maint_procedure 378*d03d3d91SMatt Spinler 379*d03d3d91SMatt Spinler## Modifying and Testing 380*d03d3d91SMatt Spinler 381*d03d3d91SMatt SpinlerThe general process for adding new entries to the message registry is: 382*d03d3d91SMatt Spinler 383*d03d3d91SMatt Spinler1. Update message_registry.json to add the new errors. 384*d03d3d91SMatt Spinler2. If a new component ID is used (usually the first byte of the SRC reason 385*d03d3d91SMatt Spinler code), document it in ComponentIDs.md. 386*d03d3d91SMatt Spinler3. Validate the file. It must be valid JSON and obey the schema. The 387*d03d3d91SMatt Spinler `process_registry.py` script in `extensions/openpower-pels/registry/tools` 388*d03d3d91SMatt Spinler will validate both, though it requires the python-jsonschema package to do 389*d03d3d91SMatt Spinler the schema validation. This script is also run to validate the message 390*d03d3d91SMatt Spinler registry as part of CI testing. 391*d03d3d91SMatt Spinler 392*d03d3d91SMatt Spinler``` 393*d03d3d91SMatt Spinler ./tools/process_registry.py -v -s schema/schema.json -r message_registry.json 394*d03d3d91SMatt Spinler``` 395*d03d3d91SMatt Spinler 396*d03d3d91SMatt Spinler4. One can test what PELs are generated from these new entries without writing 397*d03d3d91SMatt Spinler any code to create the corresponding event logs: 398*d03d3d91SMatt Spinler 1. Copy the modified message_registry.json into `/etc/phosphor-logging/` on 399*d03d3d91SMatt Spinler the BMC. That directory may need to be created. 400*d03d3d91SMatt Spinler 2. Use busctl to call the Create method to create an event log 401*d03d3d91SMatt Spinler corresponding to the message registry entry under test. 402*d03d3d91SMatt Spinler 403*d03d3d91SMatt Spinler``` 404*d03d3d91SMatt Spinlerbusctl call xyz.openbmc_project.Logging /xyz/openbmc_project/logging \ 405*d03d3d91SMatt Spinlerxyz.openbmc_project.Logging.Create Create ssa{ss} \ 406*d03d3d91SMatt Spinlerxyz.openbmc_project.Common.Error.Timeout \ 407*d03d3d91SMatt Spinlerxyz.openbmc_project.Logging.Entry.Level.Error 1 "TIMEOUT_IN_MSEC" "5" 408*d03d3d91SMatt Spinler``` 409*d03d3d91SMatt Spinler 410*d03d3d91SMatt Spinler 3. Check the PEL that was created using peltool. 411*d03d3d91SMatt Spinler 4. When finished, delete the file from `/etc/phosphor-logging/`. 412