os image downloads onto /tmp and might run out of space

[imrehg]

Same issue with resin quickstart and resin device init as well. os image is downloaded onto /tmp, but that's not really a good to assume to work. The local disk usually has enough space for people, but /tmp might be small. Just run the quickstart command on a server, where it had ~8GB disk space free, but still couldn't download (/tmp is only 500MB)

? Select an application Virtuality (intel-nuc)
Getting device operating system for intel-nuc
ENOSPC: ENOSPC: no space left on device, write

If you need help, don't hesitate in contacting us at:

  GitHub: https://github.com/resin-io/resin-cli/issues/new
  Gitter: https://gitter.im/resin-io/chat

greg@XDRF002:~/resincli$ df -h
Filesystem            Size  Used Avail Use% Mounted on
udev                  493M     0  493M   0% /dev
tmpfs                 101M  3.3M   97M   4% /run
/dev/mapper/vg0-root   39G   28G  8.7G  77% /
tmpfs                 501M     0  501M   0% /dev/shm
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                 501M     0  501M   0% /sys/fs/cgroup
tmpfs                 501M  501M     0 100% /tmp
/dev/vda2             179M   81M   89M  48% /boot
cgmfs                 100K     0  100K   0% /run/cgmanager/fs
tmpfs                 101M     0  101M   0% /run/user/1000

Should probably download to a temporary file in the directory it's been called from?

[jviotti]

Hey there!

OS image is downloaded onto /tmp, but that's not really a good to assume to work.

We download to $HOME/.resin/cache by default, but we fallback to
/tmp if there is no home directory, or you explicitly configured it
otherwise (based on your df -h output, I believe you don't have
$HOME).

I guess we could download to the current directory, however that means
that multiple runs of quickstart on different directories will cause
the cache to not be re-used, defeating its purpose and probably giving
more space issues.

I suggest you explicitly configure a different data directory in your
device, using either the RESINRC_DATA_DIRECTORY environment variable,
or a per-user, or per-project .resinrc.yml; which will cause the
images to be downloaded at $RESINRC_DATA_DIRECTORY/cache instead.

See https://github.com/resin-io/resin-settings-client for details.

On Thu, Sep 01, 2016 at 01:17:36AM -0700, Gergely Imreh wrote:

OS image is downloaded onto /tmp, but that's not really a good to assume to work. The local disk usually has enough space for people, but /tmp might be small. Just run the quickstart command on a server, where it had ~8GB disk space free, but still couldn't download (/tmp is only 500MB)

? Select an application Virtuality (intel-nuc)
Getting device operating system for intel-nuc
ENOSPC: ENOSPC: no space left on device, write

If you need help, don't hesitate in contacting us at:

  GitHub: https://github.com/resin-io/resin-cli/issues/new
  Gitter: https://gitter.im/resin-io/chat

greg@XDRF002:~/resincli$ df -h
Filesystem            Size  Used Avail Use% Mounted on
udev                  493M     0  493M   0% /dev
tmpfs                 101M  3.3M   97M   4% /run
/dev/mapper/vg0-root   39G   28G  8.7G  77% /
tmpfs                 501M     0  501M   0% /dev/shm
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                 501M     0  501M   0% /sys/fs/cgroup
tmpfs                 501M  501M     0 100% /tmp
/dev/vda2             179M   81M   89M  48% /boot
cgmfs                 100K     0  100K   0% /run/cgmanager/fs
tmpfs                 101M     0  101M   0% /run/user/1000

Should probably download to a temporary file in the directory it's been called from?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#391

Juan Cruz Viotti
Software Engineer

[imrehg]

I'm most certainly have a home, and the same /tmp behaviour also exists on my laptop too.

greg@XDRF002:~$ echo $HOME
/home/greg

I understand the quickstart issue, and makes sense, though I think people would expect, that if things happen the same directory where they are, they know it's reusable, and if they are in another directory, they might not want to reuse it anyways. But, the current default is definitely defensible.

The setting being configurable is great, though this is not at all obvious setting. I guess you have some reason not to use command line flags?

[jviotti]

I'm most certainly have a home, and the same /tmp behaviour also
exists on my laptop too.

Hm, then there is definitely something going on. Are you running this on
a Raspberry Pi? Running Raspbian, or Resin?

This is the module we use to determine the default location:
https://github.com/sindresorhus/home-or-tmp. Can you check what it
returns on your system?

I understand the quickstart issue, and makes sense, though I think
people would expect, that if things happen the same directory where
they are, they know it's reusable, and if they are in another
directory, they might not want to reuse it anyways. But, the current
default is definitely defensible.

Would logging something, saying that an image is being cached at a
certain path help?

The setting being configurable is great, though this is not at all
obvious setting. I guess you have some reason not to use command line
flags?

This is promoted on the Resin CLI README, but maybe we should make it
even clearer somehow?

Regarding command line flags, the environment variable support is
basically convenient syntax sugar over the configuration files mechanism
for when using the Resin CLI in an actual Resin application.

Supporting the same thing as command line options is another syntax
sugar than could be easily done as well.

On Thu, Sep 01, 2016 at 07:30:43AM -0700, Gergely Imreh wrote:

I'm most certainly have a home, and the same /tmp behaviour also exists on my laptop too.

greg@XDRF002:~$ echo $HOME
/home/greg

I understand the quickstart issue, and makes sense, though I think people would expect, that if things happen the same directory where they are, they know it's reusable, and if they are in another directory, they might not want to reuse it anyways. But, the current default is definitely defensible.

The setting being configurable is great, though this is not at all obvious setting. I guess you have some reason not to use command line flags?

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#391 (comment)

Juan Cruz Viotti
Software Engineer

[imrehg]

1) file download location

Checked, home-or-tmp gives the correct home directory in both cases I have. One is an ArchLinux laptop, the other is an Ubuntu headless server.

Question, is resin-cli really using home-or-tmp? All I could find is this section in the code, which does not seem to make use of that at all, but the tmp module to generate a filename: https://github.com/resin-io/resin-cli/blob/870ce974e0b20b0a17e11a0acd0c43e208b8245b/lib/actions/device.coffee#L360-L362

It is supported by the fact, that following your explanation, the download directory should be $HOME/.resin/cache or/tmp/.resin/cache, but it actually downloads to the /tmp folder directly (no subdirs, as expected based on the details)

2) env var docs

The rest of it is indeed sort of docs issue. I see now the things you refer in README. The problem is, that you can install and use resin-cli while never actually seeing the README file (command line install and use), and it has such a deep and broad documentation within resin help, that one expects to find everything there. So it is a case of mismatched expectations. You add everything that's needed, really, while the user misses them (PEBCAK?).

It might be just that the help (or help --verbose only) has a section of "Environment Variables` (or some other way include), to mentions the two env vars that are apparently used by the cli, and then it would be discoverable. This would be a nice minimal amount of change, probably. :)

[jviotti]

Question, is resin-cli really using home-or-tmp? All I could find is
this section in the code, which does not seem to make use of that at
all, but the tmp module to generate a filename:
https://github.com/resin-io/resin-cli/blob/870ce974e0b20b0a17e11a0acd0c43e208b8245b/lib/actions/device.coffee#L360-L362

Ah, I see, amazing catch. We should definitely be re-using
$HOME/.resin (or any configured directory) for this. Definitely my
mistake. I'll send a PR soon.

It might be just that the help (or help --verbose only) has a
section of "Environment Variables` (or some other way include), to
mentions the two env vars that are apparently used by the cli, and
then it would be discoverable. This would be a nice minimal amount of
change, probably. :)

I agree, lets put it on help --verbose.

On Fri, Sep 02, 2016 at 03:17:50AM -0700, Gergely Imreh wrote:

1) file download location

Checked, home-or-tmp gives the correct home directory in both cases I have. One is an ArchLinux laptop, the other is an Ubuntu headless server.

Question, is resin-cli really using home-or-tmp? All I could find is this section in the code, which does not seem to make use of that at all, but the tmp module to generate a filename: https://github.com/resin-io/resin-cli/blob/870ce974e0b20b0a17e11a0acd0c43e208b8245b/lib/actions/device.coffee#L360-L362

It is supported by the fact, that following your explanation, the download directory should be $HOME/.resin/cache or/tmp/.resin/cache, but it actually downloads to the /tmp folder directly (no subdirs, as expected based on the details)

2) env var docs

The rest of it is indeed sort of docs issue. I see now the things you refer in README. The problem is, that you can install and use resin-cli while never actually seeing the README file (command line install and use), and it has such a deep and broad documentation within resin help, that one expects to find everything there. So it is a case of mismatched expectations. You add everything that's needed, really, while the user misses them (PEBCAK?).

It might be just that the help (or help --verbose only) has a section of "Environment Variables` (or some other way include), to mentions the two env vars that are apparently used by the cli, and then it would be discoverable. This would be a nice minimal amount of change, probably. :)

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#391 (comment)

Juan Cruz Viotti
Software Engineer

[balena-ci]

[nazrhom] This issue has attached support thread https://jel.ly.fish/#/support-thread~f7a760ba-0f0e-4903-a259-4dd23bcef617