Issue 160676 in chromium: Second RDP session can't open a Chrome window if first session runs Chrome already

[chro...@googlecode.com]

Status: Untriaged
Owner: ----
CC: apps-tse...@chromium.org
Labels: Type-Bug Pri-2 Area-Internals Hotlist-Enterprise Enterprise

New issue 160676 by mik...@chromium.org: Second RDP session can't open a
Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

Version: 23.0.1271.64 m
OS: Windows server 2008

What steps will reproduce the problem?
1. Set up a Windows server 2008, allow multiple RDP sessions, create a
user1 account, install Chrome from .msi
Let me know if you need a test environment, I have a VM running to repro
this issue.
2. Connect to the server as user1 via RPD and start up Chrome
3. Connect to the server as user1 again via RDP and try to start Chrome

What is the expected output? What do you see instead?
I'd expect to open a new window within the existing running Chrome browser
process.

In practice it fails silently.

Logs:
37728:6100:3290977875:ERROR:process_singleton_win.cc(194)] Lock file can
not be created! Error code: 32
[37728:6100:3290977890:VERBOSE1:client_socket_pool_base.cc(65)] Setting
g_socket_reuse_policy_penalty_exponent = -1
[37728:6100:3290977890:VERBOSE1:pref_proxy_config_tracker_impl.cc(143)]
028A2DC0: set chrome proxy config service to 02890C00
[37728:6100:3290977890:VERBOSE1:pref_proxy_config_tracker_impl.cc(226)]
028A2DC0: Done pushing proxy to UpdateProxyConfig
[37728:6100:3290977890:ERROR:gpu_info_collector_win.cc(93)] Can't retrieve
a valid WinSAT assessment.
[37728:6100:3290977890:ERROR:chrome_browser_main.cc(1041)] Failed to create
a ProcessSingleton for your profile directory. This means that running
multiple instances would start multiple browser processes rather than
opening a new window in the existing process. Aborting now to avoid profile
corruption.

Logs indicates that Chrome wants to create a new browser process rather
than open a window in the existing one.

Original customer report:
https://productforums.google.com/forum/?fromgroups=#!topic/chrome/7HPUAR6zTFg

I tried a similar setup in Linux, using 'ssh -X' and the second connection
opened a new window without any problem.
Message in the terminal: "Created new window in existing browser session."

I guess this is the intended behavior and as the code is OS specific I
assume the issue is on Windows only.


Please use labels and text to provide additional information.

[chro...@googlecode.com]

Updates:
Owner: mnis...@chromium.org
Cc: cyr...@chromium.org

Comment #2 on issue 160676 by roy...@chromium.org: Second RDP session can't

open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

Mattias: would you know who can comment on this bug ? We were able to repro
this issue.

[chro...@googlecode.com]

Updates:
Owner: ---
Cc: pastarm...@chromium.org mnis...@chromium.org

Comment #3 on issue 160676 by mnis...@chromium.org: Second RDP session

can't open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

Adding Julian since he knows the RDP stuff.

I presume what happens is that you create a second RDP session that is
isolated from the first one somehow, i.e. Chrome fails to find the existing
instance and then hits the lockfile safeguard that we have put in
intentionally to avoid running multiple browser instances on the same user
data dir.

I'm not sure whether there's a "fix" for this, but I'll defer to Julian to
comment.

[chro...@googlecode.com]

Updates:
Owner: pastarm...@chromium.org
Cc: -pastarm...@chromium.org

Comment #4 on issue 160676 by pastarm...@chromium.org: Second RDP session

can't open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

It seems like what Mattias pointed that the RDP sessions are isolated so
that Chrome processes from the one can not communicate with those from the
other. I will be glad to get access to the VM where this was reproduced to
analyze the situation.

Can you please mail me with instructions how to get the access.

[chro...@googlecode.com]

Comment #5 on issue 160676 by mik...@chromium.org: Second RDP session can't

open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

Access has been granted.

[chro...@googlecode.com]

Updates:
Status: Started

Comment #6 on issue 160676 by pastarm...@chromium.org: Second RDP session

can't open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

The problem is exactly that the two RDP sessions do not share the desktop
although they are logged in with the same credentials. The desktop meaning
not the "Desktop" folder but the logical entity in windows where the
applications run. Therefore the instances running in both sessions can't
see each other and the first one locks the profile for exclusive use which
is critical to ensure no profile corruption can occur.

This problem has been discussed in the past and the best solution for this
problem is to modify the startup link of Chrome to make sure every logged
in user gets his own profile. this can be achieved using the
--user-data-dir flag (or UserDataDir GPO policy). For example using this
command line to start chrome will even guarantee that every client will
reach the very same profile every time he/she logs in from the same client
machine:

chrome.exe --user-data-dir=%LOCALAPPDATA%\Google\Chrome\%CLIENTNAME%

This will create unique folder for every user under the default profile
location for Chrome. Right now there is no way to specify the client name
variable in a policy therefore this particular example will work only as a
command line flag.

If those accounts should still share their configuration Chrome Sync can be
used to synchronize all settings in the different profiles.

Please tell me if this solution works for you and I will mark the issue as
closed.

[chro...@googlecode.com]

Comment #7 on issue 160676 by Westberg...@gmail.com: Second RDP session

can't open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

The solution worked for me, thank you very much!

[chro...@googlecode.com]

Comment #8 on issue 160676 by Westberg...@gmail.com: Second RDP session

can't open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

The solution worked for Google chrome,it created a folder with my computer
name that i am remote controlling with. But if i have a google chrome frame
where should i put the parameters then?

[chro...@googlecode.com]

Comment #9 on issue 160676 by pastarm...@chromium.org: Second RDP session

can't open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

For Chrome Frame there is a Windows Group Policy called GCFUserDataDir
which is the equivalent to UserDataDir fro Chrome Frame
(http://www.chromium.org/administrators/policy-list-3#GCFUserDataDir).
The issue there is that you can not use environment variables for security
reasons but only the predefined set of variables listed here
http://www.chromium.org/administrators/policy-list-3/user-data-directory-variables.
However I just created a bug (http://crbug.com/161247) to add
the %CLIENTNAME% to the list of properties accessible through a path
variable for policies. You can star this bug to know when this is ready.
Until then it might be impossible to specify different paths for chrome
frame running on the same user account.

[chro...@googlecode.com]

Updates:
Status: Fixed
Blockedon: chromium:161247

Comment #10 on issue 160676 by pastarm...@chromium.org: Second RDP session

can't open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

The ${client_name} variable has been added to the list of variables
supported in GPOs which will make it possible to implement the solution
proposed in comment #9 as a GPO. The change should become visible on the
stable channel in Chrome 25 and on canary in a few days.

[chro...@googlecode.com]

Comment #11 on issue 160676 by pastarm...@chromium.org: Second RDP session

can't open a Chrome window if first session runs Chrome already
http://code.google.com/p/chromium/issues/detail?id=160676

The documentation on chromium.org has been updated accordingly.

[chro...@googlecode.com]

Comment #14 on issue 160676 by jeff...@krs.ac.nz: Second RDP session can't

open a Chrome window if first session runs Chrome already

https://code.google.com/p/chromium/issues/detail?id=160676

Found this issue again with Multipoint server and the above solution does
not work as the station name remains the same, worked around it by using
--user-data-dir=%LOCALAPPDATA%\Google\Chrome\%SessionName% instead and item
level targeted shortcuts in GPO.

Would be great if the devs could add a ${SessionName} variable so that this
could be pushed out easily instead of giving users a different icon for
chrome in a different place.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #15 on issue 160676 by pasta...@chromium.org: Second RDP session

can't open a Chrome window if first session runs Chrome already
https://code.google.com/p/chromium/issues/detail?id=160676

Sounds like a reasonable request - filed a new bug to track that
https://code.google.com/p/chromium/issues/detail?id=416790 please star it
if you want to follow progress on that.

[chro...@googlecode.com]

Comment #16 on issue 160676 by pasta...@chromium.org: Second RDP session

can't open a Chrome window if first session runs Chrome already
https://code.google.com/p/chromium/issues/detail?id=160676

Just a heads up to the people tracking this bug - 416790 has been fixed so
it will appear in M41 if all goes good.