seems to be working fine with Lion for me

[dsanson]

Just wanted to drop a note saying that this has been working fine for me on Lion. I use it regularly, and have not noticed any kernel panics. I was using build 51bbc9f, but annoyed by the warning message, so am now running 8c5ea5f.

[ChrisJohnsen]

Thanks for your feedback!

Is there any chance you are using Terminal instead of iTerm?

I have several reports from iTerm users, but the panic report (linked in the commit message of 51bbc9f) described using either/both iTerm and Terminal (it was not clear). If I get a success report from someone using tmux and the wrapper under Lion’s Terminal, then I will feel more comfortable about re-pushing something like 8c5ea5f.

[dsanson]

Ah. I am using iTerm, not Terminal.

[ChrisJohnsen]

I have pushed a couple of new commits (dadea0a) that have the same effect as the reverted 8c5ea5f: use the same method as 10.6, but do not warn when run under 10.7.

[tgray]

Just so you know, I'm the one who reported the kernel panics. I just reported another with 10.7.2. I've experienced them with both iTerm and Terminal. The latest was with iTerm and I wasn't even using this pasteboard program. So at least in my case, I don't actually think the pasteboard program is at fault...

[ChrisJohnsen]

@tgray: Thanks for the extra feedback! I am sad to hear that you are still having panics, though.

[jassinm]

i have the problem under 10.7 that once i add reattach-to-user-namespace :
panes , windows do not always get a login shell. This is really random.
At the moment i just kill the pane and hope that the next pane starts up successfully.
any help would be appreciated

[ChrisJohnsen]

@locojay: Please open a new issue since your problem is not related to dsanson’s report that started this issue.

I do not have a 10.7 installation, but I have never seen a problem where a shell randomly fails to start up (under 10.6). I have sometimes run into process limits (i.e. ulimit -u in ksh, bash, and zsh), but the shell (or tmux, if it is completely unable to fork at all) will usually generate error messages about “resource temporarily unavailable”.

You could start investigating by using Activity Monitor to examine what processes are running under tmux when you see this happen. If you use the “All Processes, Hierarchically” view, you should be able to pick out the tmux server and Sample or Inspect it or its children to try to see what they are doing (you can probably identify the newest child—your prime suspect—by its PID: usually the highest number, unless your tmux server has lived through a wrap-over of the PIDs). If the problem is happening inside tmux, then you may need to run it in verbose mode to collect a log.

[jassinm]

thanks i opened issue #5