-
Notifications
You must be signed in to change notification settings - Fork 0
Large user ID causes 600+ GB openedx image in Tutor #178
Comments
tl;dr: skip to the end. I was able to reproduce this issue on Linux with this minimal example: Dockerfile:
Completes in 1s:
340s and it's still running:
It's the "exporting layers" step which takes a very long time to complete, as you discovered yourself. This leads me to think that the bug may come from buildkit. So I attempted a build without buildkit:
And the build is now stuck on the On the other hand, this one-line
The maximum allowed user ID in ubuntu 22.04 is 60k:
but the build works find with
This is fascinating. Aaaaaaand here's a similar report: https://stackoverflow.com/questions/73351423/docker-build-hangs-when-adding-user-with-a-large-value-of-user-id-uid 🍾 The upstream issue: moby/moby#5419 (2014!) Aaaaaand the fix is to add Who wants to open a PR? |
I'd like to give it a try. |
Thanks Emad! |
On macOS, building the "openedx-dev" Docker image resulted in an image that required more than 600 GB of disk space. This was due to the `adduser` command which was called with a user ID of 2x10⁹ (on macOS only). This resulted in a very large /var/log/faillog file, hence the image size. Related upstream discussion: moby/moby#5419 Close openedx-unsupported/wg-developer-experience#178
On macOS, building the "openedx-dev" Docker image resulted in an image that required more than 600 GB of disk space. This was due to the `adduser` command which was called with a user ID of 2x10⁹ (on macOS only). This resulted in a very large /var/log/faillog file, hence the image size. Related upstream discussion: moby/moby#5419 Close openedx-unsupported/wg-developer-experience#178
Background
@rgraber 's openedx (and openedx-dev) images ended up ridiculously big and took an extremely long time to finish building. In particular, the layer created by the
useradd
command was accounting for the vast majority of the space.We investigated, and noticed that her host's user ID (
id -u
) is ~2.1 billion. This user ID is passed into the Tutor openedx Dockerfile asAPP_USER_ID
, and is then used in theuseradd
command to create the image'sapp
user. Manually passing a smallerAPP_USER_ID
returned the build time & image size to reasonable amounts.Note: Tutor purposefully uses the host's user ID as the image's app user ID in order to avoid annoying file-owner thrashing when working with bind-mounted directories.
Reproduction:
Tested on:
Workaround
On systems where the host's user ID is too big, it can be overriden as so:
Unfortunately, this may cause file permissions issues when bind-mounting dirs. Haven't tested yet.
Open questions
Tasks
The text was updated successfully, but these errors were encountered: