daemon: add SdNotifyMonotonicUsec helper function

[corhere]

The synchronized service reload protocol added in systemd version 253 requires that the service provides a MONOTONIC_USEC field alongside the RELOADING=1 notification message for synchronization purposes. The value carried in this field must be the system CLOCK_MONOTONIC timestamp at the time the notification message was generated as systemd compares it to other CLOCK_MONOTONIC timestamps taken by pid1.

While the Go standard library does utilize CLOCK_MONOTONIC in the implementation of package "time", the absolute monotonic timestamps in time.Time values are not made available to programmers. Users familiar with idiomatic usage of monotonic timestamps in Go might (incorrectly) try to implement MONOTONIC_USEC using process-relative monotonic timestamps, like so:

var processStart = time.Now()

func NotifyReloadingINCORRECT() {
	ts := time.Since(processStart)/time.Microsecond  // WRONG
	msg := fmt.Sprintf(
		daemon.SdNotifyReload+"\nMONOTONIC_USEC=%d", ts,
	)
	_, _ = daemon.SdNotify(false, msg)
}

Help users fall into the pit of success by providing a helper function SdNotifyMonotonicUsec() which returns a MONOTONIC_USEC variable-assignment string which encodes the system CLOCK_MONOTONIC timestamp in decimal microseconds, as systemd expects.

[thaJeztah]

@cgwalters ptal

[WGH-]

I think this should go to sdnotify_unix.go.

Currently, as of main branch, all code is buildable on Window (even if it's just a stub). With this golang.org/x/sys/unix import, it no longer builds on Windows.

[corhere]

Done!

[kolyshkin]

LGTM except

• we need to use a versioned x/sys/unix (I think the earliest version would do).
• I'm not sure about the copyright (since there's no CoreOS, Inc in 2025).

// Copyright 2025 CoreOS, Inc.

[corhere]

• we need to use a versioned x/sys/unix (I think the earliest version would do).

I tried that at first. Unfortunately golang.org/x/sys/[email protected] is incompatible with Go 1.12. I carefully chose the oldest x/sys commit which provided the necessary syscalls and constants so that the module will continue to build on Go 1.12, as required by CI. Is there a problem with using an untagged commit as the required version? The MVS algorithm should consider tagged versions as higher precedence since their commit dates are all newer, AIUI, so it should not cause any dependency-hell grief in importing modules.

• I'm not sure about the copyright (since there's no CoreOS, Inc in 2025).

// Copyright 2025 CoreOS, Inc.

What should I put instead?

[kolyshkin]

Unfortunately golang.org/x/sys/[email protected] is incompatible with Go 1.12.

We'll just switch to modern Go instead, I don't see much value in trying to support ancient versions.

// Copyright 2025 CoreOS, Inc.
What should I put instead?

I dunno, but will ask around.