macOS updates often break nix installation (updates replace path-hooks on multi-user install)

[amckinlay]

I have noticed that every once and a while /Users/andrewmckinlay/.nix-profile/bin and /nix/var/nix/profiles/default/bin disappear from my $PATH. The last time this happened, the hook nix installed was missing from /etc/zshrc.

Copying the following hook (copied from /etc/bashrc) to /etc/zshrc and restarting the shell fixed everything again:

# Nix
if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
  . '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
fi
# End Nix

My concern is that macOS updates will periodically overwrite /etc/.zshrc (and /etc/.bashrc), requiring effort on my part to reinstall nix. For example, one macOS update overwrote the entire file to fix this misspelling:

andrewmckinlay@imac ~ % diff /etc/zshrc.backup-before-nix /etc/zshrc
3c3
< # Setup user specific overrides for this in ~/.zhsrc. See zshbuiltins(1)
---
> # Setup user specific overrides for this in ~/.zshrc. See zshbuiltins(1)

Both files are read-only anyway, should they really be written to by the nix installer?

[lilyball]

If they keep updating these files, perhaps we should file an Apple Feedback report asking them to add /etc/bashrc.d/ and /etc/zshrc.d folders whose contents get sourced by the default scripts? This way we can add configuration there that won't get overridden.

Beyond that, the only automatic solution that comes to mind would be to have nix-daemon check these files on launch and re-add the Nix block if it's missing.

[ptitvert]

I have done a few days before the upgrade to Catalina 10.15.6... and today I wanted to install something to discover that my nix installation was gone!
Well after some research, I found that the /nix was still there, but everything else was gone... no nix-env command nothing!
So after cursing a lot... I search until I found this thread...
I would like also that this problem to solved... For the moment, I have put on my 2 users the following lines in the ~/.profile

# Nix
if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
  . '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
fi
# End Nix

So I don't care if the /etc/zshrc is or not overwritten in the future... I agree this is a bad solution, but at least for the time being my workaround...

[lilyball]

I filed feedback for Apple (FB8181728). In the meantime, nix-daemon will need to learn how to modify the files appropriately on launch.

[abathur]

The zsh case seems to have been fixed (but not released yet) in the course of #3456. I haven't observed this same issue with bash shell files.

Edit: this had its own problems and was reverted.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/here-are-the-etc-bashrc-amendments-performed-by-the-installer-on-macos/11360/1

[stale]

I marked this as stale due to inactivity. → More info

[elliot-u410]

I'm still seeing this issue as of Nix 2.3.15 and Big Sur 11.5.2. The workaround is to re-add the following to /etc/zshrc:

# Nix
if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
  source '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
fi
# End Nix

[abathur]

I'm still seeing this issue as of Nix 2.3.15 and Big Sur 11.5.2.

Edit: I see in matrix that #3608 caused its own problems documented in #4169, so I guess a release would actually be a step in the wrong direction atm... Striking through the parts that may not actually be much help...

FWIW this is roughly expected:

• The fix for the ZSH case was merged in Use /etc/zshenv instead of /etc/zshrc for profile #3608, but there hasn't been a release from master since then (and it doesn't look like anyone's backported it). I'm not really in the loop, but at least per https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204 there should be a release from master coming fairly soon?
• Even after a new release is cut from master, I expect you'll continue to see this behavior on an old install until you manually migrate or manually remove Nix and reinstall it.

I would try manually migrating. I think you'd just need to create /etc/zshenv if it doesn't exist, move your source line there, and verify it works.

Also: brownie points if you (or maybe any zsh user who hasn't taken 11.5.2 yet?) remember to report back here or in #3608 if this migration helps you dodge this problem.

[ggPeti]

can't we just patch zsh to use different rcfile paths? users can then set the patched zsh as their shell with nix-darwin

[abathur]

@ggPeti I assume it's ideal if it still works without Nix-darwin, but tbh I have no clue how big the set of (Nix + zsh - nix-darwin) uses is.

#4169 seems to have a more robust discussion on ~zsh-specific fixes, and I'm trying to fish around for someone to add it to the 2.4 milestone; if I find someone, that might be a good place to pull on the thread...

[abathur]

#4169 got closed without dealing with this part of the problem.

[abathur]

I recently stumbled on a reference to someone saying they'd taken an update and had the update leave their modified items in place, and add the replaced items to the Relocated Items directory.

I have a spare laptop on the beta release channel and wanted to try this out, so I took an update on it this afternoon to 11.5 and noticed two things:

• It did not displace /etc/bashrc on this update--it just placed the "official" bashrc at Relocated\ Items/Configuration/private/etc/bashrc.system_default.
• It did, however, still overwrite /etc/zshrc.

I'm not sure if this means they're treating zsh init files differently since it's the default shell, or if it means they inadvertently left zshrc out of the list of files to respect instead of replace. Something to watch closely in the next few updates, I guess.

See also: https://developer.apple.com/forums/thread/670671

[abathur]

I recently stumbled on a reference to someone saying they'd taken an update and had the update leave their modified items in place, and add the replaced items to the Relocated Items directory.

I have a spare laptop on the beta release channel and wanted to try this out, so I took an update on it this afternoon to 11.5 and noticed two things:

• It did not displace /etc/bashrc on this update--it just placed the "official" bashrc at Relocated\ Items/Configuration/private/etc/bashrc.system_default.
• It did, however, still overwrite /etc/zshrc.

I'm not sure if this means they're treating zsh init files differently since it's the default shell, or if it means they inadvertently left zshrc out of the list of files to respect instead of replace. Something to watch closely in the next few updates, I guess.

See also: https://developer.apple.com/forums/thread/670671

I tried this with an update from 12.0 beta to 12.0.1 and, once again, zshrc was overwritten.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/macos-update-and-nix/15779/2

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-commands-missing-after-macos-12-1-version-upgrade/16679/5

[ctheune]

And of course this happened again on 12.2. (@frlan)

[ctheune]

... please don't?!?

[amckinlay]

Every macOS update breaks nix. It's clearly not ready for macOS.

[asivitz]

When trying to debug this problem for myself, I think I was misled by the current documentation. For example, this discussion of environment variables

https://nixos.org/manual/nix/stable/installation/env-variables.html

assumes a single-user installation. (I think?) And because I don't have prefix/etc/profile.d/nix.sh I thought my installation might be broken. Am I right in thinking there should be separate sections for single and multi user installations and the multi-user section should mention nix-daemon.sh instead of nix.sh?

[abathur]

assumes a single-user installation... Am I right in thinking there should be separate sections for single and multi user installations and the multi-user section should mention nix-daemon.sh instead of nix.sh?

Good catch. I think so. If none of the differences between the two scripts seem to fall within the scope of the current documentation, it might suffice to just say that each mode has a distinct script and list the path for each?

[asivitz]

That sounds reasonable to me

[ajmas]

Since I am the only one using my computer, just including the necessary lines in my user's ~/.zshrc is the simplest solution for now.

[yanns]

for those using a home manager, you can use the following configuration:

  programs.zsh.initExtra = "if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
  . '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
fi";

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/why-can-i-not-execute-a-new-version-of-nix-with-nix-shell/31032/1

[iFreilicht]

For those who manually modified their user's ~/.zshrc, you may want to change the condition to something like this:

[[ ! $(command -v nix) && -e "/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh" ]] && source "/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh"

Otherwise, trying to test a new version of nix by using nix shell will still use the old version. See the thread linked by the discourse bot above.

[AwesomeDog]

The issue still persists on Sonoma 14.4 update.

[CharlesChiuGit]

persists on Sonoma 14.5 upgrade.

[FloThinksPi]

Has anyone considered/reviewed https://zero-to-nix.com/concepts/nix-installer ?
I will try this out with the update to 14.5 but so far it seems they dont write into the /etc/zshrc rather create a plist entry to make nix available in the shells path, interesting. May survive an update.

Edit: It survived the 14.5 update without issue it seems, when using the installer by Determinate Systems. Its not the official one though and despite the company being heavily involved in nix, its not wrong to question thrust-worthiness when you curl a script and run it as root :)

[mcg]

I use a Zero-to-Nix install on several Apple Silicon machines. It’s has survived several updates.

[abathur]

so far it seems they dont write into the /etc/zshrc rather create a plist entry to make nix available in the shells path, interesting.

This doesn't quite characterize it right. The DetSys installer does still modify shell profiles, but it also installs a launchd daemon (the plist) that runs /nix/nix-installer repair when it loads which in turn re-applies the shell profile fixes. Here's the implementation PR if you're curious:

• Make our Nix installation immune to macOS upgrades DeterminateSystems/nix-installer#672

Has anyone considered

Yep!

There's a slowly-progressing ~unofficial/experimental project in the NixOS org to work on a fork of the DetSys installer (fork mainly because the Nix team isn't yet on board with some of the ~opinionated differences between their installer and the canonical one, so we need to un-implement those or implement the official installer's approach if it differed). If that path leads to official adoption, we'll gain support for this that way.

Since the DetSys installer is leaning on its own repair command for the business end of this, implementing the same feature for the official shell installer would be a lot more complex than it looks like at a glance. One of the DetSys installer's key design decisions here is keeping a receipt of what the installer did. Without that receipt, the shell installer's version of this would probably look like one of:

• getting to (and staying at) full idempotence (and then just re-running the whole installer--with whatever user-tunable parameters were used for the first install)
• implementing full uninstall (that is able to account for user-tunable parameters), and implementing this as full uninstall and reinstall
• significantly refactor the installer to use a similar receipt approach and build something similar to the nix-installer's repair command

All of these are probably achievable, but they also smell like quite a lot of work to me. I also imagine the first two (~simpler) choices would be so slow that restoring terminal tabs with a zsh shell wouldn't have the fix when they load. My own limited energy is (at least for now) focused on getting the fork of the DetSys installer to the point where it's ~ripe for the Nix team to evaluate.

(We're close. I've delayed making some requests around this since it isn't urgent and many of the people I need to bug have been focused on urgent governance stuff.)

Around the same time as DetSys were adding this feature, I also opened a PR with a narrower (albeit weirder) workaround:

• darwin-installer: work around zshrc overwrites #9243

Aside: A third approach, which lilyball has advocated, is that nix-daemon itself should be able to do this itself.

I'm a little cautious around both workarounds because they're "weird" in a (slightly different) way that might lead some people to worry their system is compromised. Graham's comment linked below and my response reflect on this property of both:

• darwin-installer: work around zshrc overwrites #9243 (comment)

I haven't leaned on my PR much because:

• If it doesn't cause complaints or regular trouble of its own (i.e., flaky behavior due to a race condition, people disabling the service, etc.), I think the DetSys approach is better from an end-user perspective--it can repair a broader set of problems than my PR.
• Work on the fork will likely get us the same benefit, so I don't see much reason to add to the delta between the two installers until that resolves on way or another.