boltblog

How to prevent ssh -X from hanging on exit when dbus is used

Programs like virt-manager and gedit commonly use dbus. Dbus running will prevent a clean exit of ssh -X, making it hang on exit until you press ctrl+c or kill dbus manually.
To avoid having to kill dbus manually, let's kill it automatically

Now, normally if I want to run virt-manager (or anything else graphical) on a remote machine with X forwarding, I'd use a command like

ssh -X root@remote-server virt-manager

Instead, I want to use dbus' ability to output sh-compatible commands to set invironment variables and kill the PID I get from that before exiting, like so:

ssh -X root@remote-server 'eval $(dbus-launch --close-stderr --sh-syntax); virt-manager --no-fork; kill -TERM $DBUS_SESSION_BUS_PID'

Problem solved!  The remote shell (bash) now starts dbus manually instead of letting virt-manager do it, waits for virt-manager to exit (--no-fork), then kills dbus and exits.

SSH in a while loop – stdin problems

When SSH is used with a line like "while read ....", the while loop will only run once.
This can be seen by running this simple example:

$ seq 1 10 | while read line; do ssh remotehostname "echo x${line}x"; done
x1x

You might expect this to connect to the host with the name "remotehostname" 10 times, and each time print one of the numbers in the sequence from 1 to 10. This will, however, not be the case. The result is a single line, saying "1".

Where did the rest of the numbers go? To the SSH process.
By default, SSH runs off with the stdin file descriptor, preventing "read" from reading anything else from it. You can see this by trying the following example:

$ seq 1 10 | while read line; do ssh remotehostname "echo x${line}x; cat -"; done
x1x
2
3
4
5
6
7
8
9
10

Now all the numbers were printed, but they were all in a single ssh connection. As you can see, only the number "1" got the X'es on both sides, indicating it was printed by the "echo" instruction. The rest of the numbers come from "cat -", which basically takes whatever comes in on SSH's stdin, and dumps it to the stdout (the screen, in this case). So that's where they went!

Now, how do you remedy this?

Answer: SSH's -n switch. From the manual:
-n Redirects stdin from /dev/null (actually, prevents reading from stdin). This must be used when ssh is run in the background. A common trick is to use this to run X11 programs on a remote machine. For example, ssh -n shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically forwarded over an encrypted channel. The ssh program will be put in the background. (This does not work if ssh needs to ask for a password or passphrase; see also the -f option.)

So let's try that with -n, shall we?

$ seq 1 10 | while read line; do ssh -n remotehostname "echo x${line}x; cat -"; done
x1x
x2x
x3x
x4x
x5x
x6x
x7x
x8x
x9x
x10x

There. 10 SSH connections opened, 1 number printed each time. A total waste of time, but a rather simple example to follow

GCC stray X in program

Problem:
IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn/pi.c:1: error: stray ‘\357’ in program

This is caused by "invalid" characters in the code, specifically I encountered this while trying to compile the Intel EMGD driver for my EEEPC's graphics card.

Thanks to the helpful folks over here, there's a solution:
cd IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn
cat -v pi.c | awk '{if(NR>1) print $0}' > tmp # make strange characters on first visible and remove
mv tmp pi.c
That makes the invalid characters visible and removes them.
In this case, it leaves some partial, garbage comments behind, so the file still wont compile.
To resolve this, I opened the file in vim, and quickly searched for and removed the faulty comments (and some I didn't have to remove).
Remember to answer "no" to the question of re-extracting the tarball each time you retry building this.
Attached is the original driver file, and my modified copy of pi.c

Result:
"Completed EMGD Installation"

Lin_EMGD_1_6_RC_1922
modified pi.c