Single App Kiosk mode local data is lost after 3 months
Reported by
paoe...@gmail.com,
Apr 30 2018
|
||||
Issue descriptionChrome Version: Google Chrome 64.0.3283.190 Chrome OS Version: Platform 10176.76.0 Chrome OS Platform: Chromebit CS10 Steps To Reproduce: (1) Set up Chrome OS for Single App Kiosk mode (manually as a non-managed device) (2) Set Kiosk (plugin id: afhcomalholahplbjhnmahkoekoijban) as the kiosk app to be used (3) Wait ~90 days Expected Result: Kiosk config should be retained and normal operation continue. Actual Result: Kiosk config data has been lost and initial Kiosk config screen is displayed on boot. Reproducibility: This has now happened to ~50 devices we have installed at customer deployments since December, the rest are quite likely to follow once they reach 3 months of operation. Further info: Full steps used to originally configure devices: https://pastebin.com/bUzNedv7 Original report on Kiosk bug tracker: https://discuss.kiosk.cook.company/t/devices-are-losing-their-kiosk-configs-overnight/406 -- this yielded no results and looking at the plugin source code it seems unlikely it is responsible for this behavior. After the device has failed, re-entering kiosk configurations and saving them resumes normal operation, but our guess is likely only for the next 3 months. After the first couple of batches of shipped devices failed, we took the precaution of removing daily restarts from new installations. We also removed the daily restart from the configs of some installed devices that had not yet failed. Our best guess had been related to https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/cryptohome/cryptohome.cc#57 and https://chromium.googlesource.com/chromiumos/platform2/+/master/cryptohome/service.cc#100 with the initial idea being that there might be a chance the automatically created kiosk user's activity timestamp might never get updated with a daily restart configured. However, now according to the most recent reports it seems that the settings have been lost even on a device where we changed to "no reboots" a week before the 3 month mark. To clarify, this happened 3 months from initial installation. So it seems our initial guess might have been down the wrong path, or the kiosk user timestamps never gets updated for some other reason... We have retained a few of the failed devices if you have requests on something we can check. We tried to change to Developer Mode on one of the devices so we could browse the user home folders and logs but this wipes the device. Is there a better way to do this? As we have used these in a lot of installations and need to use something for ongoing ones on a weekly basis, this matter is pretty urgent to us.
,
May 11 2018
,
Aug 14
It seems the real factor is not time, but hard drive space. Over 90 days the relatively small (16GB) hard drive of the Chromebit fills up. This apparently triggers cleanup, which ends up removing kiosk user config. We were able to get on this track since we also have some older Windows based kiosk devices (not using Kiosk plugin but plain Chrome in kiosk mode). They started slowing down after a year and we found the 64GB hard drives to be full, with 50GB worth of BrowserMetrics data in Chrome's cache folders. There seems to be very little clear info online about why this happens and how much of it is related to the OS or Chrome itself, other than similar reports of the BrowserMetrics folders growing huge. We have now followed kiosk device hard drive space on installed Chromebit devices and seen this same pattern happen. The hard drives are filling up slowly but consistently and once almost completely full, kiosk user data seems to be wiped and there is ample space on the drive again. If we try to put the device in developer mode to check the contents of the hard drive of an installed ChromeOS device we face the same problem as before when debugging this issue -- the hard drive is wiped. If we keep running the device in developer mode from the start but otherwise with the same config, the hard drive does not seem to fill up at all. Unless this is just another red herring, our best guess at the moment would be that the problem is something like a combination of: - Our somewhat uncommon WebGL page triggering more internal diagnostics events that fill up the drive and/or the data not getting sent and cleaned due to some condition - Hitting a slight misdesign regarding aggressive hard drive cleanup and treating the kiosk user as a non-prioritized account
,
Jan 11
,
Jan 15
|
||||
►
Sign in to add a comment |
||||
Comment 1 by dtapu...@chromium.org
, Apr 30 2018