No time zone on Solaris servers
Hi list, We downloaded tzdb2022c and compiled it on a Solaris 10 server with TOPDIR=/newtz and other default config parameters. After compiling is finished, the zoneinfo directory is copied to an other Solaris server, then the date command does not show any time zone on the host. It seems the server is at UTC time zone. Can anybody point me on how to fix it? Thank you very much! Wei Sent from Yahoo Mail for iPhone
On 8/23/22 13:25, W CUI via tz wrote:
the date command does not show any time zone on the host. It seems the server is at UTC time zone.
Please run the shell command 'LC_ALL=America/Los_Angeles truss date' and see where 'date' is looking for the TZif file containing data for Los Angeles. Most likely 'date' is looking at a directory other than where you installed the TZif files.
On 8/24/22 22:29, Paul Eggert via tz wrote:
On 8/23/22 13:25, W CUI via tz wrote:
the date command does not show any time zone on the host. It seems the server is at UTC time zone.
Please run the shell command 'LC_ALL=America/Los_Angeles truss date' and see where 'date' is looking for the TZif file containing data for Los Angeles. Most likely 'date' is looking at a directory other than where you installed the TZif files.
Oh, sorry, I gave you the wrong shell command. It should be: LC_ALL=C TZ=America/Los_Angeles truss date
"truss" command output is here. The date command is looking for the correct zoneinfo file, but there is no correct time zone output. #:>LC_ALL=C TZ=America/Los_Angeles truss dateexecve("/usr/bin/date", 0x08047AE4, 0x08047AEC) argc = 1sysinfo(SI_MACHINE, "i86pc", 257) = 6mmap(0x00000000, 32, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFF0000mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFB0000mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFA0000memcntl(0xFEFBE000, 13408, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0memcntl(0x08050000, 2500, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0resolvepath("/usr/lib/ld.so.1", "/lib/ld.so.1", 1023) = 12resolvepath("/usr/bin/date", "/usr/bin/date", 1023) = 13sysconfig(_CONFIG_PAGESIZE) = 4096stat64("/usr/bin/date", 0x080476D0) = 0open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENTstat64("/lib/libc.so.1", 0x08046F80) = 0resolvepath("/lib/libc.so.1", "/lib/libc.so.1", 1023) = 14open("/lib/libc.so.1", O_RDONLY) = 3mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0) = 0xFEF90000mmap(0x00010000, 1216512, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEE60000mmap(0xFEE60000, 1107293, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFEE60000mmap(0xFEF7F000, 30375, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 1110016) = 0xFEF7F000mmap(0xFEF87000, 4328, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFEF87000munmap(0xFEF6F000, 65536) = 0munmap(0xFEF90000, 32768) = 0close(3) = 0mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF90000memcntl(0xFEE60000, 124768, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEF70000getcontext(0x08047540)getrlimit(RLIMIT_STACK, 0x08047538) = 0getpid() = 3784 [3780]lwp_private(0, 1, 0xFEF72A00) = 0x000001C3setustack(0xFEF72A60)sysi86(SI86FPSTART, 0xFEF87798, 0x0000133F, 0x00001F80) = 0x00000001brk(0x08062ED0) = 0brk(0x08064ED0) = 0time() = 1661427357open("/var/run/tzsync", O_RDONLY) = 3mmap(0x00000000, 4, PROT_READ, MAP_SHARED, 3, 0) = 0xFEE50000close(3) = 0brk(0x08064ED0) = 0brk(0x08066ED0) = 0open("/usr/share/lib/zoneinfo/America/Los_Angeles", O_RDONLY) = 3fstat64(3, 0x08047940) = 0mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEE30000read(3, " T Z i f 2\0\0\0\0\0\0\0".., 1294) = 1294close(3) = 0ioctl(1, TCGETA, 0x08047954) = 0fstat64(1, 0x080478C0) = 0Thu Aug 25 11:35:57 2022write(1, " T h u A u g 2 5 1".., 26) = 26_exit(0)#:>#:>dateThu Aug 25 11:37:24 2022 The date command output should be something like:Thu Aug 25 08:59:57 EDT 2022 ---- Anyway, updating these two lines in Makefile then compile again seems fixed the problem. DATAFORM= rearguardZFLAGS= -b fat Again, it is a very old Solaris 10 server. Thank you for your help. On Thursday, August 25, 2022 at 12:00:40 AM EDT, Paul Eggert <eggert@cs.ucla.edu> wrote: On 8/24/22 22:29, Paul Eggert via tz wrote:
On 8/23/22 13:25, W CUI via tz wrote:
the date command does not show any time zone on the host. It seems the server is at UTC time zone.
Please run the shell command 'LC_ALL=America/Los_Angeles truss date' and see where 'date' is looking for the TZif file containing data for Los Angeles. Most likely 'date' is looking at a directory other than where you installed the TZif files.
Oh, sorry, I gave you the wrong shell command. It should be: LC_ALL=C TZ=America/Los_Angeles truss date
On 8/25/22 16:30, W CUI wrote:
execve("/usr/bin/date", 0x08047AE4, 0x08047AEC) argc = 1
Oh, I think I see the problem now. You're running 32-bit Solaris 10, which predates Internet RFC 8536 and does not follow its Section 4 recommendation "When reading a version 2 or 3 file, implementations SHOULD ignore the version 1 header and data block except for the purpose of skipping over them." <https://www.rfc-editor.org/rfc/rfc8536#section-4> For these obsolescent systems, you should install fat files, e.g,: make TOPDIR=/newtz ZFLAGS='-b fat' install Fat files contain extra 32-bit data needed by obsolescent 32-bit-only TZif readers like 32-bit Solaris 10. Oracle says they'll support Solaris 10 only through January 2024, and might have not worried that 32-bit Solaris 10 does not follow that RFC 8536 recommendation, as 32-bit Solaris apps (even if running in compatibility mode in current Solaris) will stop working anyway in the year 2038 due to time_t wraparound. However, as you have found, it is awkward that 32-bit Solaris 10 can't read today's TZif files, so if you are an Oracle customer who needs to run old executables with current TZ data you might consider filing a bug report with Oracle about this issue.
participants (2)
-
Paul Eggert -
W CUI