SYMPTOM
The principal symptom is that you'll see that your runtime gets disconnected from Anypoint Platform or is not able to connect to it.
Going one step further, you notice that <MULE_HOME>/conf/mule-agent.yml file is either empty or contains unknown characters.
As this file is needed to establish a connection between your onprem runtime and Runtime Manager, if it's malformed, you won't be able to connect.
CAUSE
By default, The FileWriter constructor used by the agent clears the descriptor file.
After the FileWriter is built, the agent performs several steps that may produce an exception.
If an error occurs, an exception is thrown and leaves empty the original descriptor file.
In addition, corruption may happen, for example, due to a third party software scanning the file system.
An example of the corrupted file entries:
enabled: *id014
mule.agent.application.service:
applicationConfigurations: []
enabled: *id014
mule.agent.logging.service:
applicationLogLevels: []
enabled: *id014
mule.agent.scheduling.service: &id015
schedulerConfigurations: []
enabled: *id015
In the above snippet, values
*id014 and
*id015 are observed instead of
true or
false.
SOLUTION
The way the mule-agent.yml file gets updated has been improved on later versions of the agent, so you shouldn't encounter this issue again after upgrading the Mule Agent.
This has been fixed in 1.14.6 (Mule 3.x) and
2.4.10 or later (Mule 4.x - also for PCE and GovCloud).
To restore the service immediately, replace the
mule-agent.yml from the backup. Just stop the runtime, replace the file and start the runtime back again.
If there is no backup available (or too old), for security reasons, there is no way to reconstruct this file. So if you are affected by this issue, in order to fix this you'll need to:
- Remove your runtime from Runtime Manager
- Update the agent to latest version available.
- Add the server back again. (You will need to deploy all apps again).
