G'Day All,
I only roughly read this thread, but I had a similar problem and found a really
nice solution. I have a MacBook Pro on my desk at work that I connect into my
linux box so I can run some CAD tools and have the windows display on my Mac. I
didn't like doing this using VNC because all I got was a lumped linux desktop
full of windows. So I then used SHH to display all the windows back
individually on my Mac (so I could do Expose etc.) and that was OK, but every
time I had to disconnect my MacBook Pro from the network and go to another
building everything blew up and I lost all my unsaved work.
Then I discovered NX (https://www.nomachine.com). It too displays all the linux
box windows individually onto my Mac, and it does die when it loses the network
BUT you can always reconnect to the network any time later and everything is
right back where you left it. Just wonderful.
Regards,
Mick
On Aug 19, 2016, at 02:34 PM, "James K. Lowden" <jklow...@schemamania.org>
wrote:
On Tue, 21 Jun 2016 15:04:38 -0400
JF Mezei <jfme...@vaxination.ca> wrote:
I have a desktop which acts as X11 server for a number of windows from
other machines/servers.
Same arrangement here. I log into Ubuntu over ssh from my Macbook Pro
running El Capitan, XQuartz 2.7.9 (xorg-server 1.17.4). I do not run
GNU Screen.
One of the problems I have is that if I put my Mac to sleep overnight
to save on power/heat, the remote apps don't get their "ack"s and
declare the connection dead.
I have been living with the problem for months, and have narrowed it
down. If it's a timeout problem, it's not as simple as adjusting
ForwardX11Timeout. I've noticed that idle xterms survive for days, but
emacs frames die when sleep mode (or whatever it's called now) is in
effect.
In the 10.6 era, OS X power options allowed a plugged-in MacBook to
stay awake with the display dimmed. That was not an option for me a
few months ago IIRC, but it appears now it is: under Power Adapter, I
see an unchecked box by "Prevent computer from sleeping automatically
when the display is off". That would probably do the trick, at the
expense of some wear and tear.
I have enabled Power Nap. I suppose my question is: Is Power Nap
expected to allow remote X clients to update their windows? Or is all
sleep fatal for remote clients?
Below I describe the situation in detail, for the benefit of anyone with
similar questions, and in case some detail matters.
I start emacs as follows:
$ cat /usr/local/bin/restart-emacs
#! /bin/sh
host=ubuntu
dir=projects
ssh -f $host "cd $dir && /usr/local/bin/open-modified-files"
On the Ubuntu host, open-modified-files starts emacs with:
pgrep emac[s] || emacs --daemon
After some idle time, the following message will appear in the terminal:
[mac]$ packet_write_wait: Connection to 192.168.5.17:
Broken pipe
[Note to software authors, Kindly indicate the application name in your
error messages!]
Just to be clear, that's Ubuntu complaining about its write:
[mac]$ ifconfig en0 | grep -w inet
inet 192.168.5.11 netmask 0xffffff00 broadcast 192.168.5.255
When that happens, the emacs daemon dies, and I run "restart-emacs"
again. I rebooted 15 days ago. $DISPLAY is now up to localhost:20.0.
I followed the ForwardX11Timeout advice.
[mac]$ grep X11 .ssh/config
XAuthLocation /usr/X11/bin/xauth
ForwardX11 yes
ForwardX11Trusted yes
ForwardX11Timeout 500h
That helped with xterms dying. I still have the xterm-self-relocating
problem, kudos to David Borman for explaining that one.
Curiously, if I launch an xterm on the mac and log into Ubuntu, that's
much less resilient. IOW:
These xterms die early and often:
/usr/X11R6/bin/xterm -e "ssh $host" &
(/opt/X11/bin/xterm is the same inode.)
These xterms stay up:
ssh -f $host /usr/bin/xterm -e "'$cmd'"
Might that perhaps be because of settings in ~/.ssh/config on the
Ubuntu host?
To recap the status quo:
1. ForwardX11Timeout helps. *Idle* connections are not taken down;
xterms launched on Ubuntu maintain their TCP connection through OS X's
sleep period.
2. OS X sleep appears to prevent X clients from writing over
ssh-forwarded connections.
3. Power Nap appears to have no effect.
The "Broken Pipe" message belongs to EPIPE. It seems likely that it
comes from emacsclient. It communicates with emacs over a Unix domain
socket, and with X over TCP, of course. A plausible explanation would
be that emacsclient is unable to communicate with its window, because OS
X is inactive. It recieves an EPIPE error in response to write(2), and
keels over, splatting one desperate message on the screen with its last
breath.
It would be nice if sleep mode did not interfere with remote X client
status. The TCP stack must be "awake" in some sense, else network
activity couldn't rouse the machine. Is this on the radar, or is
remote X slowly dying on the vine?
--jkl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (X11-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/x11-users/mick.mueck%40mac.com
This email sent to mick.mu...@mac.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (X11-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/x11-users/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
