Design choice of `switch-to-configuration`

Personally I have two configurations with different network settings. I use networking.firewall.extraStopCommands to do some clean-up work.

However, if I declare those command in configuration A, no in configuration B, then when I switch from A to B using switch-to-configuration, those commands won’t be executed. I believe the reason is that switch-to-configuration will sets up /etc before restarting services.

So why is that? Is there a specific reason to do so?

1 Like

The order of activation steps is unlikely to be changed. No particular order is ideal.

The main way to prevent such issues is to move configuration files to /nix/store.

Another one, is to use systemd service with stopIfChanged = true;. It is default btw, but sometimes it is set to false. What happens during activation of a changed service with stopIfChanged = true;? It is stopped with code from old configuration, and started with code from new configuration.

Unfortunately for you, firewall service has reloadIfChanged = true;, which disables the stop logic above. It won’t run stop commands from old configuration, it will only run reload command from new configuration. NB:

It also runs your extraStopCommands but somewhere in the middle - . But because your new configuration doesn’t include extraStopCommands, they won’t be executed.

So easy way to fix that would be override and set = lib.mkForce false;. Then stop commands will be executed on all firewall changes.

Thanks, but it seems that if I set reloadIfChanged to falseeit will behave differently(reloadScript will not be executed), my current workaround is moving stop commands to configuration B, which is hacky though┑( ̄Д  ̄)┍

I wrote in a bit more detail about how to possibly make the reloads safer and more reliable at Please comment there :slight_smile: