lix-project/lix

Fork 62

`upgrade-nix` fails to install instanced `nix-daemon@.service` #1112

New issue

Open

opened 2026-01-29 17:55:58 +00:00 by lunaphied · 6 comments

lunaphied commented

2026-01-29 17:55:58 +00:00

Owner

Describe the bug

When you upgrade to a nightly Lix from an existing non-NixOS install, the new instanced systemd target does not get linked in. As a result, daemon socket activation stops working correctly, as the socket unit file has Accept=Yes which causes systemd to expect th

Steps To Reproduce

Install Lix from the installer following the instructions at https://lix.systems/install (curl -sSf -L https://install.lix.systems/lix | sh -s -- install)
Build a nightly Lix (for example rev 56988d8605) and capture the store path.
Upgrade the installed lix by doing sudo nix upgrade-nix --store-path $builtStorePath.
Reboot the system (this is the easiest way to reload the systemd units and restart them correctly)
Observe that nix store ping no longer works when using the daemon.

Expected behavior

Either it should upgrade correctly or some kind of error should be thrown indicating a manual step is required for this update.

`nix --version` output

nix (Lix, like Nix) 2.95.0-pre20260127-dev_9861915
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/iris.iridium/.config/nix/nix.conf:/etc/xdg/xdg-ubuntu/nix/nix.conf:/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/lfpgnl5wfsfpgd955qfbs6rcac0nbzv2-lix-2.95.0-pre20260127-dev_9861915/share

## Describe the bug When you upgrade to a nightly Lix from an existing non-NixOS install, the new instanced systemd target does not get linked in. As a result, daemon socket activation stops working correctly, as the socket unit file has `Accept=Yes` which causes systemd to expect th ## Steps To Reproduce 1. Install Lix from the installer following the instructions at https://lix.systems/install (`curl -sSf -L https://install.lix.systems/lix | sh -s -- install`) 2. Build a nightly Lix (for example rev 56988d860593a5fd8153d02a0ca5469508378626) and capture the store path. 3. Upgrade the installed lix by doing `sudo nix upgrade-nix --store-path $builtStorePath`. 4. Reboot the system (this is the easiest way to reload the systemd units and restart them correctly) 5. Observe that `nix store ping` no longer works when using the daemon. ## Expected behavior Either it should upgrade correctly or some kind of error should be thrown indicating a manual step is required for this update. ## `nix --version` output ``` nix (Lix, like Nix) 2.95.0-pre20260127-dev_9861915 System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/iris.iridium/.config/nix/nix.conf:/etc/xdg/xdg-ubuntu/nix/nix.conf:/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/lfpgnl5wfsfpgd955qfbs6rcac0nbzv2-lix-2.95.0-pre20260127-dev_9861915/share ```

lunaphied added this to the 2.95 milestone

2026-01-29 17:55:58 +00:00

lunaphied added the

bug

OS/Linux

Affects/Nightly

labels

2026-01-29 17:55:58 +00:00

lunaphied changed title from ~~Upgrad~~ to upgrade-nix fails to install instanced nix-daemon@ systemd unit

2026-01-29 17:56:23 +00:00

lunaphied changed title from ~~upgrade-nix fails to install instanced nix-daemon@ systemd unit~~ to upgrade-nix fails to install instanced nix-daemon@.service

2026-01-29 17:56:31 +00:00

pennae commented

2026-01-29 18:03:54 +00:00

Owner

tbh upgrade-nix should just be deleted. on a nixos system it has no purpose, and on non-nixos systems it is bound to always cause problems of this sort. the installer has much better knowledge of where to put what and how to activate it, upgrading an installation should be done via the installer as well to take advantage of that

tbh `upgrade-nix` should just be deleted. on a nixos system it has no purpose, and on non-nixos systems it is bound to always cause problems of this sort. the installer has much better knowledge of where to put what and how to activate it, upgrading an installation should be done via the installer as well to take advantage of that

pennae added the

Release Blocking

Urgent

label

2026-01-29 18:09:53 +00:00

lunaphied commented

2026-01-30 07:22:47 +00:00

Author

Owner

I totally agree but right now this is our supported flow until that work gets done and either we need to block release on the installer improvements or (more realistically) block release on adding special case handling to upgrade-nix (I imagine we could add some kind of script that gets run after the profile is built but before switching to it if we wanted to make it somewhat generic)

pennae commented

2026-01-30 13:09:20 +00:00

Owner

yes, the releaswe cannot happen before we have some solution to this. we would greatly prefer doing this in the installer if at all possible because having two (diverging?) methods to get the latest version is likely to cause ever more problems as time passes, but we're not familiar with how active installer maintenance is right now

pennae commented

2026-03-06 12:52:39 +00:00

Owner

it seems that the most reasonable thing we can do is to refuse to upgrade with an additional confirmation step if systemctl is present and nix-daemon.socket is enabled without a nix-daemon@.socket being present. that should be easy enough to add and can link to our upgrade documentation to explain the gory details

it seems that the most reasonable thing we can do is to refuse to upgrade with an additional confirmation step if `systemctl` is present and `nix-daemon.socket` is enabled without a `nix-daemon@.socket` being present. that should be easy enough to add and can link to our upgrade documentation to explain the gory details

ktemkin commented

2026-03-08 14:25:52 +00:00

Member

@pennae wrote in #1112 (comment):

it seems that the most reasonable thing we can do is to refuse to upgrade with an additional confirmation step if systemctl is present and nix-daemon.socket is enabled without a nix-daemon@.socket being present. that should be easy enough to add and can link to our upgrade documentation to explain the gory details

This is what we should go with, for now. Eventually (next release, prolly?) we'll have the installer set up a basic profile manager to handle system upgrades, and then we can tear out upgrade-nix.

@pennae wrote in https://git.lix.systems/lix-project/lix/issues/1112#issuecomment-17970: > it seems that the most reasonable thing we can do is to refuse to upgrade with an additional confirmation step if `systemctl` is present and `nix-daemon.socket` is enabled without a `nix-daemon@.socket` being present. that should be easy enough to add and can link to our upgrade documentation to explain the gory details This is what we should go with, for now. Eventually (next release, prolly?) we'll have the installer set up a basic profile manager to handle system upgrades, and then we can tear out `upgrade-nix`.

ktemkin commented

2026-03-08 14:27:14 +00:00

Member

also, just to keep the record consistent:

the installer has much better knowledge of where to put what and how to activate it

We decided the installer doesn't; and instead a profile management tool is the actual thing that should be handling this.

also, just to keep the record consistent: > the installer has much better knowledge of where to put what and how to activate it We decided the installer doesn't; and instead a _profile management tool_ is the actual thing that should be handling this.