Thank you for your reply SuccessfulKoala55 . 😄
It is currently set to 1, so I am assuming setting it to 0 would mute the errors from logging?
The current behaviour is, if I keep it set to 1 the services agent would automatically shutdown if the access key is not configured. Assuming I set it to 0, then the agent services should not shutdown anymore, right?
Hi ExuberantBat52 , this is an internal endpoint configuration env var (which is why it was probably not documented well). It's purpose is to make sure that if the services agent is not configured (which it might be, if you just installed the server and did not bother to set up the services agent yet), it will not continue inflating the logs with connection errors.
This is a special behaviour since in general agents are installed and set up, and if they fail to connect to the server, that's usually an error you'd want to know about. The services agent, being an optional part of the server's installation, might be left unconfigured intentionally 🙂
so basically the flag also prevents it from shutting down
Which would make sense because of the name SHUTDOWN_IF_NO_ACCESS_KEY . The thing is, when I tried setting it to 0, it still shutdown.
As you can see, it eventually manages to reach the apiserver however, it still says that access key was not provided and that the service will not be started. I get the same behaviour whether I set the flag to 0 or 1.
Let me rerun it, so that I can capture it. I am currently running it on AWS Fargate, so I have the logs for that.
That's strange - do you have the docker log for it when it does that?
It would not shut down, but will keep attempting to connect and issuing errors to the logs when it fails
This printout: CLEARML_API_ACCESS_KEY was not provided, service will not be started basically means the docker container entrypoint just exited with return code 0. Everything else is (I assume) related to Fargate?
As for peroviding 1 or 0, I think I see the problem - the entrypoint's code uses -n which checks for string length, so disabling this feature should be with simply not defining the env var, not by providing 0 🙂