Fix building on windows

[ncruces]

activation doesn't build on Windows because syscall.CloseOnExec takes a syscall.Handle rather than an int there.

go-systemd/activation/files.go

Lines 55 to 59 in 87511f3

	files := make([]*os.File, 0, nfds)
	for fd := listenFdsStart; fd < listenFdsStart+nfds; fd++ {
	syscall.CloseOnExec(fd)
	name := "LISTEN_FD_" + strconv.Itoa(fd)
	offset := fd - listenFdsStart

This fixes this with a build constraint returning nil on Windows, which makes it a NOP and I guess follows the philosophy of most of the project.

[lucab]

Thanks for the PR. However I'm quite confused. The activation module bridges to the service activation part of systemd, which as far as I know is not available on anything other than Linux. How and where are you trying to use this on Windows?

[ncruces]

All of this only works on Linux, but much of it builds on Windows.

Also, even on Linux, if a service is not started by systemd, there's usually a well defined behaviour.

For the activation module, no files/listeners are returned.

For another example, the daemon module builds fine on Windows, and the behaviour of SdNotify is well defined: it shall return false, nil (meaning "notification not supported", because the env var is unset).

This leads to a useful pattern that gets used on Linux, but is useful on Windows/macOS/etc also: call into go-systemd, if it somehow reports it's not running under systemd, do something else. This is used in a bunch of examples, and works fine in general.

I'm not saying henceforth you should support building on Windows, especially when the cost is high, but here the cost seems low?

It's up to you really. Feel free to drop this if you don't think you want to support this.

[lucab]

@ncruces happy to land something like this if it is useful to you :)
Although non-Linux targets are not covered by CI at this point, so it's hard to guarantee it won't accidentally regress.
I'll have a better look at this next week.
Medium term, perhaps we can use github runners to build this repo.

[ncruces]

One possible goal might be just to ensure that it builds for Windows/macOS, which given Go's cross compilation support might not be hard to add to CI even if that runs on Linux.

Any Linux tests that ensure that in the absence of systemd env variables reasonable defaults are returned, are also validating behaviour on platforms that lack systemd.

But for CI to make sense, I'd have to look at why some other modules don't build.

And really, although this is useful to me, I also understand the view that, and don't want to burden you with, maintaining something that might break in the future, and is basically just a nop.

[ncruces]

I went back and looked.

This works as is, macOS:

% CGO_ENABLED=0 GOOS=darwin go build ./...
go build github.com/coreos/go-systemd/v22/internal/dlopen: build constraints exclude all Go files in [REDACTED]/go-systemd/internal/dlopen

This fails, Windows:

% CGO_ENABLED=0 GOOS=windows go build ./...
go build github.com/coreos/go-systemd/v22/internal/dlopen: build constraints exclude all Go files in [REDACTED]/go-systemd/internal/dlopen
# github.com/coreos/go-systemd/v22/journal
journal/journal.go:130:12: undefined: syscall.UnixRight

So there'd be syscall.UnixRight to fix on the journal module.
There are 3 funcs to stub there, but it should be straight forward if there's interest.

[ncruces]

Oh my! Sorry for messing this up!
I was trying to add some commits and fix commit messages (to match your contribution guidelines).

journal should also build on Windows (and macOS) as tested by running:

CGO_ENABLED=0 GOOS=darwin go build ./...
CGO_ENABLED=0 GOOS=windows go build ./...

[lucab]

@ncruces can you please rebase on current master and squash your changes into a single commit?

[ncruces]

Hi @lucab!
Is this what you meant?
Doing it in one commit unfortunately loses track of the rename.