The two messages I read with the above subject seem to overlook some important concepts:
a) Like many many servers, openser is a high-level application. It depends on a complicated under-world of services and protocols. The operation of it depends on many external elements, all of which should be in good working order.
b) DNS resource records (RR) have time-to-live (TTL) attributes. Any application may cache RR up to the length of time specified by the TTL. When you restart something, you typically blow away the cache and start over. In general, most applications do not cache general name lookups, since that is a lower-level function. However, an application caching the hostname it's on and/or IP addresses to bind to is standard practice.
I have come to realise that it seems as though once loaded into memory and running, openser "caches" the config file and also does not appear to re-check for changes in network conditions
Yes, isn't that great! It shouldn't check until either told to by a human or when the underlying protocol indicates that it is time for a refresh (like a DNS TTL expiring).
Regarding this:
I had to lock-down the network card to 10mbit full-duplex. It was autoselecting 100mbit half-duplex. Hope that helps someone... sometime...
Autoselecting 100/half probably means that the link auto-negotiation failed, as that is the default. It might fail because the other side was nailed down, perhaps to 10/full. That seems like an unlikely choice... but one reason why it might be nailed at 10mbits is because someone before you couldn't get it to run well at 100mbits and discovered that setting it to 10 was a "solution." If that was the case, I'ld guess that the cable between the switch and the server is lengthy and that it was not tied down in the prescribed order (wO, O, wG, Bl, wBl, G, wBr, Br) [or swap O and G].
I apologize if this email comes across as a little snooty. This is my first email of the day and I often have trouble phrasing things in a nice way prior to my coffee kicking in.
-mark