omsadmin.conf: No such file or directory

[dewitpj]

Hi,

Where can I get a copy of omsadmin.conf:

/opt/microsoft/omsagent/bin/service_control: line 160: /etc/opt/microsoft/omsagent//conf/omsadmin.conf: No such file or directory

We have tried multiple installs and this file is nowhere on the system (Ubuntu 18.04 & Ubuntu 20.04 tried)

Thanks

[RafaelRuales]

it seems not only the file mentioned above is gone (/etc/opt/microsoft/omsagent//conf/omsadmin.conf) but the structure of the whole /etc/opt/microsoft/omsagent directory has changed? ubuntu 20.04

[dewitpj]

Hi Guys,

Any updates ?

[pemontto]

We encountered this problem recently and found it was related to clock skew. Our host clock was only out a few hours, but that caused some (not all) requests to 403 which left the OMS agent half configured. Regarding the content of omsadmin.conf

WORKSPACE_ID=<WORKSPACE_ID>
AGENT_GUID=<AGENT_ID UUIDv4>
LOG_FACILITY=local0
CERTIFICATE_UPDATE_ENDPOINT=https://<WORKSPACE_ID>.oms.opinsights.azure.com/ConfigurationService.Svc/RenewCertificate
URL_TLD=opinsights.azure.com
DSC_ENDPOINT=https://<WORKSPACE_ID>.agentsvc.azure-automation.net/Accounts/<WORKSPACE_ID>/Nodes\(AgentId='<AGENT_ID UUIDv4>'\)
OMS_ENDPOINT=https://<WORKSPACE_ID>.ods.opinsights.azure.com/OperationalData.svc/PostJsonDataItems
AZURE_RESOURCE_ID=
OMSCLOUD_ID=
UUID=<UUIDv4>

[Supersaki]

Encountered the same error, and ours was due to missing the -FF flag (in Azure GCC High environment) in the cef_installer.py command.

[jnawk]

For me, I had a broken previous install where I had, like a muppet, switched the workspace id and key arguments around. sh ./omsagent-*.universal.x64.sh --purge got rid of everything for a clean install.

[WaitingForGuacamole]

If it is clock drift, what exactly are we supposed to do about it? This is happening to me installing a VM Scale Set. Am I supposed to come up with a custom script to get the time synced on a newly imaged machine before the extension installs?

Sounds brittle.

[WaitingForGuacamole]

Also, the troubleshooting doc says this is an important configuration file - it'd be great if it told you what to do if it's not there. The troubleshooter tool tells you it's not there, and that it's a problem, reinstalling it doesn't seem to do much.

I imagine I could try purging, but if that works, is that my go-to strategy for VM Scale Sets, watch for new instances and manually re-install the agent?

[jnawk]

If it is clock drift, what exactly are we supposed to do about it? This is happening to me installing a VM Scale Set. Am I supposed to come up with a custom script to get the time synced on a newly imaged machine before the extension installs?

Sounds brittle.

install a time sync daemon like ntp or chrony, not exactly uncommon or unreasonable. "a few hours" is not reasonable clock skew.

[WaitingForGuacamole]

install a time sync daemon like ntp or chrony, not exactly uncommon or unreasonable. "a few hours" is not reasonable clock skew.

Shouldn't a marketplace image deployed to Azure be configured out of the box to sync time properly?

[jnawk]

install a time sync daemon like ntp or chrony, not exactly uncommon or unreasonable. "a few hours" is not reasonable clock skew.

Shouldn't a marketplace image deployed to Azure be configured out of the box to sync time properly?

I'd have thought so, but I'm no Azure expert.

[WaitingForGuacamole]

That is what I am currently attempting. I mean, you're right, this is probably what I need to do, it's just annoying.

[WaitingForGuacamole]

And in the end, it was a hosed log analytics workspace. Out of 8 workspaces I have set up, this was the only one whose workspaceid.oms.opinsights.azure.com would not resolve in DNS. Could've opened a ticket, instead whacked and recreated it, and it deployed like a charm.

[dylan8902]

I was getting this error:

/opt/microsoft/omsagent/bin/service_control: line 160: /etc/opt/microsoft/omsagent/${WORKSPACE_ID}/conf/omsadmin.conf: No such file or directory
ERROR:  start_omsagent failed with result '1' on workspace ${WORKSPACE_ID}.

To get around this issue, I ran:

touch /etc/opt/microsoft/omsagent/${WORKSPACE_ID}/conf/omsadmin.conf
chmod 755 /etc/opt/microsoft/omsagent/${WORKSPACE_ID}/conf/omsadmin.conf
/opt/microsoft/omsagent/bin/omsadmin.sh

/opt/microsoft/omsagent/bin/service_control restart ${WORKSPACE_ID}

And the agent started happily

[anthonyAA11]

I was getting this error:

/opt/microsoft/omsagent/bin/service_control: line 160: /etc/opt/microsoft/omsagent/${WORKSPACE_ID}/conf/omsadmin.conf: No such file or directory
ERROR:  start_omsagent failed with result '1' on workspace ${WORKSPACE_ID}.

To get around this issue, I ran:

touch /etc/opt/microsoft/omsagent/${WORKSPACE_ID}/conf/omsadmin.conf
chmod 755 /etc/opt/microsoft/omsagent/${WORKSPACE_ID}/conf/omsadmin.conf
/opt/microsoft/omsagent/bin/omsadmin.sh

/opt/microsoft/omsagent/bin/service_control restart ${WORKSPACE_ID}

And the agent started happily

Just worked for me, many thanks :)

[hestolz]

Thank you for your submission. As previously announced, the Log Analytics agent has been deprecated and has no support as of August 31, 2024. If you use the Log Analytics agent to ingest data to Azure Monitor, migrate now to the new Azure Monitor agent. As part of repo archival, open issues and pull requests will be closed.