Restart chrony/ntp service on interfaces-config restart - #69
Conversation
Signed-off-by: Anand Mehra (anamehra) <anamehra@cisco.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| ''' | ||
| ntp_service = get_ntp_service_name() | ||
|
|
||
| if ntp_service: |
There was a problem hiding this comment.
Should this behavior be handled by interfaces-config or systemd service dependency instead of ZTP? ZTP should ideally not manage unrelated service lifecycle.
There was a problem hiding this comment.
Addressed in 840e0de. I kept this scoped to ZTP because this is the code path explicitly restarting interfaces-config during discovery/resume/remove. chrony.service already has After=interfaces-config.service for startup ordering, but that does not restart/rebind chrony when ZTP later runs systemctl restart interfaces-config. Adding reverse ordering/dependencies from interfaces-config back to NTP/chrony risks an ordering cycle, so I did not alter the systemd unit dependencies in this PR.
| runCommand('systemctl stop ' + ntp_service, capture_stdout=False) | ||
|
|
||
| logger.info('Restarting interfaces-config service...') | ||
| runCommand('systemctl restart interfaces-config', capture_stdout=False) |
There was a problem hiding this comment.
If interfaces-config restart fails, will the NTP service be restarted? Consider using finally/cleanup handling to avoid leaving NTP stopped.
There was a problem hiding this comment.
Addressed in 840e0de. The Python path now wraps the interfaces-config restart in try/finally so the active NTP service is started again even if an unexpected exception occurs, and it logs a nonzero interfaces-config return code. The shell path now uses a shared restart_interfaces_config_with_ntp helper that captures the restart rc, starts NTP afterward, and returns the original rc.
| ntp_services = ['chrony', 'ntp'] | ||
| for service in ntp_services: | ||
| try: | ||
| rc = runCommand('systemctl is-enabled ' + service, capture_stdout=True) |
There was a problem hiding this comment.
Should we check the active service instead of the enabled service here? A service can be enabled but not running, so checking active status may better reflect the NTP service currently in use
There was a problem hiding this comment.
Addressed in 840e0de. Detection now uses systemctl is-active --quiet for chrony/ntp in both ztp-engine.py and ztp-profile.sh, so only the service that was actually running before the interfaces-config restart is stopped and started again.
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Signed-off-by: Anand Mehra (anamehra) <anamehra@cisco.com>
840e0de to
024b2ba
Compare
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
3 participants
Restart NTP service when interfaces-config restarts
Problem
When ZTP restarts the
interfaces-configservice (during link scan or periodic restarts), it causes issues with the NTP service if management VRF is configured.Why this happens:
interfaces-configchanges the network namespace and VRF configurationSolution
Added logic to detect which NTP service is running (chrony or ntp) and restart it around the
interfaces-configrestart:This ensures NTP continues working correctly in the management VRF after network reconfigurations.
Changes
get_ntp_service_name()function to detect which service is available, and__restart_network_services()method to handle the restart sequenceget_ntp_service()function and updated install/remove sections to stop/start NTP around interfaces-config restartsWhy detect the service?
Different SONiC releases use different NTP implementations (ntp vs chrony), so we check which one is actually running instead of hardcoding it. The code checks in priority order: chrony first, then ntp.