Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve support for illumos and Solaris #1252

Open
pitdicker opened this issue Sep 4, 2023 · 3 comments
Open

Improve support for illumos and Solaris #1252

pitdicker opened this issue Sep 4, 2023 · 3 comments

Comments

@pitdicker
Copy link
Collaborator

pitdicker commented Sep 4, 2023

There are several very informative comments in the time-rs repo.
From time-rs/time#543 (comment):

The illumos implementations of tzset(3C), localtime_r(3C), setenv(3C), and getenv(3C), all have an MT-Level of Safe or MT-Safe; MT-Level and other attributes are described in attributes(7). We inherited them a decade ago when we forked from Solaris, so I would expect that Solaris is also thread safe for all of these routines.

In addition to thread safety, our time zone configuration is a bit different from a Linux system, though most of this is hidden from a consuming process behind the standard entrypoints like localtime_r(), etc.

A process determines the local time zone in roughly this way:

  • if TZ is set in the environment, we'll use it uncritically to select the zone
  • if TZ is not set, we'll read the TIMEZONE(5) file: a text file which is allowed to contain a TZ= line specifying the time zone
  • otherwise, we'll default to GMT0

Iff a process does not have TZ set in its environment, we cache the value read from /etc/TIMEZONE the first time we try to establish a local time, and the zone information from the zoneinfo file. This cache can be purged in all processes on the system by a privileged user with the tzreload(8) command. One can, thus, reconfigure the local system time zone while software is running. If a process does have TZ set in its environment then tzreload won't change the time zone for that process, but it will still invalidate the cache of the nominated zone file, which might have been patched in a package update to reflect an updated set of time zone information without needing to restart all the software on the system.

Historically systems like Java and Go and so on have created challenges for operators by ignoring the local time zone database, or at least some of the system facilities for configuring and refreshing it. It would be really great if we could avoid having that happen with Rust, where there are truly superlative facilities for using system library routines through FFI, etc!

@pitdicker
Copy link
Collaborator Author

We don't support the /etc/TIMEZONE file on illumos and Solaris yet, or the invalidation mechanism.

@Kijewski
Copy link
Contributor

Kijewski commented Jan 8, 2024

Evaluating /etc/TIMEZONE is implemented in iana-time-zone: tz_illumos.rs

@djc
Copy link
Contributor

djc commented Jan 9, 2024

Let's wait for someone who has an actual Illumos/Solaris use case to implement this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants