The system will run for a period of time successfully. Then at some point throw this exception and often in that circumstance, terminate jobs. It’s a fairly stock instance built with the horde server, MongoDB and REDIS. The instance is described in the confluence exported doc I’ve attached (Horde+Infrastructure.pdf). I’m happy to provide you with whatever else I can give you, I’m just not sure what that is in a case like this. Please don’t hesitate to ask.
Steps to Reproduce
Unfortunately I don’t have a repro to provide. The issue happens at different times, the only consistency is in the exception that is generated. I’ve included that information in the attached file “exceptionText.txt” - I tried including the text in the question but it is too many characters. I’m not sure what other information to provide.
Hello, the “Name or service not known” message points to a DNS issue, suggesting the `horde-server` container could not resolve `hordedb.int.thatsnomoon.com`.
The 30s timeout looks to be the MongoDB driver’s default server selection timeout, and this is causing issues with authentication and agent sessions to expire.
System.Net.Sockets.SocketException (00000005, 0xFFFDFFFF): Name or service not known
at System.Net.Dns.GetHostEntryOrAddressesCore(String hostName, Boolean justAddresses, AddressFamily addressFamily, Nullable`1 startingTimestamp)
at System.Net.Dns.GetHostAddresses(String hostNameOrAddress, AddressFamily family)
at MongoDB.Driver.Core.Connections.TcpStreamFactory.ResolveEndPoints(EndPoint initial)
If this is the issue, I wouldn’t expect much useful information in the Horde and the MongoDB logs, but it might be worth checking these around the time of the failures.
If you’re using static IP addresses, the simplest workaround that I can think of would be to point `MongoConnectionString` at the host’s IP (e.g., `mongodb://10.100.0.109:27017/…`).
This would also go some way to prove where the issue lies for future troubleshooting.
To further troubleshoot the root cause, could you please share the `MongoConnectionString` value from `server.json` and confirm your Docker network setup?
If you’re using Docker’s embedded DNS resolver, you could try enabling debug logging to see if there are any DNS failures in those logs.
We have not seen the issue since this change. I’m not sure if that means it’s fixed, or we just haven’t seen it. I also don’t know what interval makes sense to keep the ticket open. It’s harder to prove an absence of event than the event.