When your Debian server shows NTP service as running (/etc/init.d/ntp status) but the system clock remains incorrect by several minutes, we need to investigate multiple layers of the time synchronization stack.

First check the actual NTP synchronization status:

ntpq -pn
ntpstat
timedatectl status

The key indicators to examine:

• Reach value (should show 377 for fully synchronized state)
• Offset value (should be in milliseconds range when synced)
• Stratum level (should be 1-16, lower is better)

Network Connectivity Issues:

# Test NTP server connectivity
ntpdate -q 0.europe.pool.ntp.org

Firewall rules often block NTP traffic (UDP port 123):

# Check iptables rules
iptables -L -n | grep 123
# Temporary test rule
iptables -I INPUT -p udp --dport 123 -j ACCEPT

Configuration Problems:

Ensure your ntp.conf has proper time servers:

# Recommended minimum configuration
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

NTP normally won't correct time differences greater than 1000 seconds by default. For initial sync of large offsets:

# Stop NTP first
systemctl stop ntp
# Force time sync
ntpdate -u pool.ntp.org
# Restart NTP
systemctl start ntp

For systems needing precise time immediately:

# Using chrony (modern alternative)
apt install chrony
chronyc sources -v
chronyc tracking

Or using systemd-timesyncd:

timedatectl set-ntp true
systemctl restart systemd-timesyncd

Check detailed synchronization status:

ntpq -c "rv 0 stratum,offset,delay,jitter"
watch -n 1 ntptime

Examine the drift file for hardware clock issues:

cat /var/lib/ntp/ntp.drift

---

When your Debian server shows ntpd running but the system clock remains significantly off (5 minutes in this case), there are several potential causes to investigate. The key indicators from the original scenario:

$ /etc/init.d/ntp status
NTP server is running..

Yet ntpq -p showed all servers marked as .INIT. state, indicating no successful synchronization.

First, verify NTP server connectivity with these essential commands:

# Check NTP service status
systemctl status ntp

# Verify NTP server connectivity
ntpq -p

# Test manual synchronization (requires ntpdate)
ntpdate -u pool.ntp.org

The resolution revealed a common pitfall - network restrictions. NTP uses UDP port 123. Check firewall rules:

# Check current iptables rules
iptables -L -n | grep 123

# Temporary test: allow NTP traffic
iptables -I INPUT -p udp --dport 123 -j ACCEPT

For reliable time synchronization, consider these /etc/ntp.conf improvements:

# Use multiple diverse time sources
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst

# Local clock as fallback (stratum 10)
server 127.127.1.0
fudge 127.127.1.0 stratum 10

# Enable kernel discipline
tinker panic 0

After configuration changes, monitor synchronization status:

# Check synchronization status
ntpstat

# Detailed peer information
ntpq -pn

# View clock discipline statistics
ntpdc -c kerninfo

For environments with strict firewalls, consider:

1. Using HTTP-based time services (requires custom scripts)
2. Setting up a local NTP server with outbound-only access
3. Using chrony as an alternative to ntpd

Example chrony configuration:

server time.google.com iburst
server time.windows.com iburst
makestep 1.0 3

After implementing changes, verify with:

# Check system clock vs NTP
timedatectl status

# View NTP synchronization details
chronyc tracking  # if using chrony
ntpq -c rv        # if using ntpd