Systemd. Binary logs are wonderful aren't they?
It's not that hard to read them without linking their library. The format is explained on their documentation.
Go is portable, until it isn't
81–90 of 138 posts
Re: Go is portable, until it isn't
#82i wonder, for their use case, why not just submit journal in binary format to the server and let the serve do the parsing?
It's crucial to be able to do some processing locally to filter out sensitive/noisey logging sources.
Re: Go is portable, until it isn't
#83This stuff is out of my frame of reference. I've never used Go before and have never had the need to go this low level (C APIs, etc); so please keep this in mind with my following questions, which are likely to sound stupid or ignorant.
Can this binary not include compiled dependacies along side it? I'm thinking like how on windows for portable apps they include the DLLs and other dependant exes in subfolders?
Out of interest, and in relation to a less well liked Google technology, could dart produce what they are after? My understanding is dart can produce static binaries, though I'm not sure if these are truly portable compile once run everywhere sense.
Re: Go is portable, until it isn't
#84Was there not a third option: Calling the journalctl CLI as a child process and consume the parsed logs from the standard output? This might have avoided both the requirement to use CGO and also to write a custom parser. But I guess I am missing something.
Re: Go is portable, until it isn't
#85FWIW I maintain an official implementation of the journal wire format in go now.
https://github.com/systemd/slog-journal so you can at least log to the journal now without CGO
But that's just the journal Wire format which is a lot simpler than the disk format.
I think a journal disk format parser in go would be a neat addition
Re: Go is portable, until it isn't
#86Was there not a third option: Calling the journalctl CLI as a child process and consume the parsed logs from the standard output? This might have avoided both the requirement to use CGO and also to write a custom parser. But I guess I am missing something.
This was the first thought that occurred to me too when I saw this post.
Re: Go is portable, until it isn't
#87Was there not a third option: Calling the journalctl CLI as a child process and consume the parsed logs from the standard output? This might have avoided both the requirement to use CGO and also to write a custom parser. But I guess I am missing something.
Also there is a --json (or -o json) flag for journalctl which will output line based json log entries. And it can simply be called with a Command as you pointed out.
Re: Go is portable, until it isn't
#88Was there not a third option: Calling the journalctl CLI as a child process and consume the parsed logs from the standard output? This might have avoided both the requirement to use CGO and also to write a custom parser. But I guess I am missing something.
Yeah looks like they missed the forest for the trees.
I see this kind of thing in our industry quite often; some Rube Goldberg machine being invented and kept on life support for years because of some reason like this, where someone clearly didn’t do the obvious thing and everyone now just assumes it’s the only solution and they’re married to it.
But I’m too grumpy, work me is leaking into weekend me. I had debates around crap like this all week and I now see it everywhere.
Re: Go is portable, until it isn't
#89I ran into this issue when porting term.everything[0] from typescript to go. I had some c library dependencies that I did need to link, so I had to use cgo. My solution was to do the build process on alpine linux[1] and use static linking[2]. This way it statically links musl libc, which is much friendlier with static linking than glibc. Now, I have a static binary that runs in alpine, Debian, and even bare container…
> and even bare containers. Strange, i thought the whole point of containers was to solve this problem.
Depends how much you care about the size and security footprint of your container images.
Re: Go is portable, until it isn't
#90I ran into this issue when porting term.everything[0] from typescript to go. I had some c library dependencies that I did need to link, so I had to use cgo. My solution was to do the build process on alpine linux[1] and use static linking[2]. This way it statically links musl libc, which is much friendlier with static linking than glibc. Now, I have a static binary that runs in alpine, Debian, and even bare container…
That is a nice approach. I'll have to give that a try with rclone. I tried lots of things in the past but not using Alpine which is a great idea Another alternative is https://github.com/ebitengine/purego You can use this to dynamic load shared objects / DLLs so in the OP example they could disable systemd support if the systemd shared object did not load. This technique is used in the cgofuse library ( https://githu…
I am using purego indirectly in two pet projects of mine. While it has its own issues it definitely solves the issue of cross-compilation.
In this particular case it may be that they will need to write a wrapper to abstract differences between the systemd C API if it is not stable, but at least they still can compile a binary from macOS to Linux without issues.
The other issue as other said is to use journalctl and just parse the JSON format. Very likely that this would be way more stable, but not sure if it is performant enough.