Stop remoting host on install.

remoting/host/installer/linux/debian/postinst

Index: remoting/host/installer/linux/debian/postinst
diff --git a/remoting/host/installer/linux/debian/postinst b/remoting/host/installer/linux/debian/postinst
new file mode 100755
index 0000000000000000000000000000000000000000..31e6b310c0098e0192e42046fe6b4b9524a8b997
--- /dev/null
+++ b/remoting/host/installer/linux/debian/postinst
@@ -0,0 +1,12 @@
+#!/bin/bash
+
+set -e
+
+case $1 in
+  "configure")
+    echo "Shutting down remoting hosts (they will restart automatically)..."
+    killall -q -s USR1 remoting_me2me_host || true

[Lambros, 2012/08/17 00:14:11]

Are you sure about USR1, doesn't that just tell it to reload its config?  Just a
plain SIGTERM seems to be the right thing here.

[Jamie, 2012/08/17 00:21:13]

I think you're thinking of SIGHUP. The reason I went with SIGUSR1 was so that we
could handle in the host in a future version and perhaps close the connection
more cleanly with an error message. However, the only value in sending the
signal before we have code to process it is that downgrades would work
correctly, which I don't think we care about. I'll change it to SIGTERM.

[Sergey Ulanov, 2012/08/17 00:23:59]

This will only restart the host. If the daemon code (the python script) is
updated too, shouldn't we restart it too?
Also if we use SIGTERM to kill the process it might be a good idea to handle it
explicitly in the host, e.g. to shutdown all current sessions cleanly.

[Jamie, 2012/08/17 01:21:28]

That's right. I'm planning a follow-up CL to handle the more complex case of an
updated script or Xvfb. The problem there is that simply restarting the affected
process will kill the user's desktop and might result in data loss. I wanted to
handle this simple case first.
I'm not averse to doing that, but as Lambros says, I think it can be a follow-up
(especially as it conflicts with your signal handling CL).

+    ;;
+esac
+
+#DEBHELPER#