Elastic Synthetics Journey: Receiving `permission denied`

This evaluates to elastic-agent.

We have mechanisms in place to prevent running browser monitors as a root user which are probably interfering here. FYI, we have introduced a new approach on 8.7.1.

I just updated to 8.7.1 today. However, in checking my tests, there don't seem to be any changes. I'm still receiving the same results.

We have had issues with around mitigations in place to prevent running browser monitors under root. A new approach was implemented on 8.7.0 (not 8.7.1, as I thought) which impacts push monitors and other deprecated types. Since we generally recommend not running containers as root, this issue will impact ECK users mostly.

A quick question. You write "...push monitors and other deprecated types." Have push monitors been deprecated?

@DougR Rest of the things @emilioalvap can better answer but we are no way deprecating Push monitors :slight_smile:

1 Like

Hi @DougR,

As @shahzad31 very kindly mentioned, push monitors and their related features are not deprecated.

What I meant to say is: other monitor types (mainly zip url and local), which are already deprecated, are also impacted. I should have used better wording on my previous comment, sorry about the confusion.

On the other topics:

  • Yes, I initially thought 8.7.1 was the version that came with permissions rework, but it ended up going into 8.7.0.
  • elastic-agent is the user that heartbeat will switch to when running synthetic journeys, since chromium can be picky about running as root. ATM, permissions are not granted to this user in order to read journey files from disk.

NP. This is what I assumed, I just wanted clarification, since we've just started to go down this road for our synthetic monitoring.

elastic-agent is the user that heartbeat will switch to when running synthetic journeys, since chromium can be picky about running as root. ATM, permissions are not granted to this user in order to read journey files from disk.

Are there any workarounds for this? I've attempted to set umask for the /tmp directory, as well as attempted to do a setacl + sticky bit on /tmp when the pod starts, but no joy so far.

Thx.

Hi @DougR,

Unfortunately, there's no workaround that we can suggest using. Our recommendation would be to upgrade to v8.8 when possible and, in the meantime, running these on our synthetics infrastructure, if that's an option for you.

Thx. Considering that we're on 8.7.1, is there an ETA for 8.8.x?

Unfortunately we can't share expected release dates, it's always possible to find a bug that might cause us to delay a release for instance. It has been a while since our last minor, and it's our goal to get this release out to customers as soon as it's ready. Apologies for the issues you've seen, and we hope 8.8 works much better for you.

I've upgraded to 8.8.0, and everything appears to be working as expected.

This topic was automatically closed 24 days after the last reply. New replies are no longer allowed.