Use fixed socket name instead of SecureSocketWithKey

Use fixed socket name instead of SecureSocketWithKey

Root-case of the issue is that GTMCopyLaunchdExports does
not work on 10.10, so we can't resolve socket name
generated for SecureSocketWithKey.

Socket provided by SecureSocketWithKey was used for:
1. Communicate with service from browser.
This solved by using predefined socket name known to browser
and service. Socket just needs to be unique for user_data_dir.
Similar approach is used on Linux.

2. Start temporarily .plist file during service registration.
No we can start just using RunAtLoad.

BUG=428369, 466644
Committed: https://crrev.com/e4502e84ca012ce83ac4aa43583f4f7998e5f3e1
Cr-Commit-Position: refs/heads/master@{#320735}

[Vitaly Buka (NO REVIEWS), 2015-03-05 19:40:49]

vitalybuka@chromium.org changed reviewers:
+ jacobmarble@chromium.org, rsesek@chromium.org

[Vitaly Buka (NO REVIEWS), 2015-03-05 19:41:01]

PTAL

[Jacob Marble, 2015-03-05 20:30:49]

lgtm

[Vitaly Buka (NO REVIEWS), 2015-03-05 22:28:28]

vitalybuka@chromium.org changed reviewers:
+ thakis@chromium.org

[Robert Sesek, 2015-03-05 22:34:02]

I'm not sure this is quite right. While the GTMCopyExports does not work,
because it relies on undocumented APIs, there's a new API in 10.10 called
launch_activate_socket(), which does this:

"""
 * Retrieves the file descriptors for sockets specified in the process'
 * launchd.plist(5).
 * @param name
 * The name of the socket entry in the service's Sockets dictionary.
 *
 * @param fds
 * On return, this parameter will be populated with an array of file
 * descriptors. One socket can have many descriptors associated with it
 * depending on the characteristics of the network interfaces on the system.
 * The descriptors in this array are the results of calling getaddrinfo(3) with
 * the parameters described in launchd.plist(5).
"""

Prior to 10.10, I'm not sure why this wasn't using launch_msg() to do a similar
thing to check the job into launchd and to return the sockets dictionary.

https://codereview.chromium.org/982883003/diff/20001/chrome/browser/service_p...
File chrome/browser/service_process/service_process_control_mac.mm (right):

https://codereview.chromium.org/982883003/diff/20001/chrome/browser/service_p...
chrome/browser/service_process/service_process_control_mac.mm:9: #include
"base/mac/foundation_util.h"  // operator<< for CFErrorRef
These comments quickly become stale and aren't terribly common in Chrome, so I'd
omit this.

https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
chrome/common/service_process_util_mac.mm:91: // Fallback to /tmp if $TMPDIR is
too long.
When would this happen?

https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
chrome/common/service_process_util_mac.mm:234: [NSNumber numberWithBool:YES], @
LAUNCH_JOBKEY_RUNATLOAD,
You can use @YES

https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
chrome/common/service_process_util_mac.mm:234: [NSNumber numberWithBool:YES], @
LAUNCH_JOBKEY_RUNATLOAD,
This is changing the RunAtLoad to be from only when for_auto_launch is true to
unconditional. Why that change?

[Vitaly Buka (NO REVIEWS), 2015-03-05 22:55:06]

On 2015/03/05 22:34:02, Robert Sesek wrote:
> I'm not sure this is quite right. While the GTMCopyExports does not work,
> because it relies on undocumented APIs, there's a new API in 10.10 called
> launch_activate_socket(), which does this:
> 
> """
>  * Retrieves the file descriptors for sockets specified in the process'
>  * launchd.plist(5).
>  * @param name
>  * The name of the socket entry in the service's Sockets dictionary.
>  *
>  * @param fds
>  * On return, this parameter will be populated with an array of file
>  * descriptors. One socket can have many descriptors associated with it
>  * depending on the characteristics of the network interfaces on the system.
>  * The descriptors in this array are the results of calling getaddrinfo(3)
with
>  * the parameters described in launchd.plist(5).
> """
> 
> Prior to 10.10, I'm not sure why this wasn't using launch_msg() to do a
similar
> thing to check the job into launchd and to return the sockets dictionary.

Actually I am not sure why it didn't use fixed socket name from beginning.
This is simpler and does what we need.

> 
>
https://codereview.chromium.org/982883003/diff/20001/chrome/browser/service_p...
> File chrome/browser/service_process/service_process_control_mac.mm (right):
> 
>
https://codereview.chromium.org/982883003/diff/20001/chrome/browser/service_p...
> chrome/browser/service_process/service_process_control_mac.mm:9: #include
> "base/mac/foundation_util.h"  // operator<< for CFErrorRef
> These comments quickly become stale and aren't terribly common in Chrome, so
I'd
> omit this.
> 
>
https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
> File chrome/common/service_process_util_mac.mm (right):
> 
>
https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
> chrome/common/service_process_util_mac.mm:91: // Fallback to /tmp if $TMPDIR
is
> too long.
> When would this happen?
> 
>
https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
> chrome/common/service_process_util_mac.mm:234: [NSNumber numberWithBool:YES],
@
> LAUNCH_JOBKEY_RUNATLOAD,
> You can use @YES
> 
>
https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
> chrome/common/service_process_util_mac.mm:234: [NSNumber numberWithBool:YES],
@
> LAUNCH_JOBKEY_RUNATLOAD,
> This is changing the RunAtLoad to be from only when for_auto_launch is true to
> unconditional. Why that change?

[Vitaly Buka (NO REVIEWS), 2015-03-05 23:22:13]

https://codereview.chromium.org/982883003/diff/20001/chrome/browser/service_p...
File chrome/browser/service_process/service_process_control_mac.mm (right):

https://codereview.chromium.org/982883003/diff/20001/chrome/browser/service_p...
chrome/browser/service_process/service_process_control_mac.mm:9: #include
"base/mac/foundation_util.h"  // operator<< for CFErrorRef
On 2015/03/05 22:34:02, Robert Sesek wrote:
> These comments quickly become stale and aren't terribly common in Chrome, so
I'd
> omit this.

sure.
my concern is that it compiles with or without include, but output without
include is just pointer

https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
chrome/common/service_process_util_mac.mm:91: // Fallback to /tmp if $TMPDIR is
too long.
On 2015/03/05 22:34:02, Robert Sesek wrote:
> When would this happen?

kMaxSocketNameLength is 104

name generated on my machine is about 94
e.g
/var/folders/00/0dpyh000h01000cxqpysvccm001pvt/T/758B1E1062CD965F78D92951B1E9E136D28155CB.srv

not sure if I can rely that it's constant

https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
chrome/common/service_process_util_mac.mm:234: [NSNumber numberWithBool:YES], @
LAUNCH_JOBKEY_RUNATLOAD,
On 2015/03/05 22:34:02, Robert Sesek wrote:
> You can use @YES

Done.

https://codereview.chromium.org/982883003/diff/20001/chrome/common/service_pr...
chrome/common/service_process_util_mac.mm:234: [NSNumber numberWithBool:YES], @
LAUNCH_JOBKEY_RUNATLOAD,
On 2015/03/05 22:34:02, Robert Sesek wrote:
> This is changing the RunAtLoad to be from only when for_auto_launch is true to
> unconditional. Why that change?

for_auto_launch means that this file is going to be permanently stored 
~/Library/LaunchAgents to be used after reboot

without for_auto_launch it's just plist in temp directory. and we are going to
run it once to start service setup. it's not important a problem that it has
RunAtLoad, because this file will not be loaded after reboot, only by us in
ServiceProcessControl::Launcher::DoRun()

[Vitaly Buka (NO REVIEWS), 2015-03-05 23:43:19]

Actually I found on-demand that this cl breaks. If service terminated browser
may trigger start by accessing socket.

Still I'd like to use fixed name and to put that name into SockPathName 
instead of SecureSocketWithKey, otherwise we will have to solve same problem
again

[Robert Sesek, 2015-03-05 23:44:53]

On 2015/03/05 23:43:19, Vitaly Buka wrote:
> Actually I found on-demand that this cl breaks. If service terminated browser
> may trigger start by accessing socket.
> 
> Still I'd like to use fixed name and to put that name into SockPathName 
> instead of SecureSocketWithKey, otherwise we will have to solve same problem
> again

OK. I don't think it's too difficult a problem to solve (though it is easier to
use a named socket).

[Vitaly Buka (NO REVIEWS), 2015-03-06 01:51:09]

https://codereview.chromium.org/982883003/diff/60001/chrome/common/service_pr...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/60001/chrome/common/service_pr...
chrome/common/service_process_util_mac.mm:185: if
(!GetServiceProcessData(&version, &pid) || pid == -1) {
this check was the reason why on demand didn't work for me

[Vitaly Buka (NO REVIEWS), 2015-03-11 18:54:42]

On 2015/03/06 01:51:09, Vitaly Buka wrote:
>
https://codereview.chromium.org/982883003/diff/60001/chrome/common/service_pr...
> File chrome/common/service_process_util_mac.mm (right):
> 
>
https://codereview.chromium.org/982883003/diff/60001/chrome/common/service_pr...
> chrome/common/service_process_util_mac.mm:185: if
> (!GetServiceProcessData(&version, &pid) || pid == -1) {
> this check was the reason why on demand didn't work for me

Robert?

[Robert Sesek, 2015-03-11 22:20:29]

Sorry for the delay; review load has been exceptionally high this week. I'm
still not sure this is the best approach for using launchd sockets in general,
but other ones would require a larger restructuring, so LGTM.

https://codereview.chromium.org/982883003/diff/140001/chrome/common/service_p...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/140001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:95: // Fallback to /tmp if $TMPDIR is
too long.
I'd suggest using an UMA histogram to track how often this happens.

[Vitaly Buka (NO REVIEWS), 2015-03-12 16:14:51]

vitalybuka@chromium.org changed reviewers:
+ asvitkine@chromium.org, isherman@chromium.org, thestig@chromium.org

[Vitaly Buka (NO REVIEWS), 2015-03-12 16:14:51]

asvitkine or isherman for metrics
thestig for chrome/

[Vitaly Buka (NO REVIEWS), 2015-03-12 16:15:15]

> I'd suggest using an UMA histogram to track how often this happens.

done

[Alexei Svitkine (slow), 2015-03-12 17:35:03]

https://codereview.chromium.org/982883003/diff/200001/chrome/common/service_p...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/200001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:95: socket_name.value().size(), 75,
124, 50);
Wait, does this even compile?

I think UMA_HISTOGRAM_ENUMERATION() takes exactly 3 params - the name of the
histogram, the value being logged and the number of buckets.

In this case, you're not even logging an enumeration. This should probably be an
UMA_HISTOGRAM_COUNTS() - which gives you an exponential bucket range
distribution.

[Vitaly Buka (NO REVIEWS), 2015-03-12 18:06:55]

Patchset #12 (id:220001) has been deleted

[Lei Zhang, 2015-03-12 19:23:49]

lgtm with some nits

https://codereview.chromium.org/982883003/diff/240001/chrome/browser/service_...
File chrome/browser/service_process/service_process_control_mac.mm (right):

https://codereview.chromium.org/982883003/diff/240001/chrome/browser/service_...
chrome/browser/service_process/service_process_control_mac.mm:9: #include
"base/mac/foundation_util.h"
not needed?

https://codereview.chromium.org/982883003/diff/240001/chrome/common/service_p...
File chrome/common/service_process_util.h (right):

https://codereview.chromium.org/982883003/diff/240001/chrome/common/service_p...
chrome/common/service_process_util.h:43: #endif  // OS_MACOSX
This should be !defined(OS_MACOSX)

https://codereview.chromium.org/982883003/diff/240001/chrome/common/service_p...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/240001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:246: NSString* soket_name =
typo

[Vitaly Buka (NO REVIEWS), 2015-03-12 19:44:14]

https://codereview.chromium.org/982883003/diff/200001/chrome/common/service_p...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/200001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:95: socket_name.value().size(), 75,
124, 50);
On 2015/03/12 17:35:03, Alexei Svitkine (slow) wrote:
> Wait, does this even compile?
> 
> I think UMA_HISTOGRAM_ENUMERATION() takes exactly 3 params - the name of the
> histogram, the value being logged and the number of buckets.
> 
> In this case, you're not even logging an enumeration. This should probably be
an
> UMA_HISTOGRAM_COUNTS() - which gives you an exponential bucket range
> distribution.

Done.

https://codereview.chromium.org/982883003/diff/240001/chrome/browser/service_...
File chrome/browser/service_process/service_process_control_mac.mm (right):

https://codereview.chromium.org/982883003/diff/240001/chrome/browser/service_...
chrome/browser/service_process/service_process_control_mac.mm:9: #include
"base/mac/foundation_util.h"
On 2015/03/12 19:23:48, Lei Zhang wrote:
> not needed?

:-)

https://codereview.chromium.org/982883003/diff/20001/chrome/browser/service_p...

Maybe this kind of errors can be detected with clang?

https://codereview.chromium.org/982883003/diff/240001/chrome/common/service_p...
File chrome/common/service_process_util.h (right):

https://codereview.chromium.org/982883003/diff/240001/chrome/common/service_p...
chrome/common/service_process_util.h:43: #endif  // OS_MACOSX
On 2015/03/12 19:23:48, Lei Zhang wrote:
> This should be !defined(OS_MACOSX)

Done.

https://codereview.chromium.org/982883003/diff/240001/chrome/common/service_p...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/240001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:246: NSString* soket_name =
On 2015/03/12 19:23:48, Lei Zhang wrote:
> typo

Done.

[Nico, 2015-03-12 19:48:45]

https://codereview.chromium.org/982883003/diff/240001/chrome/browser/service_...
File chrome/browser/service_process/service_process_control_mac.mm (right):

https://codereview.chromium.org/982883003/diff/240001/chrome/browser/service_...
chrome/browser/service_process/service_process_control_mac.mm:9: #include
"base/mac/foundation_util.h"
On 2015/03/12 19:44:13, Vitaly Buka wrote:
> On 2015/03/12 19:23:48, Lei Zhang wrote:
> > not needed?
> 
> :-)
> 
>
https://codereview.chromium.org/982883003/diff/20001/chrome/browser/service_p...
> 
> Maybe this kind of errors can be detected with clang?

Probably not; the ScopedCFRef probably has an operator bool, so that's then
printed. Maybe ScopedCFRef should have something like
https://codereview.chromium.org/837873002/

[Alexei Svitkine (slow), 2015-03-13 13:04:00]

https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:94:
LOCAL_HISTOGRAM_CUSTOM_COUNTS("CloudPrint.ServiceProcessSocketLength",
Just double checking - you don't want the histogram to show up on the UMA
dashboard - only in chrome://histograms? (Which is fine if that's you're
intention - just want to make sure if it is.)

If you do want it to go to UMA, you need to use the UMA_ prefix rather than the
LOCAL_ prefix.

https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:95: socket_name.value().size(), 75,
124, 50);
It's not clear to me why you're specifying a custom range of 75-124.

There may be a good reason - but if so it should have a comment about it.

Otherwise, I suggest using one of the built in macros - e.g.
UMA_HISTOGRAM_COUNTS_10000.

https://codereview.chromium.org/982883003/diff/260001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/982883003/diff/260001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:3041: +    Temporarily histograme with
size of IPC sockets in default location. See
What's the size of IPC sockets? Do you mean the count?

If this is really temporary, please add a TODO at the histogram call to remove
it once the bug is resolved.

[Vitaly Buka (NO REVIEWS), 2015-03-13 19:02:30]

https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:94:
LOCAL_HISTOGRAM_CUSTOM_COUNTS("CloudPrint.ServiceProcessSocketLength",
Ugh, I totally screwed up copy-pasting macros here.
UMA_HISTOGRAM_CUSTOM_COUNTS was my goal from beginning.

On 2015/03/13 13:04:00, Alexei Svitkine (slow) wrote:
> Just double checking - you don't want the histogram to show up on the UMA
> dashboard - only in chrome://histograms? (Which is fine if that's you're
> intention - just want to make sure if it is.)
> 
> If you do want it to go to UMA, you need to use the UMA_ prefix rather than
the
> LOCAL_ prefix.

https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:95: socket_name.value().size(), 75,
124, 50);
Primary goal is to know how often file path in DIR_TEMP
is >= IPC::kMaxSocketNameLength (104). I expect never or almost never.

Boolean would be enough. But with this histogram we will have additional data if
my assumption is wrong.

COUNTS_10000 buckets around 104 are large

I guess we can something like UMA_HISTOGRAM_COUNTS_100(... size() - 75), but I
don't see advantage over current approach.

On 2015/03/13 13:04:00, Alexei Svitkine (slow) wrote:
> It's not clear to me why you're specifying a custom range of 75-124.
> 
> There may be a good reason - but if so it should have a comment about it.
> 
> Otherwise, I suggest using one of the built in macros - e.g.
> UMA_HISTOGRAM_COUNTS_10000.

[Alexei Svitkine (slow), 2015-03-14 23:23:06]

https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
File chrome/common/service_process_util_mac.mm (right):

https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
chrome/common/service_process_util_mac.mm:95: socket_name.value().size(), 75,
124, 50);
On 2015/03/13 19:02:30, Vitaly Buka wrote:
> Primary goal is to know how often file path in DIR_TEMP
> is >= IPC::kMaxSocketNameLength (104). I expect never or almost never.
> 
> Boolean would be enough. But with this histogram we will have additional data
if
> my assumption is wrong.
> 
> COUNTS_10000 buckets around 104 are large
> 
> I guess we can something like UMA_HISTOGRAM_COUNTS_100(... size() - 75), but I
> don't see advantage over current approach.
> 
> On 2015/03/13 13:04:00, Alexei Svitkine (slow) wrote:
> > It's not clear to me why you're specifying a custom range of 75-124.
> > 
> > There may be a good reason - but if so it should have a comment about it.
> > 
> > Otherwise, I suggest using one of the built in macros - e.g.
> > UMA_HISTOGRAM_COUNTS_10000.
> 

Thanks for clarifying.

I think it's wasteful to have 50 buckets in the range 75 to 124. Why do you need
such precision? e.g. what would a value of 89 vs. 90 tell you?

Also, why is 124 the max? How do you know that there won't be more than 124
entries? Using more buckets and a large maximum will ensure you won't get
surprised by the data. (Of course, unless I don't know something that guarantees
there won't be over 124).

Also, is this histogram really temporary? If so, please add a TODO above it to
remove it when the investigation has concluded with a linked crbug.

https://codereview.chromium.org/982883003/diff/280001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/982883003/diff/280001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:3041: +    Temporarily histograme with
size of IPC sockets in default location. See
Nit: histogram

[Vitaly Buka (NO REVIEWS), 2015-03-16 07:06:04]

On 2015/03/14 23:23:06, Alexei Svitkine (slow) wrote:
>
https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
> File chrome/common/service_process_util_mac.mm (right):
> 
>
https://codereview.chromium.org/982883003/diff/260001/chrome/common/service_p...
> chrome/common/service_process_util_mac.mm:95: socket_name.value().size(), 75,
> 124, 50);
> On 2015/03/13 19:02:30, Vitaly Buka wrote:
> > Primary goal is to know how often file path in DIR_TEMP
> > is >= IPC::kMaxSocketNameLength (104). I expect never or almost never.
> > 
> > Boolean would be enough. But with this histogram we will have additional
data
> if
> > my assumption is wrong.
> > 
> > COUNTS_10000 buckets around 104 are large
> > 
> > I guess we can something like UMA_HISTOGRAM_COUNTS_100(... size() - 75), but
I
> > don't see advantage over current approach.
> > 
> > On 2015/03/13 13:04:00, Alexei Svitkine (slow) wrote:
> > > It's not clear to me why you're specifying a custom range of 75-124.
> > > 
> > > There may be a good reason - but if so it should have a comment about it.
> > > 
> > > Otherwise, I suggest using one of the built in macros - e.g.
> > > UMA_HISTOGRAM_COUNTS_10000.
> > 
> 
> Thanks for clarifying.
> 
> I think it's wasteful to have 50 buckets in the range 75 to 124. Why do you
need
> such precision? e.g. what would a value of 89 vs. 90 tell you?

I just pick 50 because its default number for many histograms. Maybe 25 is also
enough.
What do you consider as not wast-full?

Please take into account that this histogram will be reported by a fraction of
OSX installs which runs GCP connector.
And it's temporarily. So I don't see why we should spend time looking for
optimal values.

> 
> Also, why is 124 the max? How do you know that there won't be more than 124
> entries? Using more buckets and a large maximum will ensure you won't get
> surprised by the data. (Of course, unless I don't know something that
guarantees
> there won't be over 124).

it's just common 50 buckets around 100. 

Conclusions could be following:
1. all values below 104: we don't need fallback
2. most values below 104, few at 104-100, and nothing above: and adjust
algorithm to have smaller names, and remove fallback
3. most values below 104, few at 104-100, and few above 110: and adjust
algorithm to have smaller names, and keep fallback
4. a lot of values about 110: we need a different algorithm for socket name
generation

so we can optimize histogram parameters, but as I wrote before, I don't see
value in doing that.

> 
> Also, is this histogram really temporary? If so, please add a TODO above it to
> remove it when the investigation has concluded with a linked crbug.

Done. Yes it's temporarily.

> 
>
https://codereview.chromium.org/982883003/diff/280001/tools/metrics/histogram...
> File tools/metrics/histograms/histograms.xml (right):
> 
>
https://codereview.chromium.org/982883003/diff/280001/tools/metrics/histogram...
> tools/metrics/histograms/histograms.xml:3041: +    Temporarily histograme with
> size of IPC sockets in default location. See
> Nit: histogram

Done.

[Vitaly Buka (NO REVIEWS), 2015-03-16 07:07:16]

https://codereview.chromium.org/982883003/diff/280001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/982883003/diff/280001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:3041: +    Temporarily histograme with
size of IPC sockets in default location. See
On 2015/03/14 23:23:05, Alexei Svitkine (slow) wrote:
> Nit: histogram

Done.

[Alexei Svitkine (slow), 2015-03-16 15:33:51]

lgtm

[Vitaly Buka (NO REVIEWS), 2015-03-16 16:22:37]

The CQ bit was checked by vitalybuka@chromium.org

[Vitaly Buka (NO REVIEWS), 2015-03-16 16:22:38]

The patchset sent to the CQ was uploaded after l-g-t-m from
jacobmarble@chromium.org, rsesek@chromium.org, thestig@chromium.org
Link to the patchset: https://codereview.chromium.org/982883003/#ps320001
(title: "Mon Mar 16 00:37:12 PDT 2015")

[commit-bot: I haz the power, 2015-03-16 16:22:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/982883003/320001

[commit-bot: I haz the power, 2015-03-16 16:26:34]

Committed patchset #16 (id:320001)

[commit-bot: I haz the power, 2015-03-16 16:27:18]

Patchset 16 (id:??) landed as
https://crrev.com/e4502e84ca012ce83ac4aa43583f4f7998e5f3e1
Cr-Commit-Position: refs/heads/master@{#320735}