search

saltstack / salt

Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:
https://repo.saltproject.io/
Apache License 2.0
14.17k stars 5.48k forks source link

[BUG] timezone.system cannot be applied AlmaLinux 9: Failed to read /etc/localtime #65719

Open leeclemens opened 10 months ago

leeclemens commented 10 months ago

Description Unable to apply timezone.system on new AlmaLinux 9 system because /etc/localtime does not exist.

Setup

system_timezones:
  timezone.system:
    - name: UTC
    - utc: True

Please be as specific as possible and give set-up details.

AWS AlmaLinux 9 x86_64 AMI

Steps to Reproduce the behavior Try to apply the state on a clean system from the AMI

2023-12-17 02:49:53,200 [salt.state       :323 ][ERROR   ][11453] Unable to compare desired timezone 'UTC' to system timezone: Failed to read /etc/localtime to determine current timezone: No such file or directory

Expected behavior timedatectl does return the correct timezone, so I expected salt to be able to determine the timezone; or at the last configure it as specified in the state.

Screenshots N/A

Versions Report

Minion ```yaml Salt Version: Salt: 3006.5 Python Version: Python: 3.10.13 (main, Nov 15 2023, 04:34:27) [GCC 11.2.0] Dependency Versions: cffi: 1.14.6 cherrypy: 18.6.1 dateutil: 2.8.1 docker-py: Not Installed gitdb: Not Installed gitpython: Not Installed Jinja2: 3.1.2 libgit2: Not Installed looseversion: 1.0.2 M2Crypto: Not Installed Mako: Not Installed msgpack: 1.0.2 msgpack-pure: Not Installed mysql-python: Not Installed packaging: 22.0 pycparser: 2.21 pycrypto: Not Installed pycryptodome: 3.9.8 pygit2: Not Installed python-gnupg: 0.4.8 PyYAML: 6.0.1 PyZMQ: 23.2.0 relenv: 0.14.2 smmap: Not Installed timelib: 0.2.4 Tornado: 4.5.3 ZMQ: 4.3.4 System Versions: dist: almalinux 9.3 Shamrock Pampas Cat locale: utf-8 machine: x86_64 release: 5.14.0-362.8.1.el9_3.x86_64 system: Linux version: AlmaLinux 9.3 Shamrock Pampas Cat ```
Master ```yaml Salt Version: Salt: 3006.5 Python Version: Python: 3.10.13 (main, Nov 15 2023, 04:34:27) [GCC 11.2.0] Dependency Versions: cffi: 1.14.6 cherrypy: unknown dateutil: 2.8.1 docker-py: Not Installed gitdb: Not Installed gitpython: Not Installed Jinja2: 3.1.2 libgit2: Not Installed looseversion: 1.0.2 M2Crypto: Not Installed Mako: Not Installed msgpack: 1.0.2 msgpack-pure: Not Installed mysql-python: Not Installed packaging: 22.0 pycparser: 2.21 pycrypto: Not Installed pycryptodome: 3.9.8 pygit2: Not Installed python-gnupg: 0.4.8 PyYAML: 6.0.1 PyZMQ: 23.2.0 relenv: 0.14.2 smmap: Not Installed timelib: 0.2.4 Tornado: 4.5.3 ZMQ: 4.3.4 System Versions: dist: centos 7.9.2009 Core locale: utf-8 machine: x86_64 release: 3.10.0-1160.105.1.el7.x86_64 system: Linux version: CentOS Linux 7.9.2009 Core ```

Additional context I also tried calling timedatectl set-timezone UTC explicitlely - same issue.

Output from timedatectl (no change):

$ timedatectl 
               Local time: Sun 2023-12-17 03:43:37 UTC
           Universal time: Sun 2023-12-17 03:43:37 UTC
                 RTC time: Sun 2023-12-17 03:43:36
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
leeclemens commented 10 months ago

It seems to me that timezone.get_zone should be the source of truth in determining the current timezone rather than have duplicated (or worse, different) methods determining the same fact.

Regarding the hash check in timezone.compare_zone, is that adding value? timedatetectl returns a name, would it ever differ from the binary tzfile it loaded? Would /etc/localtime, usually a symlink in my experience, ever differ from the file it links to (but where the names match)?