RDKEMW-20801: increase OCDM service auto-start retry count to 400#246
Open
sergiygladkyy wants to merge 1 commit into
Open
RDKEMW-20801: increase OCDM service auto-start retry count to 400#246sergiygladkyy wants to merge 1 commit into
sergiygladkyy wants to merge 1 commit into
Conversation
Reason for change: post-FSR provisioning can outlast the 200-attempt window (~101s); OCDM then gives up and fails the Thunder target. Raise the retry cap to 400 (~203s) to cover the observed provisioning delay. Follows RDKEMW-5207, which set the count to 200 for the same reason. Test Procedure: FSR then connect; confirm wpeframework-ocdm.service reaches active (exited) instead of failed when provisioning takes over 200 attempts. Implements: updates to wpeframework-ocdm.service Risks: No Source: COMCAST License: Apache-2.0 Upstream-Status: Pending Signed-off-by: Sergiy Gladkyy <sgladkyy@productengine.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the OCDM systemd oneshot unit to tolerate longer device-provisioning delays by increasing the PluginActivator retry count during service start.
Changes:
- Increased
wpeframework-ocdm.servicePluginActivator retry count from-r 200to-r 400to extend the maximum precondition polling window.
Comment on lines
7
to
+9
| Type=oneshot | ||
| RemainAfterExit=yes | ||
| ExecStart=/usr/bin/PluginActivator -r 200 OCDM | ||
| ExecStart=/usr/bin/PluginActivator -r 400 OCDM |
Contributor
Author
There was a problem hiding this comment.
This needs to be tested. Will include in DEV QA flow. We can add a param TimeoutStartSec=360, but by checking the actual logs, we can tell that it's not 90s already, it is more, since -r 200 is 100+s and the unit fails on attempts always and never on timeout
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RDKEMW-20801: increase OCDM service auto-start retry count to 400
What
wpeframework-ocdm.service:PluginActivator -r 200 OCDM->-r 400.Why
On a factory-reset device, DeviceProvisioning fetches DRM credentials from FKPS before the PROVISIONING precondition can be met. OCDM is force-activated by systemd meanwhile and polls for the precondition. The current 200-attempt cap (~101s at ~0.5s/attempt) can expire before provisioning completes; OCDM then fails and takes the WPEFramework target down with it.
On the reported capture (Apache-2K, 8.3.4.15) provisioning completed ~149s after OCDM's first attempt, past the ~101s window. Doubling the cap to 400 (~203s) covers the observed delay.
This repeats RDKEMW-5207 (#68), which set the count to 200 for the same reason; the value is raised again with the same one-line change.
Scope / risk
No. Healthy boots break the poll on the first successful activation, so the wider cap is only exercised on the slow-provisioning path. It does not address the start-while-disconnected case, which is tracked separately.
Test
FSR then connect; confirm
wpeframework-ocdm.servicereachesactive (exited)rather thanfailedwhen provisioning takes more than 200 attempts.