Make IsHostPortUsed() handle ports bound by foreign UIDs.

Make IsHostPortUsed() handle ports bound by foreign UIDs.

lsof -np is not able (permission denied when running as non-root to be exact)
to retrieve file descriptor information for processes running under a different
UID. This can make IsHostPortUsed() return false when the provided port is
actually used.
Trying to connect to a port rather than binding it should not introduce any
side-effect on the system that could affect next runs as the TODO suggested. It
is also always sane not to depend on an external process (lsof) output format.

BUG=229685
R=bulach@chromium.org

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

[Philippe, 2013-05-07 08:34:32]

FYI, this is also needed to fix the release bot downstream which is always
failing when trying to bind port 10200 (bound by a process with a foreign UID I
believe).

[Philippe, 2013-05-07 08:34:32]

FYI, this is also needed to fix the release bot downstream which is always
failing when trying to bind port 10200 (bound by a process with a foreign UID I
believe).

[bulach, 2013-05-07 08:36:48]

lgtm

[Philippe, 2013-05-07 09:15:25]

On 2013/05/07 08:36:48, bulach wrote:
> lgtm

Thanks Marcus! FYI, I re-ran the android_dbg bot. For some reason the
android_dbg_triggered_tests bot wasn't spawned.

[commit-bot: I haz the power, 2013-05-07 09:32:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/pliard@chromium.org/14567016/1

[Philippe, 2013-05-07 10:07:02]

On 2013/05/07 09:32:25, I haz the power (commit-bot) wrote:
> CQ is trying da patch. Follow status at
> https://chromium-status.appspot.com/cq/pliard%40chromium.org/14567016/1

I will run the tests locally and dcommit this. The testing bot has a very long
queue since it was offline for some time: see
http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...

[Philippe, 2013-05-07 12:16:35]

Committed patchset #1 manually as r198683 (presubmit successful).

[boliu, 2013-05-07 16:18:13]

If no one has notified you yet...this seem to be breaking upstream tester. It
seems to be knocking devices offline permanently.

[pliard, 2013-05-07 16:19:35]

I did notice the failures but cannot see how it could be related. Do you?


On Tue, May 7, 2013 at 6:18 PM, <boliu@chromium.org> wrote:

> If no one has notified you yet...this seem to be breaking upstream tester.
> It
> seems to be knocking devices offline permanently.
>
>
https://codereview.chromium.**org/14567016/<https://codereview.chromium.org/1...
>

[pliard, 2013-05-07 16:20:00]

We can try to revert this and see what happens.


On Tue, May 7, 2013 at 6:19 PM, Philippe Liard <pliard@google.com> wrote:

> I did notice the failures but cannot see how it could be related. Do you?
>
>
> On Tue, May 7, 2013 at 6:18 PM, <boliu@chromium.org> wrote:
>
>> If no one has notified you yet...this seem to be breaking upstream
>> tester. It
>> seems to be knocking devices offline permanently.
>>
>>
https://codereview.chromium.**org/14567016/<https://codereview.chromium.org/1...
>>
>
>

[pliard, 2013-05-07 16:26:15]

I landed https://codereview.chromium.org/15021006/ as a revert.


On Tue, May 7, 2013 at 6:19 PM, Philippe Liard <pliard@google.com> wrote:

> We can try to revert this and see what happens.
>
>
> On Tue, May 7, 2013 at 6:19 PM, Philippe Liard <pliard@google.com> wrote:
>
>> I did notice the failures but cannot see how it could be related. Do you?
>>
>>
>> On Tue, May 7, 2013 at 6:18 PM, <boliu@chromium.org> wrote:
>>
>>> If no one has notified you yet...this seem to be breaking upstream
>>> tester. It
>>> seems to be knocking devices offline permanently.
>>>
>>>
https://codereview.chromium.**org/14567016/<https://codereview.chromium.org/1...
>>>
>>
>>
>

[Philippe, 2013-05-07 16:35:26]

On 2013/05/07 16:26:15, pliard wrote:
> I landed https://codereview.chromium.org/15021006/ as a revert.
> 
> 
> On Tue, May 7, 2013 at 6:19 PM, Philippe Liard <mailto:pliard@google.com>
wrote:
> 
> > We can try to revert this and see what happens.
> >
> >
> > On Tue, May 7, 2013 at 6:19 PM, Philippe Liard <mailto:pliard@google.com>
wrote:
> >
> >> I did notice the failures but cannot see how it could be related. Do you?
> >>
> >>
> >> On Tue, May 7, 2013 at 6:18 PM, <mailto:boliu@chromium.org> wrote:
> >>
> >>> If no one has notified you yet...this seem to be breaking upstream
> >>> tester. It
> >>> seems to be knocking devices offline permanently.
> >>>
> >>>
>
https://codereview.chromium.**org/14567016/%3Chttps://codereview.chromium.org...>
> >>>
> >>
> >>
> >

Armand/Isaac do you guys see how this change could make the devices go offline?
Could this interfere with reboot on disconnect?

[navabi, 2013-05-08 01:33:39]

On 2013/05/07 16:35:26, Philippe wrote:
> On 2013/05/07 16:26:15, pliard wrote:
> > I landed https://codereview.chromium.org/15021006/ as a revert.
> > 
> > 
> > On Tue, May 7, 2013 at 6:19 PM, Philippe Liard <mailto:pliard@google.com>
> wrote:
> > 
> > > We can try to revert this and see what happens.
> > >
> > >
> > > On Tue, May 7, 2013 at 6:19 PM, Philippe Liard <mailto:pliard@google.com>
> wrote:
> > >
> > >> I did notice the failures but cannot see how it could be related. Do you?
> > >>
> > >>
> > >> On Tue, May 7, 2013 at 6:18 PM, <mailto:boliu@chromium.org> wrote:
> > >>
> > >>> If no one has notified you yet...this seem to be breaking upstream
> > >>> tester. It
> > >>> seems to be knocking devices offline permanently.
> > >>>
> > >>>
> >
>
https://codereview.chromium.**org/14567016/%253Chttps://codereview.chromium.o...>
> > >>>
> > >>
> > >>
> > >
> 
> Armand/Isaac do you guys see how this change could make the devices go
offline?
> Could this interfere with reboot on disconnect?

Devices going offline is a tricky beast. I do not see how this particular change
could make the devices go offline, but that does seem to what is going on (we'll
know for sure now that Siva has rebooted the devices and the change has been
reverted).

Note that the devices are on IMM76D. That has known to go offline, but did not
do so on the upstream Android Tests bot. We saw it on the downstream yakju perf
bots. bulach, do you know anything that the downstream perf bots do, that are
like this change. We may be able to identify the source of this device failure
now that we have more information.

Questions:

Do the downstream perf bots do something similar that could have been causing
this problem when those devices were on IMM76D?

Would devices go offline with this change on a different Android build (i.e. a
JB build)?

Also, the Android team may be interested in what we are finding out.