75e8e218 | 30-Nov-2023 |
Myung Bae <myungbae@us.ibm.com> |
Use MonotonicTimeStamp for bmc log id
/redfish/v1/Managers/bmc/LogServices/Journal/Entries gives the system journal entries whose ID is based on the realtime timestmap. However, the system realtime
Use MonotonicTimeStamp for bmc log id
/redfish/v1/Managers/bmc/LogServices/Journal/Entries gives the system journal entries whose ID is based on the realtime timestmap. However, the system realtime may go backward if the system time is changed either manually or via NTP.
If that happens, those entries may not found via redfish GET as `sd_journal_seek_realtime_usec()`[1] may not always work on the entries which are not sorted in time-order.
This may cause the inconsistency between the content of `/redfish/v1/Managers/bmc/LogServices/Journal/Entries/` and /redfish/v1/Managers/bmc/LogServices/Journal/Entries/<bmc_journal_id>`.
For example,
``` sudo journalctl --vacuum-time=1s <wait for a while to clear up journal>
date -s "<backward-time>"
date -s "<forward-time>" ```
Run redfish journal entries and get each entry id from the output
``` curl -k -X GET https://${bmc}/redfish/v1/Managers/bmc/LogServices/Journal/Entries > rj.out ```
Take some logEntry Id that its time going backward like ``` grep "@odata.id" rj.out ```
Run redfish query for each id, and some of them can't be successful. ``` % curl -k -X GET https://${bmc}/redfish/v1/Managers/bmc/LogServices/Journal/Entries/1701604800002075 { "error": { "@Message.ExtendedInfo": [ { "@odata.type": "#Message.v1_1_1.Message", "Message": "The requested resource of type LogEntry named '1701604800002075' was not found.", "MessageArgs": [ "LogEntry", "1701604800002075" ], "MessageId": "Base.1.13.0.ResourceNotFound", "MessageSeverity": "Critical", "Resolution": "Provide a valid resource identifier and resubmit the request." } ], "code": "Base.1.13.0.ResourceNotFound", "message": "The requested resource of type LogEntry named '1701604800002075' was not found." } }%
```
This can also be verified by checking the failure of Redfish Validator run ``` python3 RedfishServiceValidator.py --auth Session -i https://${bmc} -u admin -p 0penBmc0 --payload Tree /redfish/v1/Managers/bmc/LogServices/Journal/Entries ```
For example, ``` ERROR - Members: GET of resource at URI /redfish/v1/Managers/bmc/LogServices/Journal/Entries/1701604800002075 returned HTTP error. Check URI. ERROR - Members: GET of resource at URI /redfish/v1/Managers/bmc/LogServices/Journal/Entries/1701604800065949 returned HTTP error. Check URI. ERROR - Members: GET of resource at URI /redfish/v1/Managers/bmc/LogServices/Journal/Entries/1701607680003048 returned HTTP error. Check URI. ```
``` --Time goes backwrd { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/Journal/Entries/1701604800002075", "@odata.type": "#LogEntry.v1_9_0.LogEntry", "Created": "2023-12-03T12:00:00+00:00", "EntryType": "Oem", "Id": "1701604800002075", "Message": "systemd-resolved: Clock change detected. Flushing caches.", "Name": "BMC Journal Entry", "OemRecordFormat": "BMC Journal Entry", "Severity": "OK" }, ... { "@odata.id": "/redfish/v1/Managers/bmc/LogServices/Journal/Entries/1701607680003048", "@odata.type": "#LogEntry.v1_9_0.LogEntry", "Created": "2023-12-03T12:48:00+00:00", "EntryType": "Oem", "Id": "1701607680003048", "Message": "systemd-resolved: Clock change detected. Flushing caches.", "Name": "BMC Journal Entry", "OemRecordFormat": "BMC Journal Entry", "Severity": "OK" }, -- Time comes back to the previous moment ```
The solution is proposed to use <bootid> + <monototic timestamp> as the redfish journal entry id instead of realtime timestamp. Unlike realtime timestamp which may go backward, <monotonic timestamp> is monotonically increasing.
Tested: - Redfish Validator passes - GET Journal Entry ID will be found even if its time goes backward.
[1] https://github.com/openbmc/bmcweb/blob/7164bc62dd26ec92b01985aaae97ecc48276dea5/redfish-core/lib/log_services.hpp#L2690
Change-Id: I83bfb1ed88c9cf036f594757aa4a00d2709dd196 Signed-off-by: Myung Bae <myungbae@us.ibm.com>
show more ...
|
0d946211 | 13-Jul-2022 |
Claire Weinan <cweinan@google.com> |
LogService: Use DeleteAll DBus method in clearDump
Update the clearDump() implementation to call the DeleteAll D-Bus method instead of iterating through D-Bus objects representing individual log ent
LogService: Use DeleteAll DBus method in clearDump
Update the clearDump() implementation to call the DeleteAll D-Bus method instead of iterating through D-Bus objects representing individual log entries and calling the Delete D-Bus method on each one. (It's more efficient for phosphor-debug-collector to iterate through entries in its DeleteAll method handler than for bmcweb to iterate through them.)
It seems like clearDump() wasn't originally implemented using DeleteAll because dumps of various types were under the same D-Bus path namespace at the time and there wasn't a way to selectively clear dumps of only a specific type. The commit at [1] put different dump types under different path namespaces (enabling us to now use DeleteAll).
Now clients should see a bit of performance improvement when running the ClearLog action on dump LogServices, due to the reduced number of D-Bus method calls needed to execute ClearLog.
Also updated getDumpServiceInfo() to populate the ClearLog action for dump LogServices based on whether their dump manager object implements xyz.openbmc_project.Collection.DeleteAll.
Tested: Cleared the fault log containing 100 entries. Ran with the time command several times before and after the change: ``` time curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Actions/LogService.ClearLog ```
Before the change, "real" time reported was ~1.2s. After the change, "real" time reported was ~0.4s.
Forced creation of dump entries and then ran Redfish ClearLog action on each dump type: ``` curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Actions/LogService.ClearLog
curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Actions/LogService.ClearLog
curl -k -H "X-Auth-Token: $token" -X POST http://${bmc}/redfish/v1/Systems/system/LogServices/Dump/Actions/LogService.ClearLog ```
Then verified that there were no dump LogService entries afterwards: ``` curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Entries
curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Managers/bmc/LogServices/FaultLog/Entries
curl -k -H "X-Auth-Token: $token" -X GET http://${bmc}/redfish/v1/Systems/system/LogServices/Dump/Entries ```
Also verified that the corresponding D-Bus objects were gone from the D-Bus tree after running ClearLog on each dump type:
Before ClearLog: busctl tree xyz.openbmc_project.Dump.Manager `-/xyz `-/xyz/openbmc_project `-/xyz/openbmc_project/dump |-/xyz/openbmc_project/dump/bmc | `-/xyz/openbmc_project/dump/bmc/entry | `-/xyz/openbmc_project/dump/bmc/entry/101 |-/xyz/openbmc_project/dump/faultlog | `-/xyz/openbmc_project/dump/faultlog/entry | |-/xyz/openbmc_project/dump/faultlog/entry/11 | |-/xyz/openbmc_project/dump/faultlog/entry/12 | |-/xyz/openbmc_project/dump/faultlog/entry/13 | |-/xyz/openbmc_project/dump/faultlog/entry/14 | |-/xyz/openbmc_project/dump/faultlog/entry/15 | |-/xyz/openbmc_project/dump/faultlog/entry/16 | |-/xyz/openbmc_project/dump/faultlog/entry/17 | |-/xyz/openbmc_project/dump/faultlog/entry/18 | |-/xyz/openbmc_project/dump/faultlog/entry/19 | `-/xyz/openbmc_project/dump/faultlog/entry/20 |-/xyz/openbmc_project/dump/internal | `-/xyz/openbmc_project/dump/internal/manager `-/xyz/openbmc_project/dump/system `-/xyz/openbmc_project/dump/system/entry |-/xyz/openbmc_project/dump/system/entry/3 `-/xyz/openbmc_project/dump/system/entry/4
After ClearLog: busctl tree xyz.openbmc_project.Dump.Manager `-/xyz `-/xyz/openbmc_project `-/xyz/openbmc_project/dump |-/xyz/openbmc_project/dump/bmc |-/xyz/openbmc_project/dump/faultlog |-/xyz/openbmc_project/dump/internal | `-/xyz/openbmc_project/dump/internal/manager `-/xyz/openbmc_project/dump/system
Confirmed that ClearLog action is listed for the following LogServices: /redfish/v1/Managers/bmc/LogServices/Dump /redfish/v1/Managers/bmc/LogServices/FaultLog /redfish/v1/Systems/system/LogServices/Dump Then ran "systemctl stop xyz.openbmc_project.Dump.Manager" (which removes dump manager objects including their xyz.openbmc_project.Collection.DeleteAll interface) and saw that the ClearLog action was no longer listed. Also locally built a version of phosphor-debug-collecor with the interface xyz.openbmc_project.Collection.DeleteAll removed from dump managers and ran it and saw that the ClearLog action wasn't listed.
Redfish Service Validator passed on the following URIs (with service xyz.openbmc_project.Dump.Manager running): /redfish/v1/Managers/bmc/LogServices/Dump /redfish/v1/Managers/bmc/LogServices/FaultLog /redfish/v1/Systems/system/LogServices/Dump
Note: Most dump LogService unit tests were removed in this patchset since this patchset adds a D-Bus call to getDumpServiceInfo(), and we haven't decided how to mock D-Bus calls for unit testing yet.
[1] https://github.com/openbmc/phosphor-debug-collector/commit/fef66a951fe6fe283515480b2c493dfdc2275a95
Signed-off-by: Claire Weinan <cweinan@google.com> Change-Id: Ic5f8f9e3528f521887766d8710bd77f969d8236a
show more ...
|
77b36437 | 05-Feb-2021 |
Chicago Duan <duanzhijia01@inspur.com> |
Implements PowerSubsystem schema
This commit implements the Redfish PowerSubsystem schema and collects default property values. PowerSupplies will be implemented in the next commit.
ref: https://ww
Implements PowerSubsystem schema
This commit implements the Redfish PowerSubsystem schema and collects default property values. PowerSupplies will be implemented in the next commit.
ref: https://www.dmtf.org/sites/default/files/standards/documents/ DSP0268_2022.2.pdf (6.86 PowerSubsystem 1.1.0) https://redfish.dmtf.org/schemas/v1/PowerSupply.v1_1_0.json
Tested: Validator and UT passes 1. curl -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/PowerSubsystem { "@odata.id": "/redfish/v1/Chassis/chassis/PowerSubsystem", "@odata.type": "#PowerSubsystem.v1_1_0.PowerSubsystem", "Id": "PowerSubsystem", "Name": "Power Subsystem", "Status": { "Health": "OK", "State": "Enabled" } }
2. bad chassisID curl -k -H "X-Auth-Token: $token" -X GET https://${bmc} /redfish/v1/Chassis/badchassisID/PowerSubsystem/ PowerSupplies/powersupply0 { "error": { "@Message.ExtendedInfo": [ { "@odata.type": "#Message.v1_1_1.Message", "Message": "The requested resource of type Chassis named badchassisID was not found.", "MessageArgs": [ "Chassis", "badchassisID" ], "MessageId": "Base.1.13.1.ResourceNotFound", "MessageSeverity": "Critical", "Resolution": "Provide a valid resource identifier and resubmit the request." } ], "code": "Base.1.13.1.ResourceNotFound", "message": "The requested resource of type Chassis named badchassisID was not found." } }
Signed-off-by: Chicago Duan <duanzhijia01@inspur.com> Change-Id: I6885b1777082538eceaf7ea85a8f69966459ee43
show more ...
|