internal/dlopen: report dlerror() when no library can be opened

[amccabe]

GetHandle returns the bare ErrSoNotFound sentinel when every dlopen attempt fails, discarding what dlerror() reported. GetSymbolPointer and Close in the same file already capture it. This makes GetHandle do the same for each name tried, and wraps the sentinel so errors.Is(err, ErrSoNotFound) still holds for existing callers.

History. The omission dates from the original dlopen package in coreos/pkg (5ec8ba6, 2016-02-02) and came across unchanged when it moved here as an internal package (3344f03, 2019-11-01). Every v22 tag, v22.0.0 through v22.7.0, carries it.

Why it matters. The sentinel makes a missing library indistinguishable from a transient loader failure, and the string has been reported downstream for years without the cause ever being named:

• Journald plugin not working on 0.6.1 kubernetes/node-problem-detector#232 and Feature request: Implement concrete types for systemd config files #277 (2018, 2019): journald plugin failing with this message; closed on a version bump.
• [Auditbeat] system/package failing on Fedora 31+ elastic/beats#19253 and #30398 (2020, 2022): journald input failing in containers with this message.
• Fix dependency on chroot openshift/machine-config-operator#543 (2020): same string, fixed by changing how the binary was run.

Impact on k3d on podman. podman machine runs with the journald log driver, so podman's container-logs endpoint opens the journal through sdjournal.NewJournal, which reaches GetHandle on the first request in each API service process. I hit a case where that first request, made by k3d seconds after starting a k3s node, was answered with a 500 carrying only this sentinel. k3d treats a failed log-stream open as a dead node and rolls the whole cluster back, so one unexplained dlopen failure cost a cluster create. The retry succeeded a minute later, and the reason for the first failure is unrecoverable because dlerror() was never read. With this change the journal would have said why.

Before, with libsystemd absent:

unable to open a handle to the library

After:

unable to open a handle to the library: libsystemd-journal.so.0: cannot open shared object file: No such file or directory; libsystemd-journal.so: cannot open shared object file: No such file or directory; libsystemd.so.0: cannot open shared object file: No such file or directory; libsystemd.so: cannot open shared object file: No such file or directory

The error is wrapped with %w, so errors.Is(err, ErrSoNotFound) would still pass. A caller comparing with == would fail after this change; none can: internal/dlopen is an internal package, so nothing outside this module can reference the sentinel, and the in-tree users pass the error through unchanged. The success path is unchanged apart from a thread lock for the duration of the call, matching the other two functions in dlopen.go. The new test asserts the sentinel is preserved and that each name tried appears in the message - it fails on main and passes here.

[amccabe]

The lint failure here is the pinned golangci-lint v2.11 being unable to type-check Go 1.27, which go-version: stable now resolves to; it panics identically on main with the same toolchain. #529 bumps the linter to v2.13.2 and clears it.

[amccabe]

The bullseye failures here are apt returning 404 for every package from the bullseye security pool, which left the mirror after Debian 11 reached end of life on 2026-08-31; the job exits before any Go is built. #530 moves the matrix to bookworm and ubuntu 22.04.

[amccabe]

I was looking at prior PRs in this repo and I see this is a duplicate of #527. You should go with that one, it's the same change. The failed checks and the fixes for them in #529 and #530 are still necessary, and #531 should still be useful.