Almost always a DNS caching issue in the proxy combined with startup ordering. The proxy resolves the container name to an IP once at startup, the container gets a different IP on the reboot because it came up in a different order, and the proxy keeps talking to an address that no longer exists. Restarting the container makes it re-register and often gets the old IP back, which is why the manual fix looks like it fixes the container. The real fix is to make the proxy re-resolve: use a variable for the upstream so it resolves per request, or pin the container to a static IP or a user-defined network with a stable alias.
Leo Vantwo
@chmod_confused
Junior sysadmin, four months in. I know just enough Linux to break something and just enough humility to ask before I do.
Exactly the mechanism. Add a depends_on with a health condition so the proxy starts last, and use the resolver approach so ordering stops mattering at all. Belt and braces because reboots are the one time you are not watching.
That comparison had not occurred to me. Half the club is running splits off established hives.
Very low, which fits the datacentre story: they spun up once and stayed up. A consumer drive with aggressive head parking can hit 300000 in three years. You bought fine drives.
Normal for the category and not a reason to panic on its own. Drives that ran continuously in a climate-controlled rack are in many ways gentler-used than a desktop drive with 8000 hours and 15000 spin-ups, because thermal cycling and start-stop cycles do more damage than steady spinning. Clean SMART at 41000 hours is a genuinely good sign. What you should do is run a full non-destructive read test on all four before trusting them, and stagger their retirement so you are not replacing four drives in the same month. Also check the load cycle count, which is the number people forget and the one that actually kills some models.
Drawing comb is expensive for them, roughly six to eight kilos of honey per kilo of wax by the numbers people quote. If the flow is only strong enough to fill what they have, they will not spend that. Weigh whether they are actually storing surplus or just keeping pace with the brood.
Watching per-disk latency during a transfer is even quicker. One disk sitting at ten times the latency of the others points straight at the culprit.
Time the phases so you know what is slow: scanning for changes, uploading, or the index work at the end. If scanning dominates, the metadata cache on the client is probably being lost between runs, which happens a lot inside containers with no persistent volume for the cache directory.
Quilt box, then a windbreak with whatever you have lying around, and the wrap can wait for next year. Bees deal with cold far better than they deal with condensation dripping back onto the cluster, and freeze-thaw weather is exactly what produces that. A quilt box of shavings above the crown board takes the moisture out through the top while keeping the warmth in. A wrap on a hive with no moisture management can make the wet worse by making the walls the coldest surface available.
A small upper entrance is worth it in deep snow country regardless, mostly so they can get out if the bottom board is buried and so dead bees do not block the exit. The heat you lose through a 10mm notch is trivial next to that.
Four smaller drives secondhand also means four sets of unknown hours. Two drives means half the chances of drawing a bad one, which at this scale is not nothing.
Something people forget: if your neighbours have untreated hives within a couple of kilometres, your counts can climb again in September from robbing and drift. Not a reason to skip treating, just a reason to check again in October rather than assume you are done.
I lost a queen exactly this way in my first year, inspecting on day 12 because I was anxious. Nothing looks wrong until you have no brood a month later.