Tmux freezes Mac when killing a long running session #108

Closed
dphaener opened this Issue Sep 14, 2015 · 141 comments

Comments

Projects
None yet
@dphaener

I have found that when I have a local tmux session running for more than 2-3 hours, and I kill it, my Mac (Running OS X El Capitan GM Candidate) freezes completely.

Running Tmux 2.0 Stable in Terminal.app (it also happens when using iTerm).

Additionally, Vim and Terminal apps start becoming sluggish and unresponsive after a session is open for a day or two. I wouldn't mind that too much if I could just kill the session and start it back up again. :)

@nicm

This comment has been minimized.

Show comment
Hide comment
@nicm

nicm Sep 14, 2015

Contributor

There is no way the freezing is a tmux problem, userspace programs shouldn't be able to do this. Either you are hitting a kernel bug or your hardware is dodgy.

What kind of memory usage is tmux hitting after a day or so? Have you got some ridiculously huge history-limit set?

Contributor

nicm commented Sep 14, 2015

There is no way the freezing is a tmux problem, userspace programs shouldn't be able to do this. Either you are hitting a kernel bug or your hardware is dodgy.

What kind of memory usage is tmux hitting after a day or so? Have you got some ridiculously huge history-limit set?

@dphaener

This comment has been minimized.

Show comment
Hide comment
@dphaener

dphaener Sep 14, 2015

I'm using the default history-limit (2000). I've heard of a possible kernel bug, but the description I saw didn't look like the same issue I was having.

I'll keep an eye on the memory usage today (just started a new session about 30 minutes ago) and see if that gives us any more information.

I'm using the default history-limit (2000). I've heard of a possible kernel bug, but the description I saw didn't look like the same issue I was having.

I'll keep an eye on the memory usage today (just started a new session about 30 minutes ago) and see if that gives us any more information.

@pengux

This comment has been minimized.

Show comment
Hide comment
@pengux

pengux Sep 15, 2015

I have the same problem. tmux doesn't have high memory usage when this happens. I also have the Activity Monitor open when I close tmux to see if anything suspicious is happening but couldn't find anything off. I ran tmux -vvvv to have logs but the logs doesn't show any errors either. But the problem is very much reproducible, it happens everytime.

pengux commented Sep 15, 2015

I have the same problem. tmux doesn't have high memory usage when this happens. I also have the Activity Monitor open when I close tmux to see if anything suspicious is happening but couldn't find anything off. I ran tmux -vvvv to have logs but the logs doesn't show any errors either. But the problem is very much reproducible, it happens everytime.

@nicm

This comment has been minimized.

Show comment
Hide comment
@nicm

nicm Sep 15, 2015

Contributor

The freezing? Well, does it happen when you send SIGKILL to tmux? Or on SIGTERM? Or only when you exit all the panes? Does it happen with no .tmux.conf at all? Does it happen on older OS X versions?

Contributor

nicm commented Sep 15, 2015

The freezing? Well, does it happen when you send SIGKILL to tmux? Or on SIGTERM? Or only when you exit all the panes? Does it happen with no .tmux.conf at all? Does it happen on older OS X versions?

@dphaener

This comment has been minimized.

Show comment
Hide comment
@dphaener

dphaener Sep 15, 2015

@nicm I have just confirmed that killing it via SIGKILL causes a system freeze.

@nicm I have just confirmed that killing it via SIGKILL causes a system freeze.

@nicm

This comment has been minimized.

Show comment
Hide comment
@nicm

nicm Sep 15, 2015

Contributor

You need to go and talk to Apple about this.

-------- Original message --------
From: Darin Haener notifications@github.com
Date:15/09/2015 19:25 (GMT+00:00)
To: tmux/tmux tmux@noreply.github.com
Cc: Nicholas Marriott nicholas.marriott@gmail.com
Subject: Re: [tmux] Tmux freezes Mac when killing a long running session
(#108)

@nicm I have just confirmed that killing it via SIGKILL causes a system freeze.


Reply to this email directly or view it on GitHub.

Contributor

nicm commented Sep 15, 2015

You need to go and talk to Apple about this.

-------- Original message --------
From: Darin Haener notifications@github.com
Date:15/09/2015 19:25 (GMT+00:00)
To: tmux/tmux tmux@noreply.github.com
Cc: Nicholas Marriott nicholas.marriott@gmail.com
Subject: Re: [tmux] Tmux freezes Mac when killing a long running session
(#108)

@nicm I have just confirmed that killing it via SIGKILL causes a system freeze.


Reply to this email directly or view it on GitHub.

@dphaener

This comment has been minimized.

Show comment
Hide comment
@dphaener

dphaener Sep 15, 2015

Thought that might be the case.......Unfortunately.

Thought that might be the case.......Unfortunately.

@dphaener dphaener closed this Sep 15, 2015

@paulrouget

This comment has been minimized.

Show comment
Hide comment
@paulrouget

paulrouget Sep 16, 2015

@dphaener do you need to wait 2 hours before this happens? It happens to me imediatly: boot osx 10.11, starts tmux, quit tmux, spinning wheel.

@dphaener do you need to wait 2 hours before this happens? It happens to me imediatly: boot osx 10.11, starts tmux, quit tmux, spinning wheel.

@dphaener

This comment has been minimized.

Show comment
Hide comment
@dphaener

dphaener Sep 16, 2015

@paulrouget Yes that's correct. I haven't nailed down an exact time, but the session has to be open for some time before this behavior occurs.

@paulrouget Yes that's correct. I haven't nailed down an exact time, but the session has to be open for some time before this behavior occurs.

@dphaener

This comment has been minimized.

Show comment
Hide comment
@dphaener

dphaener Sep 16, 2015

@paulrouget Update: Restarting OSX 10.11, opening a tmux session, killing session. This did not cause a full freeze. I then opened a new session. About 10 minutes later, the system began to become unresponsive, slowly. First tmux windows froze, then other programs started to become unresponsive, eventually requiring a full reboot.

@paulrouget Update: Restarting OSX 10.11, opening a tmux session, killing session. This did not cause a full freeze. I then opened a new session. About 10 minutes later, the system began to become unresponsive, slowly. First tmux windows froze, then other programs started to become unresponsive, eventually requiring a full reboot.

@pengux

This comment has been minimized.

Show comment
Hide comment
@pengux

pengux Sep 17, 2015

Actually the problem also occur with SIGTERM, not just SIGKILL. And I've ran tmux without any .tmux.conf too and still the same. As @dphaener reported, it doesn't happens right away, but tmux needs to be open for a while before it starts to slows down and become unresponsive.

pengux commented Sep 17, 2015

Actually the problem also occur with SIGTERM, not just SIGKILL. And I've ran tmux without any .tmux.conf too and still the same. As @dphaener reported, it doesn't happens right away, but tmux needs to be open for a while before it starts to slows down and become unresponsive.

@zacharyvoase

This comment has been minimized.

Show comment
Hide comment
@zacharyvoase

zacharyvoase Sep 18, 2015

I can +1 this. Has anyone filed a Radar yet, or should I? It's unfortunate that it brings the system to a halt but force-rebooting my Mac doesn't cause it to be recognized as a crash, so I don't get any traces/logs.

I can +1 this. Has anyone filed a Radar yet, or should I? It's unfortunate that it brings the system to a halt but force-rebooting my Mac doesn't cause it to be recognized as a crash, so I don't get any traces/logs.

@paulrouget

This comment has been minimized.

Show comment
Hide comment
@paulrouget

paulrouget Sep 19, 2015

Has anyone filed a Radar yet, or should I?

Please do.

Has anyone filed a Radar yet, or should I?

Please do.

@zxcvbn97

This comment has been minimized.

Show comment
Hide comment
@zxcvbn97

zxcvbn97 Sep 19, 2015

+1 Same problem here

+1 Same problem here

@pengux

This comment has been minimized.

Show comment
Hide comment
@pengux

pengux Sep 20, 2015

A tip for anyone interested. Quitting iTerm2 but not quitting tmux and doing a system restart from Mac OS X doesn't freeze the system. I guess it's a little better than a hard reset.

pengux commented Sep 20, 2015

A tip for anyone interested. Quitting iTerm2 but not quitting tmux and doing a system restart from Mac OS X doesn't freeze the system. I guess it's a little better than a hard reset.

@dieyushi

This comment has been minimized.

Show comment
Hide comment
@dieyushi

dieyushi Sep 24, 2015

same problem here.
10.11.1(15B17c) & tmux2

same problem here.
10.11.1(15B17c) & tmux2

@rrva

This comment has been minimized.

Show comment
Hide comment
@rrva

rrva Sep 30, 2015

Check if notifyd is using an abnormal amount of CPU when this occurs. That's what I've been seeing.
If I manage to kill notifyd (new one gets auto-respawned) system recovers.

https://forums.developer.apple.com/thread/9753

rrva commented Sep 30, 2015

Check if notifyd is using an abnormal amount of CPU when this occurs. That's what I've been seeing.
If I manage to kill notifyd (new one gets auto-respawned) system recovers.

https://forums.developer.apple.com/thread/9753

Code-Hex pushed a commit to Code-Hex/setup that referenced this issue Sep 30, 2015

CodeHex CodeHex
更新
tmuxの問題
tmux/tmux#108
@Kudo

This comment has been minimized.

Show comment
Hide comment
@Kudo

Kudo Oct 2, 2015

+1 for the same issue

Kudo commented Oct 2, 2015

+1 for the same issue

@craigp

This comment has been minimized.

Show comment
Hide comment
@craigp

craigp Oct 2, 2015

+1 have been suffering with this since the beta, which I wish I'd never installed, ruined my workflow

craigp commented Oct 2, 2015

+1 have been suffering with this since the beta, which I wish I'd never installed, ruined my workflow

@nicm

This comment has been minimized.

Show comment
Hide comment
@nicm

nicm Oct 2, 2015

Contributor

You all need to stop telling me about this and go and tell Apple.

Contributor

nicm commented Oct 2, 2015

You all need to stop telling me about this and go and tell Apple.

@Kudo

This comment has been minimized.

Show comment
Hide comment
@Kudo

Kudo Oct 2, 2015

Oops, my fault to bother. Now I am going to troubleshooting from notifyd as @rrva suggested.
Thanks guys.

Kudo commented Oct 2, 2015

Oops, my fault to bother. Now I am going to troubleshooting from notifyd as @rrva suggested.
Thanks guys.

@diversario

This comment has been minimized.

Show comment
Hide comment
@diversario

diversario Oct 4, 2015

Same issue here. For me, tmux is slow right from the start – typing take seconds etc. Exiting immediately takes about 10 seconds, after which everything is OK. But exiting a long-running tmux session freezes the entire OS. I also noticed that notify is going to 100% CPU while tmux us running.

Same issue here. For me, tmux is slow right from the start – typing take seconds etc. Exiting immediately takes about 10 seconds, after which everything is OK. But exiting a long-running tmux session freezes the entire OS. I also noticed that notify is going to 100% CPU while tmux us running.

@wincent

This comment has been minimized.

Show comment
Hide comment
@wincent

wincent Oct 5, 2015

You all need to stop telling me about this and go and tell Apple.

While this definitely looks like an Apple bug (and we should file upstream reports), Apple's release cadence tends to be pretty slow, so if it were possible to isolate the thing that tmux is doing that is causing the Apple bug to manifest that would be good, especially if there were some kind of mitigation that could be implemented.

(FWIW, killing notifyd solved the problem instantly for me, and I am not sure how long it will take to return. There might be nefarious consequences to doing that to notifyd, but given a choice between those and a total system lockup, there doesn't seem to be much choice, other than not using tmux, which would be basically unthinkable for me.)

wincent commented Oct 5, 2015

You all need to stop telling me about this and go and tell Apple.

While this definitely looks like an Apple bug (and we should file upstream reports), Apple's release cadence tends to be pretty slow, so if it were possible to isolate the thing that tmux is doing that is causing the Apple bug to manifest that would be good, especially if there were some kind of mitigation that could be implemented.

(FWIW, killing notifyd solved the problem instantly for me, and I am not sure how long it will take to return. There might be nefarious consequences to doing that to notifyd, but given a choice between those and a total system lockup, there doesn't seem to be much choice, other than not using tmux, which would be basically unthinkable for me.)

wincent added a commit to wincent/wincent that referenced this issue Oct 5, 2015

@joshperry

This comment has been minimized.

Show comment
Hide comment
@joshperry

joshperry Oct 5, 2015

Killing notifyd fixes it for me too. Tmux + powerline + iTerm + 10.11

Killing notifyd fixes it for me too. Tmux + powerline + iTerm + 10.11

@appaquet

This comment has been minimized.

Show comment
Hide comment
@appaquet

appaquet Oct 5, 2015

What also helped for me, as I mentioned in https://forums.developer.apple.com/thread/9753, is to increase the status refresh interval (set -g status-interval). It's defaulted to 15 seconds, but it was set to 2 for me as I'm a powerline user. As I'm not really using the powerline's date+time, I bumped it to 60 seconds. It doesn't solve the issue, but as I mentioned in Apple's threads, the context switches and faults count aren't increasing as fast as they were before on notifyd.

appaquet commented Oct 5, 2015

What also helped for me, as I mentioned in https://forums.developer.apple.com/thread/9753, is to increase the status refresh interval (set -g status-interval). It's defaulted to 15 seconds, but it was set to 2 for me as I'm a powerline user. As I'm not really using the powerline's date+time, I bumped it to 60 seconds. It doesn't solve the issue, but as I mentioned in Apple's threads, the context switches and faults count aren't increasing as fast as they were before on notifyd.

@schaefer-dev

This comment has been minimized.

Show comment
Hide comment
@schaefer-dev

schaefer-dev Oct 5, 2015

where can you report this error to apple? Its driving me crazy if I am using my 13'' mbp it really hits performance hard especially when using two external monitors vim/terminal is not fun at all!

I am constantly restarting the process and I slowed down tmux refresh interval but let's be honest that's not a solution at all, even with constant restarting I have quite a lot of lag especially using vim but at least it is somewhat usable (for now) compared to not restarting the process all the time.

where can you report this error to apple? Its driving me crazy if I am using my 13'' mbp it really hits performance hard especially when using two external monitors vim/terminal is not fun at all!

I am constantly restarting the process and I slowed down tmux refresh interval but let's be honest that's not a solution at all, even with constant restarting I have quite a lot of lag especially using vim but at least it is somewhat usable (for now) compared to not restarting the process all the time.

@vinnyang

This comment has been minimized.

Show comment
Hide comment
@vinnyang

vinnyang Oct 5, 2015

@joshperry how did you do that? I tried sending-SIGTERM to notifyd, but it just kept respawning itself…

vinnyang commented Oct 5, 2015

@joshperry how did you do that? I tried sending-SIGTERM to notifyd, but it just kept respawning itself…

@schaefer-dev

This comment has been minimized.

Show comment
Hide comment
@schaefer-dev

schaefer-dev Oct 5, 2015

@vinc386
alias bug="sudo kill $(ps aux | grep '[n]otifyd' | awk '{print $2}')
thats what I am using and its working just fine. respawning is totally intended, but it fixes the lag for some time at least

@vinc386
alias bug="sudo kill $(ps aux | grep '[n]otifyd' | awk '{print $2}')
thats what I am using and its working just fine. respawning is totally intended, but it fixes the lag for some time at least

@adambiggs

This comment has been minimized.

Show comment
Hide comment
@adambiggs

adambiggs Oct 5, 2015

I noticed that when I have an active Tmux session, the notifyd process is flooded with thousands of context switches and faults per second, and seems to consume more and more memory.

But after killing all Tmux sessions, this behaviour stops.

You all need to stop telling me about this and go and tell Apple.

I totally get that Apple is most likely at fault here. But as @wincent said, given the severity of this problem, anything that can be done on the Tmux end to mitigate it would be much better than blindly waiting for a fix from Apple.

Edit: For clarity, when Tmux isn't running notifyd still has context switches & faults coming in, but with Tmux running the rate increases roughly 10x.

I noticed that when I have an active Tmux session, the notifyd process is flooded with thousands of context switches and faults per second, and seems to consume more and more memory.

But after killing all Tmux sessions, this behaviour stops.

You all need to stop telling me about this and go and tell Apple.

I totally get that Apple is most likely at fault here. But as @wincent said, given the severity of this problem, anything that can be done on the Tmux end to mitigate it would be much better than blindly waiting for a fix from Apple.

Edit: For clarity, when Tmux isn't running notifyd still has context switches & faults coming in, but with Tmux running the rate increases roughly 10x.

@schaefer-dev

This comment has been minimized.

Show comment
Hide comment
@schaefer-dev

schaefer-dev Oct 5, 2015

@adambiggs
Does killing all Tmux sessions really helps you? As soon as I start tmux again the error will occur and killing tmux helps just as much as restarting notifyd. Is this different for you?

The problem with Apple being at fault here is that it will probably take really long for them to fix this and to be honest my workflow is pretty f***ed up now after the update but I can't just stop using tmux.

@adambiggs
Does killing all Tmux sessions really helps you? As soon as I start tmux again the error will occur and killing tmux helps just as much as restarting notifyd. Is this different for you?

The problem with Apple being at fault here is that it will probably take really long for them to fix this and to be honest my workflow is pretty f***ed up now after the update but I can't just stop using tmux.

@vinnyang

This comment has been minimized.

Show comment
Hide comment
@vinnyang

vinnyang Oct 5, 2015

@schaefer-dev thanks! Will give that a try next time I run into this bug

vinnyang commented Oct 5, 2015

@schaefer-dev thanks! Will give that a try next time I run into this bug

@adambiggs

This comment has been minimized.

Show comment
Hide comment
@adambiggs

adambiggs Oct 5, 2015

@schaefer-dev killing Tmux sessions only stops the flood of context switches and faults in notifyd. It doesn't fix anything.

I just mentioned this because, for me at least, it seems the problem is limited to Tmux. notifyd doesn't show this behaviour on it's own. So if Tmux is the only process causing this behaviour, then hopefully that means a workaround can be added in Tmux.

My workflow is totally F'd as well. I really hope we don't have to live with this for the next 6 months waiting for Apple...

@schaefer-dev killing Tmux sessions only stops the flood of context switches and faults in notifyd. It doesn't fix anything.

I just mentioned this because, for me at least, it seems the problem is limited to Tmux. notifyd doesn't show this behaviour on it's own. So if Tmux is the only process causing this behaviour, then hopefully that means a workaround can be added in Tmux.

My workflow is totally F'd as well. I really hope we don't have to live with this for the next 6 months waiting for Apple...

@zacharyvoase

This comment has been minimized.

Show comment
Hide comment
@zacharyvoase

zacharyvoase Oct 5, 2015

At the very least I've reported this to Apple. I'm interested to know why it happens and might try to develop a patch for tmux, but I can't make any promises :-)

At the very least I've reported this to Apple. I'm interested to know why it happens and might try to develop a patch for tmux, but I can't make any promises :-)

@wincent

This comment has been minimized.

Show comment
Hide comment
@wincent

wincent Oct 5, 2015

@schaefer-dev

where can you report this error to apple?

You can report it at bugreport.apple.com. Generally, the more reports the merrier; Apple uses the number of reports to prioritize their efforts.

wincent commented Oct 5, 2015

@schaefer-dev

where can you report this error to apple?

You can report it at bugreport.apple.com. Generally, the more reports the merrier; Apple uses the number of reports to prioritize their efforts.

@diversario

This comment has been minimized.

Show comment
Hide comment
@diversario

diversario Oct 5, 2015

Filed a bug with them (22980503).

Can't believe you can't just link to a bug.

Filed a bug with them (22980503).

Can't believe you can't just link to a bug.

@dphaener

This comment has been minimized.

Show comment
Hide comment
@dphaener

dphaener Oct 5, 2015

👍 Also filed a bug (22980745)

dphaener commented Oct 5, 2015

👍 Also filed a bug (22980745)

@joshperry

This comment has been minimized.

Show comment
Hide comment
@joshperry

joshperry Oct 6, 2015

Thanks for filing the bug guys. Now to find a better workaround :)

Thanks for filing the bug guys. Now to find a better workaround :)

@tbjers

This comment has been minimized.

Show comment
Hide comment
@tbjers

tbjers Oct 23, 2015

@kthelgason I just installed 10.11.1 and I am not seeing a freeze after quitting Tmux, however, I tested with set -g status-interval 0, I am going to set it back down to every second to see how that affects things. By the way, 1s interval worked fine in Yosemite.

tbjers commented Oct 23, 2015

@kthelgason I just installed 10.11.1 and I am not seeing a freeze after quitting Tmux, however, I tested with set -g status-interval 0, I am going to set it back down to every second to see how that affects things. By the way, 1s interval worked fine in Yosemite.

@mschae

This comment has been minimized.

Show comment
Hide comment
@mschae

mschae Oct 23, 2015

I am afraid this is still an issue: It didn't freeze my entire Mac OS (as it did before) but I still saw notifyd at 100% when waking my MacBook this morning.

I didn't do a new xcode-select --install after the upgrade yesterday so maybe that step was missing.

Thanks everyone on this for narrowing down what's happening. Was driving me insane the last few weeks.

mschae commented Oct 23, 2015

I am afraid this is still an issue: It didn't freeze my entire Mac OS (as it did before) but I still saw notifyd at 100% when waking my MacBook this morning.

I didn't do a new xcode-select --install after the upgrade yesterday so maybe that step was missing.

Thanks everyone on this for narrowing down what's happening. Was driving me insane the last few weeks.

@tbjers

This comment has been minimized.

Show comment
Hide comment
@tbjers

tbjers Oct 23, 2015

I did an xcode-select --install last night after upgrading to 10.11.1 and set my tmux.conf back to whatever it was before I started trying to narrow down what was going on.

I left my MacBook Air on all night with five open tmux tabs, one running Ionic, one running Rails/Puma, and one running a MongoDB instance, then I got to work this morning.

I just quit tmux as a test and it didn't cause any of the previous issues!

tbjers commented Oct 23, 2015

I did an xcode-select --install last night after upgrading to 10.11.1 and set my tmux.conf back to whatever it was before I started trying to narrow down what was going on.

I left my MacBook Air on all night with five open tmux tabs, one running Ionic, one running Rails/Puma, and one running a MongoDB instance, then I got to work this morning.

I just quit tmux as a test and it didn't cause any of the previous issues!

@kthelgason

This comment has been minimized.

Show comment
Hide comment
@kthelgason

kthelgason Oct 23, 2015

I'm still a little bothered by having no idea what was causing the issue in the first place, but I guess I'll get over it given some time!

I'm still a little bothered by having no idea what was causing the issue in the first place, but I guess I'll get over it given some time!

@russmatney

This comment has been minimized.

Show comment
Hide comment
@russmatney

russmatney Oct 27, 2015

I had these symptoms on two machines for too long and it was making me crazy - read through this thread yesterday, and then I:

Happy to report that everything is back to normal through a few hours of work yesterday and a full day today – notifyd never gets above 0.2% cpu. Hope the same for the rest of you!

I had these symptoms on two machines for too long and it was making me crazy - read through this thread yesterday, and then I:

Happy to report that everything is back to normal through a few hours of work yesterday and a full day today – notifyd never gets above 0.2% cpu. Hope the same for the rest of you!

SebastienElet added a commit to SebastienElet/dotfiles that referenced this issue Oct 27, 2015

@Starefossen

This comment has been minimized.

Show comment
Hide comment
@Starefossen

Starefossen Oct 27, 2015

Mac OS X 10.11.1 and tmux v2.1 did the trick for me. Thanks!

xcode-select --install yields the following for me though:

$ xcode-select --install
> xcode-select: error: command line tools are already installed, use "Software Update" to install updates

Mac OS X 10.11.1 and tmux v2.1 did the trick for me. Thanks!

xcode-select --install yields the following for me though:

$ xcode-select --install
> xcode-select: error: command line tools are already installed, use "Software Update" to install updates
@artursapek

This comment has been minimized.

Show comment
Hide comment
@artursapek

artursapek Oct 31, 2015

I'm happy to confirm that updating to OS X 10.11.1 and tmux 2.0 fixed this annoying problem. notifyd doesn't rise above 2% CPU anymore, whereas before it would regularly climb to anywhere between 10% and 90% CPU.

EDIT I was wrong, notifyd is still surprising me with sometimes > 50% CPU usage. It seemed to be fixed at first, I just hadn't waited long enough to confirm. Still looking for a fix for this.

This had been bothering me for weeks. tmux/vim combo should be fast! That's the point!

I'm happy to confirm that updating to OS X 10.11.1 and tmux 2.0 fixed this annoying problem. notifyd doesn't rise above 2% CPU anymore, whereas before it would regularly climb to anywhere between 10% and 90% CPU.

EDIT I was wrong, notifyd is still surprising me with sometimes > 50% CPU usage. It seemed to be fixed at first, I just hadn't waited long enough to confirm. Still looking for a fix for this.

This had been bothering me for weeks. tmux/vim combo should be fast! That's the point!

ahmedelgabri added a commit to ahmedelgabri/dotfiles that referenced this issue Oct 31, 2015

@drn

This comment has been minimized.

Show comment
Hide comment
@drn

drn Nov 3, 2015

I have been lurking on this (and other threads) about issues with a slow tmux environment after upgrading to El Capitan. None of the before-mentioned fixes solved the slowness, so thought I should share.

Disabling the status line made it somewhat better, but didn't completely solve the lag. I noticed that the fontd process spiked while I was getting lag in tmux. I checked my iTerm2 config and for some reason after the El Capitan upgrade, the "Regular Font" and "Non-ASCII Font" settings changed from my regular "Menlo Regular for Powerline" to "Monaco". Because I was using powerline symbols in my status line / prompt, I suspect that fontd was trying to search for an acceptable fallback every time a powerline character was used. Switching it back to "Menlo Regular for Powerline" has solved my slow environment.

Hope this helps someone.

drn commented Nov 3, 2015

I have been lurking on this (and other threads) about issues with a slow tmux environment after upgrading to El Capitan. None of the before-mentioned fixes solved the slowness, so thought I should share.

Disabling the status line made it somewhat better, but didn't completely solve the lag. I noticed that the fontd process spiked while I was getting lag in tmux. I checked my iTerm2 config and for some reason after the El Capitan upgrade, the "Regular Font" and "Non-ASCII Font" settings changed from my regular "Menlo Regular for Powerline" to "Monaco". Because I was using powerline symbols in my status line / prompt, I suspect that fontd was trying to search for an acceptable fallback every time a powerline character was used. Switching it back to "Menlo Regular for Powerline" has solved my slow environment.

Hope this helps someone.

@Atcold

This comment has been minimized.

Show comment
Hide comment
@Atcold

Atcold Nov 4, 2015

@drn, I think you're completely off topic here. This thread is about El Capitan freezing when tmux is exited.

Atcold commented Nov 4, 2015

@drn, I think you're completely off topic here. This thread is about El Capitan freezing when tmux is exited.

@carlitux

This comment has been minimized.

Show comment
Hide comment
@carlitux

carlitux Nov 4, 2015

As @artursapek with OS X and tmux updates this looks like is fixed...

carlitux commented Nov 4, 2015

As @artursapek with OS X and tmux updates this looks like is fixed...

@drn

This comment has been minimized.

Show comment
Hide comment
@drn

drn Nov 4, 2015

@Atcold - Fair enough, but to an extent.

The lag due to the increased CPU load caused my entire machine to hang. This was related to the second issue reported by the issue reporter "Additionally, Vim and Terminal apps start becoming sluggish and unresponsive after a session is open for a day or two."

Yes, likely a completely separate issue. However, any tmux users running into "tmux lag in el capitan" would definitely run into this thread and could potentially benefit from my use case.

Glad the original issue is fixed.

drn commented Nov 4, 2015

@Atcold - Fair enough, but to an extent.

The lag due to the increased CPU load caused my entire machine to hang. This was related to the second issue reported by the issue reporter "Additionally, Vim and Terminal apps start becoming sluggish and unresponsive after a session is open for a day or two."

Yes, likely a completely separate issue. However, any tmux users running into "tmux lag in el capitan" would definitely run into this thread and could potentially benefit from my use case.

Glad the original issue is fixed.

@kthelgason

This comment has been minimized.

Show comment
Hide comment
@kthelgason

kthelgason Nov 5, 2015

@drn not a separate issue, this is exactly what I was experiencing. As discussed above it's is now fixed.

@drn not a separate issue, this is exactly what I was experiencing. As discussed above it's is now fixed.

@maxjacobson

This comment has been minimized.

Show comment
Hide comment
@maxjacobson

maxjacobson Nov 5, 2015

I've been following this thread because I've been experiencing some tmux freezes since upgrading to El Capitan. I'm using the latest tmux from Homebrew and still seeing the issue. Where was it fixed?

I've been following this thread because I've been experiencing some tmux freezes since upgrading to El Capitan. I'm using the latest tmux from Homebrew and still seeing the issue. Where was it fixed?

@dphaener

This comment has been minimized.

Show comment
Hide comment
@dphaener

dphaener Nov 5, 2015

@maxjacobson I had to upgrade to OS X 10.11.1 and Tmux 2.0 to get it to completely stop. For me, it has resolved both issues (the freezing and the laginess).

dphaener commented Nov 5, 2015

@maxjacobson I had to upgrade to OS X 10.11.1 and Tmux 2.0 to get it to completely stop. For me, it has resolved both issues (the freezing and the laginess).

@diversario

This comment has been minimized.

Show comment
Hide comment
@diversario

diversario Nov 5, 2015

For me, running tmux 2.1 and OS X 10.11.1 still hasn't resolved it. I cannot set status-interval below 10 or turn on visual-activity without tmux eventually killing my machine.

For me, running tmux 2.1 and OS X 10.11.1 still hasn't resolved it. I cannot set status-interval below 10 or turn on visual-activity without tmux eventually killing my machine.

@fuadsaud

This comment has been minimized.

Show comment
Hide comment
@fuadsaud

fuadsaud Nov 5, 2015

Updating to OS X 10.11.1 and Tmux HEAD has also fixed it for me.

fuadsaud commented Nov 5, 2015

Updating to OS X 10.11.1 and Tmux HEAD has also fixed it for me.

@maxjacobson

This comment has been minimized.

Show comment
Hide comment
@maxjacobson

maxjacobson Nov 5, 2015

I'm using OS X 10.11.1 and tmux 2.1 (latest from Homebrew). When you say HEAD, does it mean you've had to build it manually from source? I'll try 😅

I'm using OS X 10.11.1 and tmux 2.1 (latest from Homebrew). When you say HEAD, does it mean you've had to build it manually from source? I'll try 😅

@fuadsaud

This comment has been minimized.

Show comment
Hide comment
@fuadsaud

fuadsaud Nov 5, 2015

@maxjacobson brew install --HEAD tmux 😄 That'll pull down tmux 2.2 source (from git master) and build it.

fuadsaud commented Nov 5, 2015

@maxjacobson brew install --HEAD tmux 😄 That'll pull down tmux 2.2 source (from git master) and build it.

@lukemarsden lukemarsden referenced this issue in tmate-io/tmate Nov 5, 2015

Closed

Memory leak on El Capitan (OSX) #61

@maxjacobson

This comment has been minimized.

Show comment
Hide comment

@fuadsaud aha thanks 🐋

@timhtheos

This comment has been minimized.

Show comment
Hide comment
@timhtheos

timhtheos Nov 5, 2015

+1 Subscribing.

+1 Subscribing.

maur8ino added a commit to maur8ino/dotfiles that referenced this issue Nov 7, 2015

creasty added a commit to creasty/dotfiles that referenced this issue Nov 7, 2015

@filipeamoreira

This comment has been minimized.

Show comment
Hide comment

uu59 added a commit to uu59/dotfiles that referenced this issue Nov 16, 2015

@dmuth

This comment has been minimized.

Show comment
Hide comment
@dmuth

dmuth Nov 23, 2015

Just to throw in my 2 cents, here what was I had going on:

  • OS/X 10.11, which was upgraded from 10.10, which had previously been upgraded from 10.8(?) which came with this iMac nearly 3 years ago
  • Tmux 1.9a
  • Latest version of Homebrew

The problem I was having is that tmux was slowing down when I ran Ansible 1.8.4 against a VM in Vagrant. Whenever I ran Ansible, tmux would slow to a crawl while Ansible was running in the same window. (that is, my adjacent pane would slow down by a lot)

As per some of the suggestions here, I killed the notifyd process and that instantly fixed the problem. A new notifyd was restarted, but tmux now behaved normally.

-- Doug

dmuth commented Nov 23, 2015

Just to throw in my 2 cents, here what was I had going on:

  • OS/X 10.11, which was upgraded from 10.10, which had previously been upgraded from 10.8(?) which came with this iMac nearly 3 years ago
  • Tmux 1.9a
  • Latest version of Homebrew

The problem I was having is that tmux was slowing down when I ran Ansible 1.8.4 against a VM in Vagrant. Whenever I ran Ansible, tmux would slow to a crawl while Ansible was running in the same window. (that is, my adjacent pane would slow down by a lot)

As per some of the suggestions here, I killed the notifyd process and that instantly fixed the problem. A new notifyd was restarted, but tmux now behaved normally.

-- Doug

@artursapek

This comment has been minimized.

Show comment
Hide comment
@artursapek

artursapek Nov 28, 2015

I have some more fun info to share. Last night, still frustrated with this problem, I tried what this reddit user suggested. In retrospect, I should have just set tmux's status-interval to 0 and been happy with that, but I was being stubborn and thought "I never use notification center anyway, so this sounds like a good idea".

About 10 minutes after unloading notifyd I tried restarting my laptop to start a fresh session, and to my horror the login screen would slow to a crawl at around 75% progress, slowly inch forward to a full 100%, and then never finish. It would just sit indefinitely at 100%, taunting me. I waited 10-20 minutes. I can't imagine why it would have finally gone through after that long. It was clearly just broken.

I restarted probably a dozen times, and reproduced every time.

I'm pretty certain this was caused by my turning off notifyd. I had successfully restarted a few days prior to this.

The next thing I tried was reinstalling El Capitan from recovery mode, but the same issue persisted after the fresh install. This was kind of confounding.

My next idea was to downgrade to Yosemite from a USB because I preferred it anyway. Unfortunately every blog post I could find about it online mentioned downloading the installer from the App Store, where it's no longer available. I couldn't find it anywhere else on the net, either. Apple clearly wants people to stay on El Capitan.

After a very frustrating evening, I ended up running an overnight tar backup of my home directory to an external disk. Then, this morning, I booted into recovery mode and wiped Macintosh HD. When I rebooted again, the machine went straight into NetBoot mode and miraculously decided to install Yosemite instead of El Capitan! This made sense, because it was the OS my machine shipped with (early 2015 MBAir). There's clearly still some Apple machines out there serving Yosemite up to broken machines like mine.

That install went quickly and smoothly, and after I extracted my home directory back onto the machine I only have a couple hours of re-installing and re-configuring left ahead of me. Very happy ending, if you ask me. I'm glad to be rid of El Capitan and its notifyd/kernel_task bullshit. What a racket.

I have some more fun info to share. Last night, still frustrated with this problem, I tried what this reddit user suggested. In retrospect, I should have just set tmux's status-interval to 0 and been happy with that, but I was being stubborn and thought "I never use notification center anyway, so this sounds like a good idea".

About 10 minutes after unloading notifyd I tried restarting my laptop to start a fresh session, and to my horror the login screen would slow to a crawl at around 75% progress, slowly inch forward to a full 100%, and then never finish. It would just sit indefinitely at 100%, taunting me. I waited 10-20 minutes. I can't imagine why it would have finally gone through after that long. It was clearly just broken.

I restarted probably a dozen times, and reproduced every time.

I'm pretty certain this was caused by my turning off notifyd. I had successfully restarted a few days prior to this.

The next thing I tried was reinstalling El Capitan from recovery mode, but the same issue persisted after the fresh install. This was kind of confounding.

My next idea was to downgrade to Yosemite from a USB because I preferred it anyway. Unfortunately every blog post I could find about it online mentioned downloading the installer from the App Store, where it's no longer available. I couldn't find it anywhere else on the net, either. Apple clearly wants people to stay on El Capitan.

After a very frustrating evening, I ended up running an overnight tar backup of my home directory to an external disk. Then, this morning, I booted into recovery mode and wiped Macintosh HD. When I rebooted again, the machine went straight into NetBoot mode and miraculously decided to install Yosemite instead of El Capitan! This made sense, because it was the OS my machine shipped with (early 2015 MBAir). There's clearly still some Apple machines out there serving Yosemite up to broken machines like mine.

That install went quickly and smoothly, and after I extracted my home directory back onto the machine I only have a couple hours of re-installing and re-configuring left ahead of me. Very happy ending, if you ask me. I'm glad to be rid of El Capitan and its notifyd/kernel_task bullshit. What a racket.

kruppel added a commit to kruppel/shadowboxer that referenced this issue Dec 11, 2015

@stixpjr

This comment has been minimized.

Show comment
Hide comment
@stixpjr

stixpjr Dec 14, 2015

AFAICT, this might be fixed with 10.11.2... I've been running until now with "/usr/bin/pkill notifyd" 15 minute cron job workaround, and I've noticed notifyd spiking CPU usage frequently. After installing 10.11.2, I've disabled the cronjob and notifyd CPU usage is negligible after reasonably heavy tmux use. Maybe Apple silently fixed it?

stixpjr commented Dec 14, 2015

AFAICT, this might be fixed with 10.11.2... I've been running until now with "/usr/bin/pkill notifyd" 15 minute cron job workaround, and I've noticed notifyd spiking CPU usage frequently. After installing 10.11.2, I've disabled the cronjob and notifyd CPU usage is negligible after reasonably heavy tmux use. Maybe Apple silently fixed it?

@chestarss

This comment has been minimized.

Show comment
Hide comment
@chestarss

chestarss Apr 19, 2016

+1 same problem

+1 same problem

@kthelgason

This comment has been minimized.

Show comment
Hide comment
@kthelgason

kthelgason Apr 19, 2016

@chestarss have you read and tried any of the solutions in this thread?

@chestarss have you read and tried any of the solutions in this thread?

@chestarss

This comment has been minimized.

Show comment
Hide comment
@chestarss

chestarss Apr 19, 2016

@kthelgason i am tring "set -g status-interval 0"

@kthelgason i am tring "set -g status-interval 0"

@kthelgason

This comment has been minimized.

Show comment
Hide comment
@kthelgason

kthelgason Apr 19, 2016

Are you not able to update to 10.11.2 or newer?

Sent from my iPhone

On Tue, Apr 19, 2016 at 4:11 AM -0700, "chestar" notifications@github.com wrote:

@kthelgason i am tring "set -g status-interval 0"


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

Are you not able to update to 10.11.2 or newer?

Sent from my iPhone

On Tue, Apr 19, 2016 at 4:11 AM -0700, "chestar" notifications@github.com wrote:

@kthelgason i am tring "set -g status-interval 0"


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@chestarss

This comment has been minimized.

Show comment
Hide comment
@chestarss

chestarss Apr 19, 2016

my os version is 10.11 now, i will update it to 10.11.4

my os version is 10.11 now, i will update it to 10.11.4

@chestarss

This comment has been minimized.

Show comment
Hide comment
@chestarss

chestarss Apr 19, 2016

@kthelgason my english is so poor, the above answer may not recognise

@kthelgason my english is so poor, the above answer may not recognise

@bgold-cosmos bgold-cosmos referenced this issue in Swordfish90/cool-retro-term Jul 5, 2016

Closed

Hangs on osx when invoking tmux #288

kirikiriyamama added a commit to kirikiriyamama/dotfiles that referenced this issue Sep 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment