

It’s in the dnsutils package.
It’s in the dnsutils package.
Well crap. Do you have no ipv6 address now in ip addr
?
Guess I gave Docker too much benefit of the doubt and assumed it should failover to v4 once v6 was disabled. Bad assumption on my part.
Could it be a DNS problem? If you dig registry-1.docker.io +short
does it return an ipv4 or v6 address?
It looks like there have been sporadic reports of problems from people since last year.
Ok, so it’s probably using NetworkManager. I would try disabling it in /etc/NetworkManager/NetworkManager.conf by adding a block like:
[ipv6]
addr-gen-mode=stable-privacy
method=disabled
Then sudo systemctl restart NetworkManager
.
Can’t say for sure if this will work. I dislike using NetworkManager on my servers so I can’t test if this works. But hopefully the before/after of ip addr
is different.
Although it looks like your ip addr
output posted an hour or so ago doesn’t show any ipv6 addressing. Maybe the problem is solved now.
Different programs have different defaults.
But in your situation which would be more helpful - prevent this one docker command from using ipv6 (likely more difficult), or preventing all commands from using your broken ipv6 config (likely easier)?
I have no idea about the first. Maybe some people know this detail. But I’m sure that with a distro and version that you’re running, there are lots of people who could help with the second. Raspberry Pi 3B+ is the hardware. What software are you using?
Docker is a distraction in your problem description.
It’s like if you asked why the top gear in your car isn’t working and gave the model of car and engine type and gearbox. But it’s really that you’re stuck in slow traffic. Focus on the road name and destination to find a faster route.
For your problem, search for how to disable ipv6 for the Linux distribution and version that you have installed. You will find lots of guidance. Or share those details here for someone to help.
Or, better might be to see if there is a way to get ipv6 tunneling working on your connection. It may be possible even if the ISP is unhelpful.
Some routers advertise a routable link local.
Being on-call at any hour is something to consider. With a large enough organization it can reduce the frequency, but it never goes away.
Also, maintenance is scheduled for critical systems at low demand times. It’s another reason to be prepared to work nights.
Correct. And as AtariDump points out, it’s best to check typical runtime wattage, not peak, and not just on specs.
After you know the wattage of your load, use the Runtime tab on the product page to see how much runtime you get at a given wattage.
https://www.cyberpowersystems.com/product/ups/smart-app-lcd/or1500lcdrm1u/
The one you have selected will have 2 minutes of runtime ~900w on a fresh battery. If all you want to do is clean shutdown, that’s probably fine (as long as you don’t have brief power drops that you want your shutdown procedure to ignore). If you need more time then you’ll need a different UPS.
Note that some UPS models will do better for a given task than others with similar specs. For example I have a ~100w homelab, and wanted maximum runtime for 50w during a power outage (servers off, router+switch+aps active). Some similar spec Cyberpower models were ~120 minute runtime at 50w while others were 200+ for the same load.
This appears to be a 14500 lithium ion cell (same physical size as AA), putting out 3.7v for a device like this flashlight that supports it. No voltage step down, just charging circuitry on-board.
This flag seems to only disable ipv6 on the default Docker bridge network, not daemon-wide. At least per this discussion.