[SOLVED] Memory-hog installations (in this case, of docker-compose): Why, and what to do about it?

Help
1

EDIT 2: I think I figured out the problem. It can’t find Spotify, so each rebuild fails.

It would be cool if the system emailed me whenever one of those automatic rebuilds failed. Has anyone got that set up?

EDIT 1: Looking at the nixos-rebuild output I see that nixos-rebuild is in fact downloading lots of stuff that’s clearly not a dependency for docker-compose, such as Chrome, Spotify, Plasma. So I guess I should change my question to: Is autoUpgrade not working, or is this enormous quantity of downloads to be expected from any rebuild, even after little time has elapsed since the last one?

Before installing docker-compose, df -h . showed 30 GB free. Now it’s at 24 GB and still falling. And I’ve already got Docker installed! Why is docker-compose such a big install?

Often when I install something I’m worried that my hard disk will be exhausted and my computer will crash. Does NixOS have some kind of safety mechanism against that kind of thing? (E.g. “if memory falls below 2GB during an install, abort, collect garbage, and print a message explaining what happened”.)

2

The way I’m installing docker-compose, by the way, is by adding it to my packages.nix and rebuilding, not via nix-env. Could it be that the rebuild is causing NixOS to install lots of new stuff independent of Docker?

My configuration has the following:

  system.autoUpgrade.enable = true;
  # system.autoUpgrade.allowReboot = true;

That is, while it doesn’t reboot automtaically, it does rebuild automatically every now and then. That leads me to expect that there’s not a lot for it to download right now outside of what docker-compose requires.

3

Marked as solved, but there are a few things you can do to minimize the impact/occurrence of these problems :slight_smile:

I assume you mean disk storage rather than memory.

The simplest way to solve that is to move the nix store to a separate partition. That way your update will fail with out of disk, but your system will be unaffected otherwise, so you can stop worrying about random crashes.

I’d also suggest turning on automatic garbage collection if you auto-update, since that will help make sure auto-update failure is uncommon :slight_smile: Some of the other optimizations suggested in that wiki entry are helpful too.

To send warning emails, you’d probably want to override the OnFailure setting of the auto update systemd unit and make it invoke a one-shot email sending unit. The documentation for that lives here (no anchor, search for OnFailure=).

1 Like