As you can see it’s for some reason reconfiguring itself with an http binding that uses port 443, which conflicts with our https binding, then it tries to restart and can’t bind https so it fails to start. When I remove the binding it works for 10-15 minutes and then does this again.
Hi Sam,
Thanks for getting in touch! I’m sorry to hear you are seeing this issue where your Octopus Servers bindings are changing like this.
I’m actually not aware of anything within Octopus that would run this command for you at this stage. From your description it currently sounds like something outside of Octopus Server is running these commands against your Octopus Server.
One option which comes to mind here could be to have a look around the server to see if there are any scheduled tasks running these commands perhaps.
Meanwhile I’ll keep digging on my end to see if there could be anything within Octopus that would run this command.
I took a look through the scheduled tasks and didn’t see anything of the sort. It’s worth noting this command only gets run a short period of time after I manually change the bindings back to the original bindings, it’s never run prior to the bindings changing. That doesn’t necessarily rule out a scheduled task, but I also know nobody changed anything on the box overnight. I don’t think this command is being run with the express purpose of changing the bindings, I think it’s just being called with incorrect parameters while it’s intent is to do something else. I’m not sure why it’s being called with the wrong bindings, or what’s calling it. I’ve looked through the database and everywhere else I could think of for a reference to the bad list of bindings and don’t see anything.
Hi Sam,
I’m just touching base with you with some new information on this one. OctopusDSC is one tool which behaves similar to this where if it finds the Octopus Server config is out of state it will try to put it back into a desired state.