Start a conversation Sign in
Start a conversation
  1. NewNet
  2. NewNet Articles
  3. Articles

NewNet Traffic Server: <code>tp_config</code> (No Options) Applies Node Configuration and Restarts RTR (<code>textpass</code>)

Overview

When running tp_config to force-apply MGR configuration changes on a NewNet traffic server node, RTR (textpass) may restart and cause a brief service interruption on that node. This is verified current product behavior when tp_config is executed without options, and it can be observed in tp_status as a transient non-operating state followed by uptime reset.

Key Information

  • Symptom / indicator: After running tp_config, tp_status may briefly show a non-operational state and then return to operating with uptime reset. Example observed sequence: 
    textpass adminDisabled 0 days, 0:00:03.10
textpass operating
  • Verified behavior: running tp_config with no options
    • Applies node-relevant configuration files for that traffic server node.
    • Includes applying MGRData.xml (which contains List entries used by message processing).
    • Restarts RTR (textpass) as part of applying the configuration.
  • Targeted restarts (only when options are used): Other processes/components are restarted only if explicitly targeted with component-specific parameters (examples: --texthub, --textlgp).
  • Validation-only modes do not restart processes: Validation modes (examples: --validateonly, --validatecommonconfig) check configuration without triggering process restarts.
  • Observed impact
    • Expected impact for the no-option case: brief unavailability of textpass on the node where tp_config is executed.
    • Log review identified no additional impacts beyond the restart/downtime window for the no-option case.
    • Downtime duration is environment-dependent: ~5–7 seconds was observed in a simple lab configuration; complex/production-like configurations may take longer and an exact duration cannot be guaranteed.
  • How to confirm the behavior (quick verification):
    1. Run tp_status and confirm textpass is operating and note uptime.
    2. Run tp_config on the node (expect brief service interruption on that node).
    3. Run tp_status repeatedly until textpass returns to operating, noting the transient state and uptime reset.
    4. Optionally verify the configuration change using tp_walkall (compare before/after or check the specific List/config item expected to change).
  • Product state: No engineering fix or version change is associated with this behavior; it is confirmed as current product behavior.
  • Simplified flow (text-only):
    1. Operator runs tp_config (no options).
    2. Node configuration is reloaded/applied (including MGRData.xml).
    3. RTR (textpass) is stopped/reinitialized.
    4. textpass temporarily enters a non-operating state (example observed: adminDisabled).
    5. textpass returns to operating with uptime reset.
    6. Operator validates with tp_status and confirms expected config via tp_walkall and/or functional checks.

Customer Impact

Treat tp_config (no options) as a disruptive action on the traffic server node where it is executed, because RTR (textpass) restarts and message processing on that node may be briefly unavailable.

If redundancy exists, run tp_config node-by-node during a planned window, waiting for textpass to return to operating before proceeding to the next node. To set downtime expectations, measure restart duration in a test environment that mirrors production (configuration complexity and data scale). When applicable, use validation-only modes first (for example tp_config --validateonly or tp_config --validatecommonconfig) to confirm configuration correctness without restarting processes.

Frequently Asked Questions

1. How can this issue be identified quickly?
If tp_config causes a restart, tp_status will show textpass uptime reset and it may briefly show a state like textpass adminDisabled 0 days, 0:00:03.10 before returning to textpass operating.
2. Does tp_config (no options) apply List entries and make them effective for message processing, without restarting other components?
Yes. Running tp_config without options applies node-relevant configuration files (including MGRData.xml containing List entries) and the verified restart behavior is limited to RTR (textpass) for the no-option case.
3. Is RTR (textpass) restart the only impact when running tp_config without options?
Based on reproduction in a test environment and review of logs, no additional impacts beyond brief textpass downtime were identified for the no-option case.
4. Can tp_config restart other processes like HUB?
It can when explicitly targeted with component-specific parameters (for example options such as --texthub / --textlgp, depending on your environment and documentation). Without options, the confirmed restart behavior was textpass (RTR).
5. How long will RTR be unavailable during tp_config?
The exact duration cannot be guaranteed and depends on configuration complexity and environment performance. A simple lab test observed ~5–7 seconds, but production-like configurations may take longer. Measure by running tp_config in a test environment that mirrors production and timing how long tp_status shows textpass as non-operational before returning to operating.
6. Is there a way to check configuration validity without restarting RTR?
Yes. Validation-only modes (for example tp_config --validateonly / tp_config --validatecommonconfig) do not restart processes and can be used to check for configuration issues before applying disruptive changes.
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Mohammed Amer

  2. Posted
  3. Updated

Comments