Re: Keeping X11 connections alive during sleep
Re: Keeping X11 connections alive during sleep
- Subject: Re: Keeping X11 connections alive during sleep
- From: "James K. Lowden" <email@hidden>
- Date: Wed, 17 Aug 2016 15:22:59 -0400
On Tue, 21 Jun 2016 15:04:38 -0400
JF Mezei <email@hidden> 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 (email@hidden)
This email sent to email@hidden