linuxptpdaemon: Lost PTP Port State Metrics After Sidecar Crash

[aneeshkp]

In the current setup with two containers:
The linuxptp-daemon writes PTP port state data via a Unix domain socket.
The cloud-event-proxy sidecar reads the data and exposes it as metrics.

If the sidecar container crashes and restarts, it loses previously received metrics until the next event is pushed. While most PTP events are regularly received, interface role/port state events (e.g., LISTENING, FAULTY, SLAVE, etc.) are not sent frequently, which means metrics may be missing for extended periods — potentially causing monitoring issues or inaccurate system state visibility.

This is critical because port state is required for accurate PTP status interpretation, and missing this can break functionality relying on accurate sync status reporting.

Solution : Enable the sidecar to recover the last known port state on startup without introducing polling or increased CPU usage.
Use a shared file-based state persistence approach:
The linuxptp-daemon writes the latest PTP port state to a file only when it changes.
The cloud-event-proxy sidecar reads this file on startup and uses it to restore metrics instantly.

This solution is:
Lightweight (write-on-change only)
Fast and reliable recovery for sidecar
Implementation Plan:
Mount an emptyDir volume shared between both containers.
The linuxptp-daemon writes to: /shared/ptp_port_state.json
The cloud-event-proxy reads this file during initialization.

Json file example.
{ "boundaryProfile": [ { "port": "ens7fx", "state": "MASTER", "timestamp": "2025-03-31T15:23:02Z" }, { "port": "ens7fx", "state": "LISTENING", "timestamp": "2025-03-31T15:23:02Z" } ], "OCProfile": [ { "port": "ens7fx", "state": "FAULTY", "timestamp": "2025-03-31T15:23:02Z" }, { "port": "ens7fx", "state": "SLAVE", "timestamp": "2025-03-31T15:23:02Z" } ] }

[nocturnalastro]

One thing we might want to do is load the json after the socket is up and the sidecar is listening and allow values received by the socket to overrule the json blob.

The race I'm envisioning could happen if we don't do this is.

1. Side car restarts
2. Side car reads json blob.
3. Port state changes, new json blob is written by linuxptpsaemon, and update sent on socket.
4. Side car starts listening to socket.
5. Side car sets stale value from blob.

What I am suggesting is:

1. Side car restarts.
2. Side car wait till its listening to port.
3. Side car reads json blob.
4. Side car updates values not currently set with json blob.

Does this make sense?