Install failing on Ubuntu (via standard curl command )

[psombe]

I'm attempting to install juliaup via the standard command curl -fsSL https://install.julialang.org | sh. However, the script fails with the following output.

info: downloading installer
curl: (23) Failure writing output to destination
juliaup: command failed: downloader https://julialang-s3.julialang.org/juliaup/bin/juliainstaller-1.8.16-x86_64-unknown-linux-musl /tmp/tmp.8mk7iXLQ50/juliainstaller x86_64-unknown-linux-musl

It is unable to detect that my laptop has GNU Lib C installed. My laptop details are listed below.

(core-py) psombe@psombe-x1:~/Downloads$ ldd /bin/ls
    linux-vdso.so.1 (0x00007ffe2e7d1000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f1ad0b26000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1ad0800000)
    libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f1ad0a8f000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1ad0b8d000)
(core-py) psombe@psombe-x1:~/Downloads$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.2 LTS
Release:    22.04
Codename:   jammy

[davidanthoff]

It is unable to detect that my laptop has GNU Lib C installed.

That shouldn't matter, we now always install the musl version of Juliaup.

To me this just looks like some download/permission problem? Do you get the same error if you try it again?

[psombe]

Yes. I get the same error.

[davidanthoff]

Can you download https://julialang-s3.julialang.org/juliaup/bin/juliainstaller-1.8.16-x86_64-unknown-linux-musl to a location in /tmp with curl? That seems to not work here..

[psombe]

I can download the file when I specify the file as chk.txt say. However, the script is mangling the output and failing to download. For example, I see a space in /tmp/tmp.8mk7iXLQ50/juliainstaller x86_64-unknown-linux-musl which maybe should not exist. I also don't see a --create-dirs option in the curl command.

[psombe]

Actually, you're right. I'm unable to download into /tmp with curl. Even with those flags enabled. I'm able to download to other locations though.

[davidanthoff]

Hm, so I don't know about Linux to really sort this out... Is there some other temporary folder we should try to use? @staticfloat any ideas?

[staticfloat]

@psombe what are the contents of your TMP, TEMP or TMPDIR environment variables? Do they point to /tmp?

[psombe]

All those variables are unset for me. I think this might be an issue with snap versus apt when installing curl.

[fingolfin]

Note that rustup suffers from the same problem: https://github.com/rust-lang/rustup/issues/2948

So what can be done about this issue? One option would be to just ignore it (following the logic: broken system tools can always happen, and are not our problem).

Of course it'd be nicer to do something more helpful the user. E.g. perhaps it is possible to somehow detect such a broken curl and then either

• print a helpful error pointing out a workaround;
• try to fallback to wget;
• try to fallback to a "supported" download directory (whatever that may be?)

Well, or just wait until rustup gets a workaround and then borrow it ;-). Arguably they are much bigger than we and if they can (for now) live without a fix for this, so can we...

[staticfloat]

try to fallback to a "supported" download directory (whatever that may be?)

It appears that the curl snap can write to home, so one possibility is to store the temporary file in the home directory. I'm thinking something like $XDG_STATE_HOME (I don't see any more temporary definitions in the XDG spec), defaulting to ~/.local/state. We would of course clean up the files after rustup is done, but that seems like a very safe bet for working around snapd confinement.

try to fallback to wget

This also seems reasonable, but if curl gets snapd confined, it's only a matter of time before wget does as well, so it's probably better to just fix the issues with curl.

[fingolfin]

Issue #450 is related.

As to solutions, my first thought was that one should have a function that tests if a given directory is (a) writeable, and (b) can contain executable files (e.g. by trying to create one with a trivial shell script or so and executing it). Next write a helper func that stands in for mktemp ; that help could first try mktemp, use the check function, and if that fails, fall back to e.g. $XDG_STATE_HOME.

An alternative location might be .julia/tmp or .julia/juliaup/tmp -- with the advantage that this could reduce the risk of files in there sticking around due to a failed install attempt (because cleaning out .julia resp. .julia/juliaup would get rid of it; plus we could also clean out that dir at the same time db updates are scanned for, or so... although a proper trap in the script should also ensure we delete the dir?

And then I thought, why bother with all the complexity of checks, and having the "special" code for non-standard tmp locations only executed rarely (and thus being undertested), and instead just embrace using custom location... e.g.

# create a temporary directory in the user's home directory -- this avoids
# issues with /tmp not being writable for curl (e.g. when it was installed
# via Ubuntu's snap) or not allowing the executable bit being set (e.g. as
# a security measure on certain shared machines).
mytmp="$(mktemp -d $HOME/.juliaup-tmp.XXXXXXXX)"
trap 'rm -rf -- "$mytmp"' EXIT

[fingolfin]

Apparently there are also systems where $HOME is read-only, see #252, so I guess one also should catch that, too (if it isn't already)

[colintbowers]

Just had this same issue on a fresh install of Ubuntu 24.04 LTS. For anyone reading this who just wants to get things working quickly, an easy workaround is to just sudo snap remove curl and then sudo apt-get install curl. This fixed things for me and confirms that the problem is in the snap install.