Individual TCP connections don't need to live that long. Once a macOS system reaches 49.7 days of uptime, this bug starts affecting all TCP connections.
back
2 comments
> Once a macOS system reaches 49.7 days of uptime, this bug starts affecting all TCP connections.
Current `uptime` on my work MacBook (macOS 15.7.4):
17:14 up 50 days, 22 mins, 16 users, load averages: 2.06 1.95 1.94
My personal iMac is at 279 days of uptime.
According to the post:
$ netstat -an | grep -c TIME_WAIT
If the count it returns keeps growing, you're seeing a slow leak. At some point, new connections will start failing. How soon depends entirely on how quickly your machine closes new connections.
Since a lot of client traffic involves the server closing connections instead, I imagine it could take a while.
It's unclear if it'll leak whenever your mac closes or only when it fails to get a (FIN, ACK) back from the peer so the TCP_WAIT garbage collector runs. If it's the latter, then it could take substantially longer, depending on connection quality.
% netstat -an | grep -c TIME_WAIT | wc -l
1You want to drop the wc -l.
Mac `grep -c` counts lines that match, so it always prints 1 line, so piping to wc -l will always return 1.
Or just open up and do netstat -an |grep TCP_WAIT and just watch it. If any don't disappear after a few minutes, then you're seeing the issue.
They probably aren’t affected because the buggy code was only added in macOS 26:
https://github.com/apple-oss-distributions/xnu/blame/f6217f8...
Ouch - "every Mac" from the original post is a hallucination then.
I can live with the writing style when the topic is interesting (here it was for me) but complete untruths are much worse.
You can run `sysctl kern.boottime` to get when it was booted and do the math from there.
I also can't reproduce. I want to say I have encountered this issue at least once, yesterday I before rebooted my uptime was 60 days.
But it's not instant, it just never releases connections. So you can have uptime of 3 years and not run out of connections or run out shortly after hitting that issue.
I'm just going from the bug description in the article, but it seems that depending on your network activity, the exact time you will actually notice an impact could vary quite a bit
if it's in keepalive or retransmission timers, desktop use would mask it completely. browsers reconnect on failure, short-lived requests don't care about keepalives. you'd only notice in things that rely on the OS detecting a dead peer — persistent db connections, ssh tunnels, long-running streams.
> 17:14 up 50 days, 22 mins, 16 users, load averages: 2.06 1.95 1.94
> Am I supposed to be having issues with TCP connections right now? (I'm not.)
If my skim read of the slop post is correct, you'll only have issues on that machine if it hasn't spent any of that time asleep. (I have one Macbook that never sleeps, and I'm pretty sure it hit this bug a week or two back.)
Sure they do. They need to live until torn down.
They almost never do live that long, for whatever reason, but they should.
I meant that having a connection live that long isn't necessary to trigger this bug. I know that for some workloads, it can be important for connections to live that long.