Issue metadata
Sign in to add a comment
|
Waiting for minijail to start in arc-networkd.conf always times out (and doesn't seem to matter)
Reported by
nathanb@lenovo-chrome.com,
Feb 9 2017
|
||||||||||||||||||||
Issue description
Platform: 9260.0.2017_02_07_1323 developer-build ultima
Steps to reproduce the problem:
* Go to settings
* Turn off the play store (and confirm)
* Reboot
* Go to settings
* Turn on the play store
* Check the log -- you will note that the loop completed all 50 iterations with no exit
What is the expected behavior?
Minijail starts before 50 iterations
What went wrong?
It did not
Chrome version: 58.0.3001.0 Channel: n/a
ChromeOS Version: 58.0.3001.0
Inside arc-networkd.conf is the following code:
# allow a couple of seconds for minijail to start (we measured 1.3s once)
for i in `seq 1 50`; do
if [ -f "${CONTAINER_PATH}/root/dev/.booting" ]; then
break
fi
sleep 0.1
done
The first time ARC starts up, it seems like this always times out.
[nathan@nathanb-build ~/tmp/logs/11e] cat arc-network.log | grep sleep | wc -l
50
I have not noticed any brokenness as a result of this timeout. I checked three different machines (two different platforms) and they all behave like this. However, I also checked on a Pixel 2 running ChromeOS (rather than a ChromiumOS build) on R57 instead of R58 and this issue did not occur.
I don't know if that means the behavior is a regression in R58 or if it's a quirk of ChromiumOS versus ChromeOS, but it might be a place to start.
,
Feb 9 2017
,
Feb 10 2017
> The first time ARC starts up, it seems like this always times out. That's odd, because the file is created right in the main() function in system/core/init/init.cpp. Is there some other (slow) operation that precedes minijail starting up Android's init process? The other possibility is that the file is deleted (via Android's init.rc) before this upstart script notices. > I have not noticed any brokenness as a result of this timeout. arc-networkd is needed for IPv6 support and multicast forwarding. If it isn't running, Android apps won't be able to discover e.g. Chromecast or Sonos devices on the LAN.
,
Feb 10 2017
Just to ensure it's not a ChromeOS vs ChromiumOS thing, I downloaded R58-9269.0.0 from the partner site and booted it. I see the same behavior. While I was doing this, though, I realized: I'm usually USB booting. I wondered if this behavior was only when booting from USB, so I installed the exact same image, booted from internal flash, and still observed the issue. So it's not just a USB-boot problem. It doesn't smell like a timing issue either because tt happens every single time and because tt happens on fast and slow machines equally consistently.
,
Feb 10 2017
Last I checked, Android shouldn't start at all if you're booting from USB. Not sure why there would be an issue when booting from internal flash, though.
,
Feb 10 2017
I can definitely get Android to start when booting from USB, but we can set that aside because it turned out to be a red herring. If you want to follow up offline about it though you're welcome to shoot me an email.
,
Feb 12 2018
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by vapier@chromium.org
, Feb 9 2017