Long-running daemon does not reflect updated /etc/localtime after timezone change

Answer the Question First

Is it safe to call tzset() from a signal handler in a multi‑threaded daemon? No. tzset() is not async‑signal‑safe; invoking it directly from a signal handler can corrupt glibc’s shared timezone data or deadlock a mutex used by other threads.

Does glibc provide a portable way to invalidate its timezone cache? No. The cache is refreshed only by a subsequent call to tzset() (or a process restart). There is no signal or kernel event that automatically triggers a refresh.

Recommended pattern for a safe reload:

• Install a minimal handler for SIGUSR1 (or another user‑defined signal) that sets a volatile sig_atomic_t flag.
• In the main loop or a dedicated worker thread, periodically check the flag. When it is set, call tzset() once, then clear the flag.
• Optionally, use inotify to watch /etc/localtime for IN_MODIFY or IN_ATTRIB events and trigger the same flag‑driven tzset() call.
• Ensure that no other thread performs localtime(), strftime(), or mktime() while tzset() is running. In practice, calling tzset() from the main thread is safe because the glibc cache is protected by a mutex that other threads will block on.

Below is a compact code sketch that demonstrates the pattern:

#include <signal.h>
#include <time.h>
#include <stdatomic.h>

volatile sig_atomic_t tz_reload_flag = 0;

void sigusr1_handler(int signo) {
    tz_reload_flag = 1;  /* set flag only */
}

int main() {
    struct sigaction sa = { .sa_handler = sigusr1_handler };
    sigaction(SIGUSR1, &sa, NULL);

    while (1) {
        if (tz_reload_flag) {
            tzset();          /* safe here, single thread */
            tz_reload_flag = 0;
        }

        /* normal work: localtime(), strftime(), etc. */
        sleep(1);  /* placeholder for real work */
    }
}

Why a Direct Signal Handler Call is Unsafe

In glibc, tzset() manipulates global data structures protected by a mutex. Signal handlers run asynchronously and may interrupt any thread, including one holding that mutex. If tzset() is invoked while the mutex is locked, the handler will block until the mutex is released. If the handler runs in the same thread that holds the mutex, it will deadlock. Moreover, because signal handlers can be invoked at any time, other threads may concurrently read partially updated timezone data, leading to torn or inconsistent results.

Alternative: Inotify Watcher

For daemons that cannot rely on a user‑defined signal, inotify provides a reliable way to detect changes to /etc/localtime. A small watcher thread can block on the inotify descriptor, and when an IN_MODIFY event arrives, it sets the same tz_reload_flag and exits. The main thread then performs tzset() safely.

Missing Diagnostic Detail

Does your daemon use glibc or another C library such as musl? The behavior of tzset() and the caching mechanism differ between implementations, so the exact pattern may need adjustment if musl or a custom time library is in use.

Practical Verification Steps

1. Compile the sketch above and run it as a background process.
2. Change the system timezone using timedatectl set-timezone.
3. Send SIGUSR1 to the process: kill -SIGUSR1 <pid>.
4. Observe that subsequent localtime() calls return times in the new zone.
5. Use strace -e trace=localtime,strftime,mktime,tzset to confirm that tzset() is only invoked from the main thread.

Conclusion

To keep a long‑running daemon in sync with a timezone change, avoid calling tzset() from a signal handler. Instead, use a flag set by a minimal handler or an inotify watcher, and invoke tzset() in a controlled, single‑threaded context. Verify the library used by the daemon before applying this pattern.