Q.) timedatectl outputs :
Local time: Tue 2024-10-21 13:35:31 PDT Universal time: Tue 2024-10-21 20:35:31
UTC RTC time: Tue 2024-10-21 20:35:30
Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
chronyc sources outputs :
210 Number of sources = 8
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^? excalibur.prolixium.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? paladin.latt.net 0 9 0 - +0ns[ +0ns] +/- 0ns
^? ronin.ruselabs.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 2a00:7600::41 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 50-205-244-112-static.hf> 0 9 0 - +0ns[ +0ns] +/- 0ns
^? time.cloudflare.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 69.10.161.7 0 9 0 - +0ns[ +0ns] +/- 0ns
^? ntp3.your.org 0 9 0 - +0ns[ +0ns] +/- 0ns
No error in chrony logs and service is active and running.
How to troubleshoot this ?
Q.) How would you troubleshoot a system with performance degradation after a recent update?
Q.) Troubleshoot the below issue :
mount: mount.nfs: access denied by server while mounting
rpc.mountd[8111]: refused mount request from *.*.*.* for /home/export (/home/export): illegal port 21645
Level L2 and above.
I'll be posting a series of Linux-related questions covering various skill levels. Feel free to share your insights and expertise. Your contributions will benefit learners at all stages, from those in current roles to those preparing for Linux interviews.
How to troubleshoot the issue involving chrony?
Looking at the output of chrony sources, that question mark (?), in the 'S' column,
indicates that connectivity to the source on this line has been lost.
With the chrony logs showing no errors, and the service (chronyd) is active and
running, this is an indication that chrony is currently functioning as intended, and
successfully synchronizing the system with its configured time sources. However,
time synchronization issues may be occuring due to network connectivity challenges,
or incorrect time server configurations in the chrony settings.
To locate the issue as to why connectivity to the time sources have been lost, along
with why time sync challenges may be occuring, investigate the following:
Verify time source accuracy:
Check if the time servers listed in the chrony configuration are reliable and
accessible from your system.
Network connectivity:
Ensure the system has a stable Internet connection to reach the time servers.
Firewall settings:
Check if a firewall is blocking UDP traffic on port 123; this is used for NTP communication.
Chrony configuration:
Review your /etc/chrony file to confirm the correct time servers and settings are used.
Check for recent system changes:
If the issue started recently, review any recent system updates or configuration
changes that might have impacted chrony.
With all 8 of those time sources showing a question mark (?) in the "S" column,
this suggest to me that there is a reachability problem. So, I'm going to start by
taking a look any firewall(s) to ensure that UDP traffic on port 123 is not somehow
being interferred with.
How to troubleshoot the issue involving chrony?
Looking at the output of chrony sources, that question mark (?), in the 'S' column,
indicates that connectivity to the source on this line has been lost.
With the chrony logs showing no errors, and the service (chronyd) is active and
running, this is an indication that chrony is currently functioning as intended, and
successfully synchronizing the system with its configured time sources. However,
time synchronization issues may be occuring due to network connectivity challenges,
or incorrect time server configurations in the chrony settings.
To locate the issue as to why connectivity to the time sources have been lost, along
with why time sync challenges may be occuring, investigate the following:
Verify time source accuracy:
Check if the time servers listed in the chrony configuration are reliable and
accessible from your system.
Network connectivity:
Ensure the system has a stable Internet connection to reach the time servers.
Firewall settings:
Check if a firewall is blocking UDP traffic on port 123; this is used for NTP communication.
Chrony configuration:
Review your /etc/chrony file to confirm the correct time servers and settings are used.
Check for recent system changes:
If the issue started recently, review any recent system updates or configuration
changes that might have impacted chrony.
With all 8 of those time sources showing a question mark (?) in the "S" column,
this suggest to me that there is a reachability problem. So, I'm going to start by
taking a look any firewall(s) to ensure that UDP traffic on port 123 is not somehow
being interferred with.
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.