Closed imavroukakis closed 2 months ago
mattdurham
commented
2 months ago Its unlikely we will support arm7, we have had a lot of issues with 32bit ARM. At this point we officially only support 64bit ARM. Likely related to this https://github.com/golang/go/issues/67077
mattdurham
commented
2 months ago Flow mode would likely fail with the same issue, static mode doesnt support clustering so does not hit this edge case.
imavroukakis
commented
2 months ago Hey @mattdurham thanks for the response. I understand that 32bit ARM might be a PITA to support. Having said that ARM SoCs are out there in abundance, especially in terms of embedded devices where one might want to use in the day job for Grafana Cloud ;)
In the instance that we are trialling we would not need to cluster anything quite frankly, can we skip it and hopefully never care again? If not, where would you suggest that I look to attempt to align whatever it is that it's panicking about?
mattdurham
commented
2 months ago We have had a lot of build issues over the years and runtime errors with 32bit from our various libraries we import.
Long term running node_exporter ( or other exporter) directly and scraping it from a non-32 bit system is likely the best solution.
imavroukakis
commented
2 months ago We have had a lot of build issues over the years and runtime errors with 32bit from our various libraries we import.
Long term running node_exporter ( or other exporter) directly and scraping it from a non-32 bit system is likely the best solution.
Due to a variety of network restrictions, scraping would not be possible :( but that's an idea to keep in mind anyway.
imavroukakis
commented
2 months ago I noticed a comment that was removed about running fieldalignment , happy to give any and all suggestions a go (no pun intended!)
hairyhenderson
commented
2 months ago I noticed a comment that was removed about running
fieldalignment
Yeah, that was me - I looked at the Go bug listed above and was no longer certain this was the cause. I'm actually hunting a similar bug in another project and had been working on field alignment to fix it, but while there are a number of hits from the fieldalignment linter on ckit, I'm not at all convinced that simply fixing those would help.
imavroukakis
commented
2 months ago @hairyhenderson I took inspiration from your post and went ahead and changed the lamport clock implementation to use Uint64 in ckit and rebuilt
package lamport
import "sync/atomic"
var globalClock Clock
// Now returns the current Time. The time will not be changed.
func Now() Time { return globalClock.Now() }
// Tick increases the current Time by 1 and returns it.
func Tick() Time { return globalClock.Tick() }
// Observe ensures that the time past t by at least. Must be called when
// receiving a message from a remote machine to roughly synchronize
// clocks between processes.
func Observe(t Time) { globalClock.Observe(t) }
// Clock implements a lamport clock. The current time can be retrieved by
// calling Now. The Clock must be manually incremented either by calling Tick
// or Observe.
type Clock struct {
time atomic.Uint64
}
// Time is the value of a Clock.
type Time uint64
// Now returns the current Time of c. The time is not changed.
func (c *Clock) Now() Time {
return Time(c.time.Load())
}
// Tick increases c's Time by 1 and returns the new value.
func (c *Clock) Tick() Time {
return Time(c.time.Add(1))
}
// Observe ensures that c's time is past t. Observe must be called when
// receiving a message from a remote machine that contains a Time, and is used
// to roughly synchronize clocks between machines.
func (c *Clock) Observe(t Time) {
Retry:
// If t is behind us, we don't need to do anything.
now := c.time.Load()
if uint64(t) < now {
return
}
// Move our clock past t.
if !c.time.CompareAndSwap(now, uint64(t+1)) {
// Retry if the CAS failed, which can happen when many observations are
// happening concurrently. Either this will eventually succeed or another
// call to Observe will move the current time past t and we'll be able
// to do the early stop.
goto Retry
}
}to my delight, it no longer panics
ts=2024-06-22T07:13:48.259514729Z level=info msg="starting cluster node" peers="" advertise_addr=127.0.0.1:12345
ts=2024-06-22T07:13:48.262359388Z level=info msg="peers changed" new_peers=inspect-val1xx-emmc
ts=2024-06-22T07:13:48.263384839Z level=info msg="now listening for http traffic" service=http addr=127.0.0.1:12345whether it works in a clustered scenario, different kettle of fish.
hairyhenderson
commented
2 months ago @imavroukakis great news! Are you going to issue a PR to ckit for that?
imavroukakis
commented
2 months ago @hairyhenderson sure, if it will help!
imavroukakis
commented
2 months ago Now that the fix is merged, is another PR needed to pull in the change or would a bot take care of it?
mattdurham
commented
2 months ago Another PR to update.
What's wrong?
Alloy fails with a
panicshortly after starting upSteps to reproduce
Build from source and run the agent on an armv7hf causes it to panic - in contrast the static agent, also compiled from source, works fine.
System information
Linux 5.x armv7hf
Software version
v1.1.1
Configuration
Logs