Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ntp]: Add configuration to avoid ntpd from panic and exit #4263

Merged
merged 2 commits into from
Mar 22, 2020

Conversation

SuvarnaMeenakshi
Copy link
Contributor

- What I did
Add configuration to avoid ntpd from panic and exit if the drift between new time and current system time is large.
- How I did it
Added "tinker panic 0" in ntp.conf file.

- How to verify it
[this assumes that there is a valid NTP server IP in config_db/ntp.conf]

  1. Change the current system time to a bad time with a large drift from time in ntp server; drift should be greater than 1000s.
  2. Reboot the device.

Before the fix:
3. upon reboot, ntp-config service comes up fine, ntp service goes to active(exited) state without any error message. This is because the offset between new time (from ntp server) and the current system time is very large, ntpd goes to panic mode and exits. The system continues to show the bad time.

After the fix:
3. Upon reboot, ntp-config comes up fine, ntp services comes up from and stays in active (running) state. The system clock gets synced with the ntp server time.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

the drift between new time and current system time is large.
@jleveque
Copy link
Contributor

Retest vs please

@jleveque
Copy link
Contributor

Retest vsimage please

@zhenggen-xu
Copy link
Collaborator

With ntp "-g" starting option, I,E reverting: #2589 , Do you still see the panic? That "-g" worked well for me for difference cases, so just wondering if you see a case where even with "-g" you could get panic. Also I understood this PR won't hurt, just wanted to see if we can get to the bottom of the issue.

@jleveque
Copy link
Contributor

@SuvarnaMeenakshi: Have you had a chance to test @zhenggen-xu's hypothesis? The PR he is referring to was reverted in master yesterday via #4265.

@SuvarnaMeenakshi
Copy link
Contributor Author

With ntp "-g" starting option, I,E reverting: #2589 , Do you still see the panic? That "-g" worked well for me for difference cases, so just wondering if you see a case where even with "-g" you could get panic. Also I understood this PR won't hurt, just wanted to see if we can get to the bottom of the issue.

I tested with "-g" option, that after reverting #2589. I don't see the panic. "-g" works, "tinker panic 0" also works, deciding to keep both. Tested keeping both the options, and works fine.

@SuvarnaMeenakshi
Copy link
Contributor Author

retest vsimage please

@lguohan lguohan merged commit cfe754f into sonic-net:master Mar 22, 2020
rlhui pushed a commit that referenced this pull request Mar 23, 2020
- What I did
Add configuration to avoid ntpd from panic and exit if the drift between new time and current system time is large.

- How I did it
Added "tinker panic 0" in ntp.conf file.

- How to verify it
[this assumes that there is a valid NTP server IP in config_db/ntp.conf]

Change the current system time to a bad time with a large drift from time in ntp server; drift should be greater than 1000s.
Reboot the device.
Before the fix:
3. upon reboot, ntp-config service comes up fine, ntp service goes to active(exited) state without any error message. This is because the offset between new time (from ntp server) and the current system time is very large, ntpd goes to panic mode and exits. The system continues to show the bad time.

After the fix:
3. Upon reboot, ntp-config comes up fine, ntp services comes up from and stays in active (running) state. The system clock gets synced with the ntp server time.
yxieca pushed a commit that referenced this pull request Apr 3, 2020
- What I did
Add configuration to avoid ntpd from panic and exit if the drift between new time and current system time is large.

- How I did it
Added "tinker panic 0" in ntp.conf file.

- How to verify it
[this assumes that there is a valid NTP server IP in config_db/ntp.conf]

Change the current system time to a bad time with a large drift from time in ntp server; drift should be greater than 1000s.
Reboot the device.
Before the fix:
3. upon reboot, ntp-config service comes up fine, ntp service goes to active(exited) state without any error message. This is because the offset between new time (from ntp server) and the current system time is very large, ntpd goes to panic mode and exits. The system continues to show the bad time.

After the fix:
3. Upon reboot, ntp-config comes up fine, ntp services comes up from and stays in active (running) state. The system clock gets synced with the ntp server time.
tiantianlv pushed a commit to SONIC-DEV/sonic-buildimage that referenced this pull request Apr 24, 2020
…ic-net#4263)

- What I did
Add configuration to avoid ntpd from panic and exit if the drift between new time and current system time is large.

- How I did it
Added "tinker panic 0" in ntp.conf file.

- How to verify it
[this assumes that there is a valid NTP server IP in config_db/ntp.conf]

Change the current system time to a bad time with a large drift from time in ntp server; drift should be greater than 1000s.
Reboot the device.
Before the fix:
3. upon reboot, ntp-config service comes up fine, ntp service goes to active(exited) state without any error message. This is because the offset between new time (from ntp server) and the current system time is very large, ntpd goes to panic mode and exits. The system continues to show the bad time.

After the fix:
3. Upon reboot, ntp-config comes up fine, ntp services comes up from and stays in active (running) state. The system clock gets synced with the ntp server time.
@SuvarnaMeenakshi SuvarnaMeenakshi deleted the sumeenak_ntp branch December 14, 2020 09:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants