This patch makes SdNotify return value compliant to the sd_notify() documentation. See sd_notify(3) man page.

Fixes: https://github.com/coreos/go-systemd/issues/184

Something in godbus seems to have broken API, thus breaking builds including go get. This patches fixes those changes. I don't know any background about this change, so if anyone has information, I'd sure like to know! Thanks

This allows not having to link users of the library to libsystemd, detect at runtime if it exists or not and react accordingly.

Also, refactor dlopen code.

Implements the same semantics as the JOURNAL_FOREACH_DATA_RETVAL macro in journal-internal.h and produces a *JournalEntry with every field with its corresponding data in a map[string]string. Also it includes address fields like realtime (__REALTIME_TIMESTAMP), monotonic (__MONOTONIC_TIMESTAMP and cursor (__CURSOR).

It mimics more or less journalctl -o json.

Fixes #142 Supersedes #136

…d support)

is a part of this change: https://github.com/endocode/systemd/commit/5b4452a643d924015ed25972d071ad8802aad29c and this pull request: https://github.com/coreos/fleet/pull/1564

This PR adds a go.mod and go.sum to the project which contains the latest dependencies. It would be awesome if we could tag a release according to semver after this PR got merged, WDYT? :innocent:

This is an adaptation of #215 to ensure tests don't fail and extend the behaviour to PacketConns(). A bit of test coverage is lost, but just testing if variable environments are not unset in the simple case doesn't seem worth adding more code.

Fix #215

When a non temporary error is detected while sending a message, the connection should be closed to attempt a reconnection, otherwise it won't be possible to send new messages to journald anymore.

fix inconsistency in return types for journal functions: NextSkip, Previous, PreviousSkip. Currently they will return (uint64, error), however according to sd-journal.h it should be (int, error)

Journal.Next returns (int, error) Journal.Previous returns (uint64, error)

https://github.com/systemd/systemd/blob/master/src/systemd/sd-journal.h#L98

Should there also be a usage example on how to create a transient scope unit instead of a transient service unit?

Feel free to use https://github.com/mgit-at/systemd-runas/blob/master/main.go as a example on how to use the call with transient scopes.

This gets rid of the connection ownership problem by using a non-connected Unix datagram socket and an explicit destination to send each message. It does not impact the public API, but it requires a minimum-go version bump due to https://go-review.googlesource.com/c/go/+/45872 (golang 1.10+).

Fixes https://github.com/coreos/go-systemd/issues/5 Fixes https://github.com/coreos/go-systemd/issues/233 Fixes https://github.com/coreos/go-systemd/issues/275

Note: as 1.11 got released, all upstream supported versions of the Go runtime have a fixed version of WriteMsgUnix that this PR uses. However, this means that the journal package won't work on older/buggy runtimes (<= 1.9).

I am using sdjournal indirectly with the filebeat journald input, and was wondering if reading from a non-default journald namespace is supported directly. I know that I can point filebeat to the namespace's systemd.journal file residing in /var/lib/journal/machine-id.namespace, but this requires knowledge of the machine-id for each individual server. I solved the problem for our system by symlinking the machine-id.namespace directory to a machine-independent path, but this still feels hacked together.

Looking at the code it doesn't seem like, so I just wanted to confirm.

Thanks a lot and all the best!

In https://github.com/coreos/go-systemd/blob/f5f8d59a116b1ca501dd87cdb28f6ce89ccf58dc/activation/files_unix.go#L66 the return value of os.NewFile should be checked before files is changed. It can fail if the environment variables don't match the file descriptor table, e.g. LISTEN_FDS is much larger than the number of open files. The current logic would force consumers of the interface to check for this condition or run into mysterious panics in a completely unrelated code. If os.NewFile fails, just returning nil might be reasonable, even if it means close-on-exec is set on some file descriptors.

I would like a module that can read credentials when the current program is running as a systemd service.

This should be fairly simple and a small amount of code. I'm willing to send a PR at some point.

Hi Community, I a recent event, I just discovered that the two functions to establish dbus connection doesn't handle context deadline event

func TestGoSystemd(t *testing.T) {
	ctx, _ := context.WithTimeout(context.Background(), 0)
	_, err := dbus.NewSystemConnectionContext(ctx)
	if err != nil {
		t.Fatal(err)
	}
}

this throws:

=== RUN   TestGoSystemd
    dbus_test.go:13: read unix @->/run/dbus/system_bus_socket: use of closed network connection
--- FAIL: TestGoSystemd (0.00s)

Same for

ctx, _ := context.WithTimeout(context.Background(), 0)
_, err := dbus.NewUserConnectionContext(ctx)
// : read unix @->/run/user/1000/bus: use of closed network connection

And when integrated with large software, it makes debugging a lot harder. I think here it's best to use standard context.DeadlineExceeded error when such a scenario occurs. Thank you!