systemd defaulting to tmpfs for /tmp causes enospc errors
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Auto Package Testing |
New
|
Undecided
|
Unassigned | ||
autopkgtest (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Committed
|
Undecided
|
Unassigned | ||
Noble |
Fix Committed
|
Undecided
|
Unassigned | ||
systemd (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
[Impact]
systemd 256 changes behavior and makes /tmp a tmpfs by default. This causes some
problems with packages for which the sources weight more than the tmpfs size,
and this case often happen on the testbed because they usually don't have a lot
of RAM by default (see test case below for a concrete example).
[Test case]
autopkgtest-
autopkgtest --shell gzip -- qemu ./autopkgtest-
Jump to the shell when prompted and verify the following:
mount -t tmpfs | grep /tmp # this returns nothing, /tmp is not a tmpfs anymore
stat /etc/systemd/
Since the default RAM given to the QEMU VM is 2GB and the libreoffice source
take more than 4GB, this should have no trouble running in a "No space left on
device" error.
[Fix]
https:/
This was release in autopkgtest 5.36, currently in the process of being SRU'd to
Jammy and Noble in bug #2071609.
[Regression potential]
The current SRU has a lot of unrelated changes. While this increases the
chances of regression, this also come with a broader test suite, increasing test
coverage, and so regressions should only happen in corner-cases, hopefully less
important as the current lack of this /tmp bug fix.
[Original bug report]
Debian systemd now mounts a tmpfs on /tmp by default; relevant d/changelog entry:
systemd (256~rc3-3) unstable; urgency=medium
* Make /tmp/ a tmpfs by default. Restore the upstream default and make
/tmp/ a tmpfs. Can be overridden with: touch
/etc/
Ubuntu is aligning to this, however this means that available space under /tmp is limited to the half of the available ram. That is sometimes not enough to unpack source trees in /tmp, see for example [1].
We need to to decide how to deal with this. Possibilities I can think about:
1. Disable the tmpfs tmp.mount, as suggested in the d/changelog entry. To be done in setup-testbed. Good: easy. Bad: deviates from the Ubuntu defaults, requires rebuilding the images.
2. Make autopkgtest use /var/tmp. Good: we stick to the defaults: Bad: requires non trivial changes in src:autopkgtest, which makes assumptions on stuff being in /tmp, on /tmp being cleared on reboots, ...
This under the assumption that the switch to a tmpfs has been discussed, and we want it in Ubuntu.
tags: | added: update-excuse |
Changed in autopkgtest (Ubuntu): | |
status: | New → Fix Committed |
description: | updated |
Changed in systemd (Ubuntu): | |
status: | Triaged → Won't Fix |
description: | updated |
tags: |
added: verification-done verification-done-jammy verification-done-noble removed: verification-needed verification-needed-jammy verification-needed-noble |
I think option (2) is the probably the "best" fix. Another alternative I can think of is shipping a tmp.mount drop-in on the autopkgtest environment to change the size to something better. E.g.,
# /etc/systemd/ system/ tmp.mount. d/size. conf size=<param>
[Mount]
Options=
where <param> could be a percentage of RAM (e.g. 75%%), or an explicit size (e.g. 4GB). But then again, these defaults are intentionally easy to override. If the autopkgtest environment wants to do something different, I don't think it's the end of the world, and masking tmp.mount as a first step is fine.
> This under the assumption that the switch to a tmpfs has been discussed, and we want it in Ubuntu.
This was discussed in the foundations team, and the initial consensus was to not deviate from upstream and Debian.