A question about /tmp/thread /userdata/thread

[olivluca]

I'm setting up one gateway to use it for thread (mind me, I have no thread devices but I have an Ikea nearby 😉) and I see that the otbr-agent works with the /tmp/thread directory.
The init script at startup copies /userdata/thread to /tmp/thread and does the reverse when shutting down.
It also checks for ~60 seconds after startup and when it's no more disconnected it copies /tmp/thread to /userdata/thread (it took me more than 60 seconds to configure homeassistant since I had to clear the previous config using otbr in a container, so it didn't copy the files in my case).
The question is, are the files in /tmp/thread changing frequently or do they only change when you setup a new network?
If the former, copying them back at shutdown could not be enough in case of power loss, if the latter I think it should be done manually so you don't write to flash uselessly.

[olivluca]

Mmh, why didn't I read the comment in the init script? 🙄

#   On power loss, only frame counters are lost — OpenThread recovers by
#   jumping ahead on next boot.

but if that's the only thing changing and OpenThread recovers, it shouldn't be necessary to copy /tmp/thread to /userdata/thread, should it?

[jnilo1]

Both issues are fixed in v2.1.0.

The 60-second problem: you're right, the old script only synced once ~60s after boot. If you configured the Thread network later, the dataset was never persisted. v2.1.0 replaces this with a persistent sync daemon that polls ot-ctl dataset active -x every 30s and syncs /tmp/thread → /userdata/thread only when the dataset actually changes. Minimal flash wear (writes only on real changes, not periodic).

What changes and when: the active dataset (network key, channel, PAN ID, etc.) only changes when you form or reconfigure the network — not during normal operation. Frame counters (anti-replay nonces) update on every transmission (~480 times/day), but these are ephemeral and stored in RAM only.

On power loss: OpenThread recovers automatically by jumping the frame counter ahead on next boot. The persistent data that matters (network credentials, dataset) is synced to flash by the daemon. So the only thing lost on power loss is a few seconds of frame counter advancement — no network rejoin needed.

On clean shutdown: S70otbr traps SIGTERM and does a final sync, plus the new rcK shutdown script stops all services in reverse order before reboot.

[olivluca]

nitpicking here, but

1. since the sync loop starts with last_dataset="" it will always write to flash at least once even if nothing changed
2. the same could be said for a clean stop, that will unconditionally write to flash even if nothing changed

as I said, it's just nitpicking

[jnilo1]

@olivluca Your "nitpicking" is always spot-on — please never stop! Both fixed in v2.1.1.

1. First poll: the daemon now seeds last_dataset from the REST API (/node/dataset/active) before entering the loop. Tested: the dataset is already available ~5s after otbr-agent starts (even while still in "detached" state), so the seed captures the existing dataset and the first poll sees no change — no redundant write.

2. Clean stop: removed the unconditional cp from both the trap and the stop) handler. The daemon already syncs to flash whenever the dataset changes — no need for a final copy. Frame counters are ephemeral (OpenThread recovers by jumping ahead on next boot).