Remotely starting local X application?

November 16, 2007 9:16 PM

How do I restart an X Windows application running on a remote machine, and have it display on that computer's locally-attached display? (I do not want to forward/tunnel it to the machine I'm sitting at.)

Two computers, foo and bar. Foo is a machine connected to a big display, but lacking any local controls (keyboard or mouse). Bar is a laptop. Foo normally runs an X Windows application, but sometimes this application crashes.

How can I, by connecting to foo from bar via SSH, restart an X app running on foo, and have it come back up on foo's display? All the resources I can find on the net deal with forwarding X connections so that I could display them remotely on bar (which I can do fine), but that's not what I want. I want to issue the command via SSH, but have the application display itself on the local display. (And once I get it running, I want to close down the SSH connection.)

I'm sure it has something to do with the DISPLAY variable, but I can't figure out what to set it as. (I've tried setting it to "localhost:0" and "127.0.0.1:0" as well as ":1" on both, but both give "can't open display" errors.)

It seems like this ought to be a lot easier than tunneling an X connection, but I'm stumped.

This is all using Knoppmyth, which is Debian/X11.org-based, with Bash.

posted by Kadin2048 to computers & internet (16 comments total)

You need 0.0 on those DISPLAY values. Also, if you want to discojnnect your SSH session without blowing away your X client, run it through nohup or use the disown command in bash. (or never mind if you are using tcsh)
posted by mkb at 9:22 PM on November 16, 2007

If I set DISPLAY=0:0, I get "Can't open display" errors. (Same for 0:1.)

Good suggestion, though...
posted by Kadin2048 at 9:28 PM on November 16, 2007

X display authorization is a dark and murky corner of my memory, but I believe your problem is that the person who started the X server is different from you when you log in via SSH. The X server only lets the person who started it open new connections. If you can get an X program executed before the normally-running application, you can do "xhost +" to accept connections from anybody. Then, when the app crashes, you should be able to start it again by saying "application -display :0". (Note that you may have to use nohup(1) to keep the application from getting killed when you log out of ssh.) Check out the xauth(1) man page, too, for a better solution than letting anybody pop up new windows.
posted by spacewrench at 9:29 PM on November 16, 2007 [1 favorite has favorites]

X applications often have a -display or --display option as well. Also, the format you're wanting to use for the variable/option is more likely to be "0:0" than the other options you tried.
posted by schof at 9:30 PM on November 16, 2007

Umm..plain :0 should work, or at least it worked for years with XFree. Perhaps Xorg is different?

What may be an issue is the program actually connecting to the X server, which may require an xhost command.

Oh, be sure you're doing 'export DISPLAY=:0', otherwise the variable will remain local to the shell.
posted by wierdo at 9:30 PM on November 16, 2007 [1 favorite has favorites]

Clarification: here's what I'm actually doing...

$ set DISPLAY=127.0.0.1:0.0
$ xeyes
Error: Can't open display: 0.0

Same for all variations of localhost, 127.0.0.1, 0, etc., and for displays 0 and 1 on each.
posted by Kadin2048 at 9:31 PM on November 16, 2007

@wierdo: That seemed to produce something different.

$ export DISPLAY=:0
$ xeyes
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

The connection refused message is different from what I've been getting before, so that's progress at least.
posted by Kadin2048 at 9:33 PM on November 16, 2007

Many Linux distros don't turn on the TCP socket for X. Therefore, "[address]:0" often doesn't work. (Of course, if you can find the right config file, you could turn on TCP connections too.) In any case, ":0" or ":0.0" should do the trick, except for the authorization weirdness I mentioned previously.
posted by spacewrench at 9:34 PM on November 16, 2007

Just setting DISPLAY to ":0.0" (no hostname, display 0, screen 0 on that display) should do it in the common case...

You might also not have permission to talk to the display (if, e.g., you're using xauth cookies and sshing in as a different user than the one on the display). You can fix that with "xhost", say by authorizing all local users to use the display ("xhost +localhost"), or you can use xauth (which I've forgotten how to use — check the man pages).

(On preview: yeah.)
posted by hattifattener at 9:35 PM on November 16, 2007

What does foo think its IP address is ? Normally you would set DISPLAY to foo:0.0
posted by rfs at 9:45 PM on November 16, 2007

Got it working!

What I had to do was edit the ~/.fluxbox/apps file for the user who starts the machine's initial X session, and add
[startup] {xhost +}
at the top, before the other applications that start automatically.

Then, I can SSH in later and restart the program I want displayed (after exporting DISPLAY=:0), and I don't get the 'refused by server' error.
posted by Kadin2048 at 10:18 PM on November 16, 2007

2nd spacewrench and hattifattener. You must be the same user.

If xauth vooodoo doesn't work, one other option would be to keep an instance of x11vnc running - this will let you VNC into foo's real X display.
posted by zsazsa at 10:21 PM on November 16, 2007

No. Xhost + is not a good idea. It allows anyone to run an application on the X server. I don't remember all that much about authentication in X but at the very least you can use xhost to limit access to particular users. You shouldn't stop there though. If you're going to do this, you should look at the manual page for xauth and whatever display manager the workstation is using.
posted by rdr at 2:48 AM on November 17, 2007

Second xhost+ being a bad idea unless TCP listening is turned off for the X server and there are no other local users.

Among other things, the ability to attach to an X display also lets you capture all keyboard and mouse input without the original user knowing.
posted by TravellingDen at 6:02 AM on November 17, 2007

OMG, 'xhost -' now! 'xhost +' is crazy "root my box" talk.


# as root, extract xauth info from user that started X
$ XAUTHORITY=/home/usrname/.Xauthority xauth list
hostname/unix:0 MIT-MAGIC-COOKIE-1 273bf22484148c6504f5d85e6ef510e5
hostname.sub.domain:0 MIT-MAGIC-COOKIE-1 273bf22484148c6504f5d85e6ef510e5

# as current user, add xauth info to your xauth info...
$ xauth add hostname/unix:0 MIT-MAGIC-COOKIE-1 273bf22484148c6504f5d85e6ef510e5
$ xauth add hostname.sub.domain:0 MIT-MAGIC-COOKIE-1 273bf22484148c6504f5d85e6ef510e5

# set display variable and start application
$ DISPLAY=hostname.sub.domain:0 /dev/null 2>&1 &


gah!, 'xhost +' is like having a Windows box.
posted by zengargoyle at 12:12 PM on November 17, 2007

bah, code tags failed me... export/import the xauth stuff and set DISPLAY appropriately and start your application with appropriate daemonization.
posted by zengargoyle at 12:15 PM on November 17, 2007