Comment by ChrisMarshallNY
Comment by ChrisMarshallNY 2 days ago
Depends.
I have a couple of apps on my computer that do exactly that.
I am looking forward to learning how it does work...
Comment by ChrisMarshallNY 2 days ago
Depends.
I have a couple of apps on my computer that do exactly that.
I am looking forward to learning how it does work...
> It's basic sockets.
Yup. I've done a bit of that stuff, in my time.
> If any apps are misbehaving, they're simply badly coded.
Plenty of that stuff, going around.
Might want to ease back on the "instant insult" thing. Not a good look.
> Yup. I've done a bit of that stuff, in my time.
So are you willing to admit now that "the standard TCP timeout" was a misdiagnosis of your problem?
You appeared to be projecting a personal problem with some unnamed badly coded apps onto everyone, as if it were inevitable, but the original commenter who said they turned off WiFi obviously does not experience this problem, and neither do I for that matter.
I don't think you can get ENETUNREACH from recv though. If the request was sent, it'll time out.
It can cause problems to flip off the internet when you already have open connections, though there are also API to detect changes in network availability. But I don't see that as a significant problem for "I turn off my WiFi now to do performance-sensitive work". First turn off WiFi, then launch the app you need, in that order. Problem solved.
You're not thinking like a systemd developer. The right thing to do is to ignore all anecdotes and direct evidence that a problem exists. I am talking about systemd renaming your network interfaces because you added or removed hardware.
systemd should add and remove interfaces connected in the exact same hardware path with the same name they had before.
Default literally insane legacy behaviour is just vomiting eth${RAND} where RAND depends on racing conditions.
My educated guess is that people that insist on using the legacy eth${RAND} never had a surprise random firewall and routing rules suddenly apply to different interfaces at a inconvenient time, making production halt and catch on fire, yet.
hardware paths change when you add or remove hardware. systemd developers deny this despite it affecting half of all desktop computers in existence. Your one network jack used to be eth0, systemd now changes it each time you add or remove hardware and insist they're making it more stable instead of more variable whilst they are making it more variable.
Yep. I've experienced on several computers that the systemd-approved "predictable" network device name changes when adding or removing a SSD. The solution is to turn off the network device renaming and allow the single ethernet interface in the machine to always be known as eth0.
systemd developers like to come up with clever solutions to the problems they care about, and ignore the side effects for any use cases they don't care about. And quite often those afflicted use cases are the ones most people would consider to be the more typical use cases.
> I am looking forward to learning how it does work...
It's basic sockets. If you call connect() when the internet is disabled, the errno is ENETUNREACH.
The higher-level API are built on sockets. If any apps are misbehaving, they're simply badly coded.