container-image with uv-######.lock file in /tmp

[poggenpower]

The problem

containers comes with a .lock file from uv in /tmp. /tmp should be empty.

What version of Home Assistant Core has the issue?

container from 2024.10.4 to 2025.1.0

What was the last working version of Home Assistant Core?

N/A

What type of installation are you running?

Home Assistant Container

Integration causing the issue

N/A

Link to integration documentation on our website

No response

Diagnostics information

Check the image by:

containerid=$(docker create ghcr.io/home-assistant/home-assistant:2025.1.0)
docker export "${containerid}" | tar -t tmp/

this will show something like:

tmp/
tmp/uv-1b696e695b7c17a7.lock

This lock file doesn't cause directly an issue, but lock files should be removed if not required anymore, this may cause other issues in the future. UV should not leave back a lock-file if running successful.
And it already causes issues for users running the container as non-root as this file is owned by root. I know this is unsupported, but just hint for those many users doing so.

Example YAML snippet

N/A

Anything in the logs that might be useful for us?

No response

Additional information

Workaround if you run in an issue with the lock file. Mount an empty dir as /tmp into the container.

[edenhaus]

I had a chat with @konstin, where he explained that when using --system uv will write the lock file to /tmp as they don't have a venv to place it in. The lock file is required to avoid issues on parallel runs to avoid corruption.

One possible workaround would be to mount /tmp to tmpfs on each RUN command, where uv is used, but this could easily missed, and therefore, a more generic solution would be appropriate.

Will create an issue directly on uv to get feedback on it from the maintainers Not for now as it's common to not clean up files in /tmp, even HA does not clean it up

[poggenpower]

I had a chat with @konstin, where he explained that when using --system uv will write the lock file to /tmp as they don't have a venv to place it in. The lock file is required to avoid issues on parallel runs to avoid corruption.

AFAIK this lock file is only placed while uv is running. Leaving it back seems to be an indicator that something get wrong.

What's about putting a command in the docker file to clean up /tmp/ as a workaround?

[edenhaus]

AFAIK this lock file is only placed while uv is running. Leaving it back seems to be an indicator that something get wrong.

That's not true. The program decides how to use its own lock file, and uv decided to keep it.

After doing some additional tests, the lock file will be recreated if dependencies are installed, e.g., adding a custom component.

What's about putting a command in the docker file to clean up /tmp/ as a workaround?

I don't see any benefit to adding this, as the lock file will be recreated, and we have no issues currently. As the lock file is empty, it's not saving any space.
If we really don't want to add the file to any layer, we would need to prevent it from adding to any layer and not delete it on the last one.

Nevertheless, the hassfest image uses uv only during build and therefore, we could remove it there