CM Timezone Does Not Match

Luke Hebert

- 2 minutes read - 277 words

A timezone mismatch in Cloudera Manager is a small alert that can snowball into confusing log timestamps, failed scheduled jobs, and misaligned audit trails across your cluster. The fix is straightforward once you know which files to look at.

Why It Matters

Cloudera Manager validates that every node in the cluster reports the same timezone. If even one host drifts, CM flags the alert and downstream services (HDFS, YARN, Hive, Impala) may log events with inconsistent timestamps. That makes troubleshooting and compliance reporting painful.

Files to Check

Different Linux distributions store timezone information in different places. Verify all three of the following on every node:

  • /etc/sysconfig/clock (RHEL, CentOS, SLES)
  • /etc/localtime (symlink to the zone file under /usr/share/zoneinfo/)
  • /etc/timezone (Debian, Ubuntu)

How to Align Them

  1. Decide on the target timezone (for example, America/Chicago).
  2. On each node, run timedatectl set-timezone America/Chicago (systemd-based distros) or update the files manually.
  3. Confirm the symlink: ls -l /etc/localtime should point to /usr/share/zoneinfo/America/Chicago.
  4. If the distro uses /etc/timezone, make sure it contains the same zone string.
  5. Restart the Cloudera Manager agent on that node: systemctl restart cloudera-scm-agent.
  6. Return to the CM console and verify the alert has cleared.

Quick Verification

Run this one-liner on each host to confirm consistency:

date && cat /etc/timezone 2>/dev/null; readlink -f /etc/localtime

All nodes should return the same zone path and a matching wall-clock time.

Note

If you are running containers (Docker or Kubernetes), the timezone is inherited from the host unless you explicitly mount /etc/localtime into the container. A mismatch here will still trigger the CM alert even though the host files look correct.

Once every node agrees, the alert disappears and your logs line up again.