Stop remoting host on install.

Stop remoting host on install.

It will be restarted automatically by the Python script. Note that this CL does
not handle changes to the Python script itself, nor to Xvfb.

BUG=139919
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=152095

[Jamie, 2012-08-16 23:14:40]

ptal

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

http://codereview.chromium.org/10857046/diff/1/remoting/host/installer/linux/...
File remoting/host/installer/linux/debian/postinst (right):

http://codereview.chromium.org/10857046/diff/1/remoting/host/installer/linux/...
remoting/host/installer/linux/debian/postinst:8: killall -q -s USR1
remoting_me2me_host || true
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:12]

ptal

http://codereview.chromium.org/10857046/diff/1/remoting/host/installer/linux/...
File remoting/host/installer/linux/debian/postinst (right):

http://codereview.chromium.org/10857046/diff/1/remoting/host/installer/linux/...
remoting/host/installer/linux/debian/postinst:8: killall -q -s USR1
remoting_me2me_host || true
On 2012/08/17 00:14:11, Lambros wrote:
> 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.

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]

http://codereview.chromium.org/10857046/diff/1/remoting/host/installer/linux/...
File remoting/host/installer/linux/debian/postinst (right):

http://codereview.chromium.org/10857046/diff/1/remoting/host/installer/linux/...
remoting/host/installer/linux/debian/postinst:8: killall -q -s USR1
remoting_me2me_host || true
On 2012/08/17 00:14:11, Lambros wrote:
> 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.

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.

[Lambros, 2012-08-17 00:32:06]

LGTM
I agree it would be nice to handle SIGTERM to do explicit client disconnection
before shutting down.  That's more work (fix sighup_listener_mac to handle
SIGTERM as well, and use it on Linux), and I don't think it's worth holding up
this CL for it.

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

http://codereview.chromium.org/10857046/diff/1/remoting/host/installer/linux/...
File remoting/host/installer/linux/debian/postinst (right):

http://codereview.chromium.org/10857046/diff/1/remoting/host/installer/linux/...
remoting/host/installer/linux/debian/postinst:8: killall -q -s USR1
remoting_me2me_host || true
On 2012/08/17 00:23:59, sergeyu wrote:
> On 2012/08/17 00:14:11, Lambros wrote:
> > 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.
> 
> This will only restart the host. If the daemon code (the python script) is
> updated too, shouldn't we restart it too?

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.

> 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.

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).