Thanks, all, for taking the time to look into my bug report. Since I don't control the application that first caused me to notice this bug, and I can't stop it from preferring /etc/timezone over other time zone sources, I will implement the given workaround on my servers. Thank you for providing an official workaround and stance on the issue.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2103839 Title: timedatectl set-timezone does not update /etc/timezone, leaving system with inconsistent time zone setting Status in systemd package in Ubuntu: Won't Fix Status in systemd source package in Noble: Won't Fix Status in systemd source package in Oracular: Won't Fix Bug description: [WORKAROUND FOR AFFECTED USERS] /etc/timezone will be dropped entirely in Ubuntu 25.10. Please update affected applications to use /etc/localtime instead of /etc/timezone. Please see [1], and more specifically [2], if you need to keep /etc/timezone up-to-date on Ubuntu 24.04 LTS. [1] https://discourse.ubuntu.com/t/how-to-change-the-time-zone-in-ubuntu-using-the-command-line/35307 [2] https://discourse.ubuntu.com/t/how-to-change-the-time-zone-in-ubuntu-using-the-command-line/35307/2 [Original Description] In Ubuntu 24.04 server, setting the system time zone via systemd's timedatectl fails to update the contents of /etc/timezone. In previous LTS server releases, timedatectl updated this file without any issue, so this is new faulty behavior. Because there are several different ways to query for the system's time zone (e.g., timedatectl, /etc/localtime, /etc/timezone), this bug leaves the system time zone in an inconsistent state, with the answer depending on the query method. For example, I discovered this bug when installing the latest version of Jenkins on Ubuntu 24.04, where Jenkins insisted my server was on UTC even though timedatectl would report back "America/Chicago". It turned out that Jenkins was reading the system time zone from /etc/timezone, which had never been updated after I set the timezone via timedatectl. I don't know for certain, but I believe that /etc/timezone is a common way for Java-based applications to read the system time zone. I think there has been talk of removing /etc/timezone entirely from Debian, since it could be considered redundant, which may be why timedatectl has changed its behavior here. I would be fine with that solution except for the fact that when I delete /etc/timezone on Ubuntu 24.04, it keeps getting recreated. I believe whenever the tzdata package is updated, that regenerates /etc/timezone, and a "dpkg-reconfigure tzdata" certainly does. If nothing else, there is an inconsistency in Ubuntu 24.04 between the behavior of timedatectl and the behavior of tzdata, and this inconsistent behavior can lead to an inconsistent time zone setting. Steps to reproduce the bug: ``` $ timedatectl show --property=Timezone Timezone=America/New_York $ ls -la /etc/localtime lrwxrwxrwx 1 root root 36 Mar 21 21:46 /etc/localtime -> /usr/share/zoneinfo/America/New_York $ cat /etc/timezone America/New_York $ sudo timedatectl set-timezone 'America/Chicago' $ timedatectl show --property=Timezone Timezone=America/Chicago $ ls -la /etc/localtime lrwxrwxrwx 1 root root 35 Mar 21 20:51 /etc/localtime -> /usr/share/zoneinfo/America/Chicago $ cat /etc/timezone America/New_York $ sudo dpkg-reconfigure --frontend noninteractive tzdata 2> /dev/null $ cat /etc/timezone America/Chicago ``` ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: systemd 255.4-1ubuntu8.5 ProcVersionSignature: Ubuntu 6.8.0-55.57-generic 6.8.12 Uname: Linux 6.8.0-55-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.3 Architecture: amd64 CasperMD5CheckResult: pass Date: Fri Mar 21 18:20:28 2025 InstallationDate: Installed on 2025-02-11 (38 days ago) InstallationMedia: Ubuntu-Server 24.04.1 LTS "Noble Numbat" - Release amd64 (20240827) Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: VMware, Inc. VMware7,1 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-55-generic root=UUID=d1d2bd07-2fa1-4f46-b54e-6b249e25a778 ro SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/07/2020 dmi.bios.vendor: VMware, Inc. dmi.bios.version: VMW71.00V.16707776.B64.2008070230 dmi.board.name: 440BX Desktop Reference Platform dmi.board.vendor: Intel Corporation dmi.board.version: None dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 1 dmi.chassis.vendor: No Enclosure dmi.chassis.version: N/A dmi.modalias: dmi:bvnVMware,Inc.:bvrVMW71.00V.16707776.B64.2008070230:bd08/07/2020:svnVMware,Inc.:pnVMware7,1:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:sku: dmi.product.name: VMware7,1 dmi.product.version: None dmi.sys.vendor: VMware, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2103839/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
