Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

OmsAgent: Enable failed with exit code 52 Couldn't create marker file

See original GitHub issue

When provisioning the OMS agent for Linux (v1.12) I’m receiving an error during the on-boarding/enabling process.

Enable failed with exit code 52 Couldn't create marker file

There isn’t any info on this error in the Microsoft error docs for this extension. However, I tracked the error down to a Python file in this repository. The section of code in question is here after line 629. This section shows that it’s creating a “marker file” to support multi-homing and to show it was onboarding via the extension. Other comments show that there is a permissions issue when trying to access the marker file:

# we are having some kind of permissions issue creating the marker file

I noticed there seems to be an issue with this file even though all of the other files in the workspace directory seem to be appropriately owned by the omsagent user and omiusers group.

ls -al

drwxr-x--- 3 omsagent omiusers 4096 May 29 02:10 .
drwxr-x--- 4 omsagent omiusers 4096 May 28 23:50 ..
-rw-r--r-- 1 root     root        0 May 28 23:50 .azure_extension_marker
-rw-r----- 1 omsagent omiusers  968 May 29 02:10 omsadmin.conf
-rw-r----- 1 omsagent omiusers 3083 May 28 23:50 omsagent.conf
drwxr-x--- 2 omsagent omiusers 4096 May 29 00:01 omsagent.d
-rw-r----- 1 omsagent omiusers    0 May 28 23:50 .service_registered

The .azure_extension_marker marker file seems to be owned by root user even though the code at line 609 is supposed to recursively set permissions for all files in the workspace directory.

An important note is that the onboarding process seems to complete just fine (VM shows up as datasource in workspace) but this extension failure fails all deployments that use this extension in ARM templates.

How can this issue be resolved so that the agent can be provisioned through extension? This issue is occurring on more than 1 VM/VMSS in Azure (not isolated issue).

@simathih, do you possible have comment on this? I noticed your pull request which added this code so I think you might have good context on this issue.