| 2008-11-27 12:29:18 |
GeorgeDunlap |
description |
Description: Ubuntu 8.04.1
Release: 8.04
When logging in to a machine through ssh (without -X or -Y), XAUTHORITY is not set; and when logging in non-interactively, XDB_SESSION_COOKIE is not set. This prevents programs started over an ssh session to connect to the X server of the machine on which it's running.
I use synergy to control my work desktop from my laptop (and so I have more screen real estate). I wrote the following script to automatically run the synergy server and client when I come in to work in the morning:
#!/bin/bash
killall synergys
ssh gdunlap@elijah "killall synergyc"
synergys
ssh -R 24800:localhost:24800 gdunlap@elijah "synergyc -f --name elijah localhost"
ssh gdunlap@elijah "killall synergyc"
killall synergys
It worked until I upgraded this morning, at which point it gave the following error:
DEBUG: CXWindowsScreen.cpp,840: XOpenDisplay(":0.0")
No protocol specified
WARNING: synergyc.cpp,337: cannot open secondary screen: unable to open screen
Digging a little deeper, I found that synergyc was trying to use ~/.Xauthority instead of /tmp/.gdm[...] as it should have, because XAUTHORITY was not being set when logging in over ssh.
Furthermore, I discovered that if I logged in using an interactive shell and set XAUTHORITY manually, then synergyc worked; but if I set XAUTHORITY script-wise in a non-interactive shell, it still didn't work. Further investigation revealed that in the interactive shell, XDB_SESSION_COOKIE is being set, but in a non-interactive shell, it's not being set. If logged in interactively and unset XDB_SESSION_COOKIE, it failed the same way as if I logged in non-interactively.
I'm not sure what the behavior was before, because things "just worked". :-) When I first came in this morning, the script worked, but not after I did a apt-get update. I believe the packages updated were libc, fglrx-control, and some linux modles. libc is the most likely-looking candidate. |
Description: Ubuntu 8.04.1
Release: 8.04
When logging in to a machine through ssh (without -X or -Y), XAUTHORITY is not set; and when logging in non-interactively, XDG_SESSION_COOKIE is not set. This prevents programs started over an ssh session to connect to the X server of the machine on which it's running.
I use synergy to control my work desktop from my laptop (and so I have more screen real estate). I wrote the following script to automatically run the synergy server and client when I come in to work in the morning:
#!/bin/bash
killall synergys
ssh gdunlap@elijah "killall synergyc"
synergys
ssh -R 24800:localhost:24800 gdunlap@elijah "synergyc -f --name elijah localhost"
ssh gdunlap@elijah "killall synergyc"
killall synergys
It worked until I upgraded this morning, at which point it gave the following error:
DEBUG: CXWindowsScreen.cpp,840: XOpenDisplay(":0.0")
No protocol specified
WARNING: synergyc.cpp,337: cannot open secondary screen: unable to open screen
Digging a little deeper, I found that synergyc was trying to use ~/.Xauthority instead of /tmp/.gdm[...] as it should have, because XAUTHORITY was not being set when logging in over ssh.
Furthermore, I discovered that if I logged in using an interactive shell and set XAUTHORITY manually, then synergyc worked; but if I set XAUTHORITY script-wise in a non-interactive shell, it still didn't work. Further investigation revealed that in the interactive shell, XDG_SESSION_COOKIE is being set, but in a non-interactive shell, it's not being set. If logged in interactively and unset XDG_SESSION_COOKIE, it failed the same way as if I logged in non-interactively.
I'm not sure what the behavior was before, because things "just worked". :-) When I first came in this morning, the script worked, but not after I did a apt-get update. I believe the packages updated were libc, fglrx-control, and some linux modles. libc is the most likely-looking candidate. |
|
