Bug 258126 - lang/rust fails to build, fills /tmp and exits, rather than writing to work directory
Summary: lang/rust fails to build, fills /tmp and exits, rather than writing to work d...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: FreeBSD Rust Team
Depends on:
Reported: 2021-08-28 23:36 UTC by paulbeard
Modified: 2021-11-10 13:09 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (rust)


Note You need to log in before you can comment on or make changes to this bug.
Description paulbeard 2021-08-28 23:36:34 UTC
lang/rust will not build with less that 225M of free space in /tmp. Why it writes to /tmp instead of its own word directory is an unrevealed mystery. That partition has 13G of free space which I would hope to be sufficient. Can rust's build process either a. test for available space or b. write to the port work directory? I doubt many have /usr/ports mounted with that 225M of free space.
Comment 1 Tobias Kortkamp freebsd_committer 2021-09-01 19:14:13 UTC
Ports other than lang/rust will likely be affected by a space limited
/tmp. Since rustc and others respect TMPDIR and the framework exports it
via MAKE_ENV and CONFIGURE_ENV too, I'd just set TMPDIR in make.conf to
somewhere with enough space.
Comment 2 Graham Perrin freebsd_committer 2021-09-05 17:17:52 UTC
(In reply to Tobias Kortkamp from comment #1)

> Ports other than lang/rust …

Please, do I read that correctly? 

I mean, what about lang/rust itself?


Sidetracking: <https://forums.FreeBSD.org/threads/8877/post-530289> was not a failure to build, however killings occurred (out of swap space) during the packaging phase of rust during a run of poudriere. From my postscript there: 

% df -h /tmp
Filesystem    Size    Used   Avail Capacity  Mounted on
tmpfs         4.7G    1.6G    3.1G    33%    /tmp
Comment 3 paulbeard 2021-09-05 18:05:36 UTC
Semantics. The build process fails to complete, if you insist.

4.7G for tmp is quite a bit of space. Not everyone has that. Not everyone lays out their filesystem to accommodate /tmp as part of the build/staging process, since /usr is my expectation. Seems like a POLA violation but I can simply lock these ports until they can be installed as packages. I still build from source. I find pkg to be full of surprises and I don't care for those. In what world is this an upgrade?

Installed packages to be UPGRADED:
        py38-openssl: 20.0.1 -> 19.1.0,1

Especially when the next entry is an actual downgrade (higher version number to lower).

Installed packages to be DOWNGRADED:
        protobuf: 3.17.3,1 -> 3.14.0,1
Comment 4 commit-hook freebsd_committer 2021-09-06 19:30:05 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=b1670e2c3d42a2aeacff843ef0ccea21c0929d03

commit b1670e2c3d42a2aeacff843ef0ccea21c0929d03
Author:     Tobias Kortkamp <tobik@FreeBSD.org>
AuthorDate: 2021-09-06 17:16:38 +0000
Commit:     Tobias Kortkamp <tobik@FreeBSD.org>
CommitDate: 2021-09-06 19:28:28 +0000

    lang/rust*: Mk/Uses/cargo.mk: Move TMPDIR to WRKDIR

    rustc stashes intermediary files in TMPDIR (default /tmp) which
    might cause issues for users that for some reason space limit their
    /tmp.  WRKDIR should have plenty of space.

    Other ports that use rustc might be affected too, but set it only
    in USES=cargo and lang/rust* ports for now.

    PR:             258126
    With hat:       rust

 Mk/Uses/cargo.mk             | 8 ++++++++
 lang/rust-bootstrap/Makefile | 5 +++++
 lang/rust/Makefile           | 6 ++++++
 3 files changed, 19 insertions(+)
Comment 5 paulbeard 2021-09-09 14:00:21 UTC
Per the advice in an earlier reply, I set TMPDIR to be /usr/ports and the build/staging processes filled that filesystem as well…15G of free space, pushing it to 102% and breaking other processes that expected to find space. 

I don't know how to define "plenty of space" but 15G seems fairly capacious. I suppose there is no way to check to see if TMPDIR is filling up at various checkpoints or, as suggested earlier, test to see it TMPDIR has enough free space before beginning. 

Locking it and installing/updating only as a pkg from now on.