Interesting that it uses the C API to collect journals. I would’ve thought to just invoke journalctl CLI. On platforms like macOS where the CLI doesn’t exist it’s an error when you exec, not a build time error.

▲

ajross 4 days ago | parent | next [-]

That's really not such a weird choice. The systemd library is pervasive and compatible.

The weird bit is the analysis[1], which complains that a Go binary doesn't run on Alpine Linux, a system which is explicitly and intentionally (also IMHO ridiculously, but that's editorializing) binary-incompatible with the stable Linux C ABI as it's existed for almost three decades now. It's really no more "Linux" than is Android, for the same reason, and you don't complain that your Go binaries don't run there.

[1] I'll just skip without explaination how weird it was to see the author complain that the build breaks because they can't get systemd log output on... a mac.

▲

khazit 4 days ago | parent [-]

The macOS bit wasn’t about trying to get systemd logs on mac. The issue was that the build itself fails because libsystemd-dev isn’t available. We (naively) expected journal support to be something that we can detect and handle at runtime.

	▲	ajross 3 days ago \| parent [-]
		Well... yeah. It's a Linux API for a Linux feature only available on Linux systems. If you use a platform-specific API on a multiplatform project, the portability work falls on you. Do you expect to be able to run your Swift UI on Windows? Same thing!

▲

LtWorf 3 days ago | parent | prev | next [-]

I did this a while ago but it only reads journal files sequentially and I didn't implement the needed stuff to use the indexes.

https://github.com/appgate/journaldreader

▲

amiga386 4 days ago | parent | prev [-]

That's also what gopsutils does, IIRC: it tries to look up process information with kernel APIs but can fall back to invoking /usr/bin/ps (which is setuid root on most systems) at the cost of being much less performant.