New issue
Advanced search Search tips

Issue 780908 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

Upgrading Chromoting on Linux starts a new desktop

Project Member Reported by jamiewa...@chromium.org, Nov 2 2017

Issue description

We've had a couple of reports of users losing their desktops after the most recent upgrade. It seems that two copies of the desktop are running:

ps -ef | grep '[c]hrome-remote-desktop '
user  4650  4536  0 Oct31 ?        00:00:00 /usr/bin/python2 /opt/google/chrome-remote-desktop/chrome-remote-desktop --config=... --start --child-process
user 32523  7759  0 Oct20 ?        00:00:00 /usr/bin/python /opt/google/chrome-remote-desktop/chrome-remote-desktop --start --config=...

Killing the newer desktop results in the original desktop coming back online next time it heartbeats. It looks like the installer doesn't handle the case of upgrading from an old (not user-session based) running host.

 
As a workaround `/opt/google/chrome-remote-desktop/chrome-remote-desktop --stop` will stop the new host, allowing connection to the old one after it next heartbeats.

Rebooting should bring everything back to normal.
Cc: jamiewa...@chromium.org lambroslambrou@chromium.org
 Issue 782327  has been merged into this issue.
Project Member

Comment 3 by bugdroid1@chromium.org, Nov 30 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/775d46a0194974400e80b7c730a693533844b472

commit 775d46a0194974400e80b7c730a693533844b472
Author: Erik Jensen <rkjnsn@chromium.org>
Date: Thu Nov 30 00:13:13 2017

Enable detection of older instances.

The changes to run all CRD sessions through the user-session PAM wrapper
mean there are often two instances of the python script at startup: the
parent script that runs the user-session wrapper and the child script
that is run by the user-session wrapper. In order to prevent the child
instance from detecting the parent instance as an already-running
session, the detection logic was changed to only find instances running
with the --child-process flag. This worked great for detecting existing
sessions from the same version, but it unfortunately resulted in
sessions started by a previous version being ignored as they looked like
a parent instance.

This change fixes the problem by adding an additional check in the parent
instance. While the child instance still necessarily only checks for
other child instances, the parent instance will now check for any other
instances (whether an older version, a parent, or a child) before
starting the child through the user-session wrapper. Further, if actions
such as --stop and --reload detect an instance without the
--child-process flag and none with it, they'll assume it is a legacy
instance instead of ignoring it. Finally, to allow the detection changes
to function on upgrade, the init script is updated to launch a parent
instance version of the script instead of running user-session directly.

Bug: 780908
Change-Id: I497bacdfc8328e964ddca7c649d65201c60a5cf7
Reviewed-on: https://chromium-review.googlesource.com/791822
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Erik Jensen <rkjnsn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520320}
[modify] https://crrev.com/775d46a0194974400e80b7c730a693533844b472/remoting/host/installer/linux/debian/chrome-remote-desktop.init
[modify] https://crrev.com/775d46a0194974400e80b7c730a693533844b472/remoting/host/linux/linux_me2me_host.py

Sign in to add a comment