On 2014-05-01 14:31 +0200, Pavlos Parissis wrote:
> I know that Nicholas has already reported that he fixed some leaks,
> but I thought it could be useful for Kezes.
Awesome, thanks! Yes, the head version already contains the fix so we
can expect it to officially arrive in the next version.
--
B
Hi,
I left my tmux sessions live while I was away for 2 weeks and saw that the
tmux_fork_proved file was created.
Here are the info
pparissis at poseidonas in ~ *130
ls -ls /tmp/tmux_fork_proved
0 -rw-r--r-- 1 pparissis pparissis 0 Apr 15 05:37 /tmp/tmux_fork_proved
pparissis at poseidonas in ~
c
On 15/04/14 10:28, Nicholas Marriott wrote:
> i have fixed this leak, cheers
Great, thank you!
-Jan
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases
On 15/04/14 08:14, Balazs Kezes wrote:
> On 2014-04-14 11:57 +1200, Jan Larres wrote:
>> I usually hit the problem when my machine becomes unresponsive for a
>> while due to heavy swapping when starting a memory-heavy process. I'm
>> not sure if that could cause fork() to fail, but it sounds like a
i have fixed this leak, cheers
On Sat, Apr 12, 2014 at 09:49:17PM +0100, Balazs Kezes wrote:
> On 2014-04-07 13:54 +0200, Pavlos Parissis wrote:
> > Let me know what I else I can do in order to help troubleshooting
> > this.
>
> So I've skimmed the source again and now I've found an actual leak
On 2014-04-14 11:57 +1200, Jan Larres wrote:
> I usually hit the problem when my machine becomes unresponsive for a
> while due to heavy swapping when starting a memory-heavy process. I'm
> not sure if that could cause fork() to fail, but it sounds like a
> possibility.
Yeah. If you have large amo
On 13/04/14 08:49, Balazs Kezes wrote:
> So I've skimmed the source again and now I've found an actual leak but
> I'm not sure you are hitting this or not. If the fork() in job_run()
> fails then tmux will definitely leak 2 fds. Is it possible that you have
> low process limits or huge amounts of p
On 12/04/2014 10:49 μμ, Balazs Kezes wrote:
> On 2014-04-07 13:54 +0200, Pavlos Parissis wrote:
>> Let me know what I else I can do in order to help troubleshooting
>> this.
>
> So I've skimmed the source again and now I've found an actual leak but
> I'm not sure you are hitting this or not. If th
On 12/04/2014 10:49 μμ, Balazs Kezes wrote:
> On 2014-04-07 13:54 +0200, Pavlos Parissis wrote:
>> Let me know what I else I can do in order to help troubleshooting
>> this.
>
> So I've skimmed the source again and now I've found an actual leak but
> I'm not sure you are hitting this or not. If th
On 2014-04-07 13:54 +0200, Pavlos Parissis wrote:
> Let me know what I else I can do in order to help troubleshooting
> this.
So I've skimmed the source again and now I've found an actual leak but
I'm not sure you are hitting this or not. If the fork() in job_run()
fails then tmux will definitely
On 08/03/14 12:44, Balazs Kezes wrote:
> On 2014-03-07 19:52, Jan Larres wrote:
>> Are you seeing the sleep jobs in the 'Jobs:' output of 'tmux info'?
>
> Ah, yes, I do see them in my case.
Then I would guess that either this is not actually the cause or somehow
the descriptors do not get properly
On 2014-03-07 19:52, Jan Larres wrote:
> Are you seeing the sleep jobs in the 'Jobs:' output of 'tmux info'?
Ah, yes, I do see them in my case.
> 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 outp
On 06/03/14 21:08, Nicholas Marriott wrote:
> Email me the script you are running with #() in the status line please.
That script is right here together with the other tmux configuration:
https://github.com/majutsushi/etc/tree/master/tmux
The lib directory in there contains the individual function
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
Email me the script you are running with #() in the status line please.
On Thu, Mar 06, 2014 at 02:00:16PM +1300, Jan Larres wrote:
> On 06/03/14 12:44, Thomas Adam wrote:
> > On 5 March 2014 23:40, Jan Larres wrote:
> >> No, it happens without me doing anything. Now that I think about it the
>
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
On 06/03/14 12:44, Thomas Adam wrote:
> On 5 March 2014 23:40, Jan Larres wrote:
>> No, it happens without me doing anything. Now that I think about it the
>> rate may be related to my statusline update interval (1 second), but
>> unfortunately I can't test that any more as I had to restart tmux t
On 5 March 2014 23:40, Jan Larres wrote:
> On 06/03/14 00:32, Nicholas Marriott wrote:
>> Do they increase as you use your run-shell M-hjkl bindings?
>
> No, it happens without me doing anything. Now that I think about it the
> rate may be related to my statusline update interval (1 second), but
>
On 06/03/14 00:32, Nicholas Marriott wrote:
> Do they increase as you use your run-shell M-hjkl bindings?
No, it happens without me doing anything. Now that I think about it the
rate may be related to my statusline update interval (1 second), but
unfortunately I can't test that any more as I had t
Do they increase as you use your run-shell M-hjkl bindings?
Original message
From: Jan Larres
Date: 05/03/2014 04:23 (GMT+00:00)
To: tmux-users@lists.sourceforge.net
Subject: Re: tmux leaking socket descriptors under certain circumstances
It just happened again, all the
It just happened again, all the file descriptors are used up, and there
are no jobs in the info output. I noticed something else interesting,
though: in the 'Clients' section the 'references' value keeps climbing
for all of them, even now that the rest of the system has returned to
normal (and the
On 04/03/14 05:13, Nicholas Marriott wrote:
> Please send me your .tmux.conf too.
Here you go:
https://github.com/majutsushi/etc/tree/master/tmux
-Jan
--
Subversion Kills Productivity. Get off Subversion & Make the Move
Please send me your .tmux.conf too.
Original message
From: Jan Larres
Date: 03/03/2014 03:55 (GMT+01:00)
To: tmux-users@lists.sourceforge.net
Subject: Re: tmux leaking socket descriptors under certain circumstances
On 27/02/14 12:06, Nicholas Marriott wrote:
> What t
On 27/02/14 12:06, Nicholas Marriott wrote:
> What tmux version?
A recent-ish Git revision, but the problem has been around for quite a
while. I'm not entirely sure which revision unfortunately as I've
updated my repository since then but not restarted the server.
> If you run "tmux info" once it
What tmux version?
If you run "tmux info" once it starts to leak do you see a lot of jobs
listed at the end?
On Wed, Feb 26, 2014 at 11:49:50AM +1300, Jan Larres wrote:
> Hi,
>
> I may have mentioned this in passing before, but I wanted to give it a
> bit more attention as it is quite annoying.
Hi,
I may have mentioned this in passing before, but I wanted to give it a
bit more attention as it is quite annoying. In some circumstances that I
unfortunately haven't been able to reliably reproduce tmux leaks file
descriptors for sockets, until the descriptor limit is reached and I
can't execu
26 matches
Mail list logo
