Hacker News Reader

Comment by millstone | Hacker News Reader

I'm intrigued by the "atomic upgrades and rollbacks" claim. Let's say that deploying a package requires placing two files somewhere, e.g. vmlinuz and initrd. How can this be done atomically?

View on HN

The handwavy answer is, each install (even later versions of the same package) gets installed into a unique directory. There is no /bin or /usr/bin.

bit more info here: https://nixos.org/nixos/about.html

Literally, there is no /bin or /usr/bin? So most shebang scripts won't run at all? That is indeed a radical departure.

Sorta buried in that link

"A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store."

So you get bash :)

There's a /bin/sh because libc needs it, but we're going to remove that one too in the future somehow.

But /usr/bin/env is in nixos to make it easy for people to run scripts. But packages never use /usr/bin/env, it's just there for convenience.

Ok, if env is supplied then scripts can at least use it to locate Python, etc. which makes a lot of sense. The text made it sound like these directories did not exist at all.

So what does PATH look like?

If you as a user wish to have a normal-ish Unix commandline experience, you "install" into your personal nix profile various nix packages. I put "install" in quotes because there are two steps:

1) Adding the package to the nix store, /nix/store/checksum-coreutils-version

2) Linking this into your nix profile: ~/.nix-profile/bin/ls will be a symlink to /nix/...coreutils.../bin/ls

Your PATH is then ~/.nix-profile/bin.

Now if you're packaging a shell script, and it calls coreutils and rsync, then inside the build scripts for that package, you might do something like this to wrap the script with the required PATH:

  wrapProgram myScript --prefix PATH ${coreutils}/bin:${rsync}/bin

That way, the script will still work even if the user running it does not have coreutils or rsync in PATH. If will also work if the user does have rsync-1.0, but the script requires rsync-2.0, because the custom PATH being used by the script includes the required rsync.

In this situation, both coreutils and rsync would be present in /nix/store, even if no user has linked them into their profile.

They use atomic file operations involving symlinks. Moving a new symlink to overwrite an old symlink is one way to atomically switch out a directory for another. I don't know if there is any special handling of the kernel packages, but that's basically how it works as far as I know.

I am not sure if this is the same, but Redhat's Project Atomic does similar thing using rpm-ostree

http://www.projectatomic.io/

It's a different approach. That's basically an implementation using ostree. Nix is way different than that. Neither is better in my opinion, but I use Nix happily.

The package manager could just flock() a specific file before making any changes.

From svn's red book:

By atomic transaction, we mean simply this: either all of the changes happen in the repository, or none of them happens. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.

Does Nix mean the same thing? Is it atomic in the face of program or system crashes?

Yes. In many cases, switching to the new version of the package is nothing more than rewriting a symlink. Sometimes it's more involved, like restarting a service. Either way, the cut over happens after building the new package has completed successfully. If building the package fails, it has no effect on the running system.

I suppose there is still a window in which an error could leave the system in an inconsistent state, but it's pretty narrow, and the error would have to be a kernel panic or something like that.

Err, are there any systems that try to cut over to a new package before it's been built successfully?

I guess that traditional package managers could install a helper script or a config file early in the build system before the main package is finished.

Yes. Almost all of them, actually. By "build" I mean the whole package installation process, including moving the compiled files into their final destinations.

If you're upgrading an existing package, and that involves overwriting one binary in /usr/bin and another in /usr/lib, a crash in the middle of that process leaves the package partially upgraded, and very likely broken.

Nix never overwrites an existing package installation. Instead, it installs the new version in a separate directory, then overwrites a symlink that pointed to the old version with a symlink pointing to the new version.

Things you must be afraid when using nix:

1) If you install a bad grub, you cannot rollback it using nix. That means, not a wrong grub line, but if grub itself is broken.

2) Anything that is not under nix control, the data: like desktop configurations, databases, ecc.

But after the first successful install you shouldn't have to worry about GRUB anymore. I don't know what it's like on NixOS, but on GuixSD we just change the grub.cfg.

You also upgrade grub versions I hope :) Or maybe improve the grub installation scripts.

The contents of any package are immutable; once they're written they're never modified again. New versions of the package get installed in a different directory tree.

Reply on news.ycombinator.com