On 06/03/14 15:42, Balazs Kezes wrote: > On 2014-03-06 14:00, Jan Larres wrote: >> Like I said I had to restart tmux so I can't test that at the moment, >> but I could try to reproduce it. > > So when I do > set -g status-right "#(sleep 30)" > set -g status-interval 1 > I see that tmux starts hoarding the sockets. So it possible that your > tmux-status is the culprit as you suspect although I haven't found any > obvious part in it which could hang in case of high load. If that is the > problem then maybe the hanged instances are still running if you haven't > rebooted your machine. Try "pgrep tmux-status" to check this. I'd > definitely suggest adding start/exit logging to your status script just > make sure we know it isn't that what hangs.
Are you seeing the sleep jobs in the 'Jobs:' output of 'tmux info'? I didn't have any jobs there, but I don't know how to test it at the moment since as I mentioned that section seems to be missing from my info output in the current tmux revision. > The socket inodes are consecutive which isn't in my case thus this might > mean it's a different leak. If the tmux-status investigation fails I > suggest creating a debug tmux and running the server under "valgrind > --track-fds=yes" to determine where were the fds actually allocated in > order to narrow down the search area. That sounds like an interesting idea, I'll have a look at that. -Jan ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
