Change:
ipfs --offline config Mounts.FuseAllowOther --json true ipfs --offline config Mounts.IPFS ${cfg.ipfsMountDir} ipfs --offline config Mounts.IPNS ${cfg.ipnsMountDir} <ins> '' + optionalString cfg.autoMigrate '' ${pkgs.ipfs-migrator}/bin/fs-repo-migrations -y </ins> '' + concatStringsSep "n" (collect <del> isString (mapAttrsRecursive (path: value: # Using heredoc below so that the value is never improperly quoted '' read value <<EOF ${builtins.toJSON value} EOF ipfs --offline config --json "${concatStringsSep "." path}" "$value" '') ({ Addresses.API = cfg.apiAddress; Addresses.Gateway = cfg.gatewayAddress; Addresses.Swarm = cfg.swarmAddress; } // cfg.extraConfig)) ); </del> <ins> isString (mapAttrsRecursive (path: value: # Using heredoc below so that the value is never improperly quoted '' read value <<EOF ${builtins.toJSON value} EOF ipfs --offline config --json "${concatStringsSep "." path}" "$value" '') ({ Addresses.API = cfg.apiAddress; Addresses.Gateway = cfg.gatewayAddress; Addresses.Swarm = cfg.swarmAddress; } // cfg.extraConfig)) ); </ins> serviceConfig = { <del> ExecStart = ["" "${cfg.package}/bin/ipfs daemon ${ipfsFlags}"]; </del> <ins> ExecStart = [ "" "${cfg.package}/bin/ipfs daemon ${ipfsFlags}" ]; </ins> User = cfg.user; Group = cfg.group; } // optionalAttrs (cfg.serviceFdlimit != null) { LimitNOFILE = cfg.serviceFdlimit; };

Discussion:
Describe the bug After updating the channel, IPFS does not start anymore. It would be nice if a migration would be done automatically if needed. Or at least document the process in the release notes. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior IPFS just working Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
When i run it again, nothing happens. So we might just put it in a systemd service that runs every time before IPFS starts. But it might break and lead to data loss. That would be very bad! It is advised to backup before doing this. So it has to be discussed if we do such dangerous operations on peoples data automatically or just document how to do it manually.
There are strong opinions both for automatic migrations and against. Some software will bake migrations right into their primary executable and not even give you a chance. Other software will not fail if you don't run a migration and silently introduce strange breaking behavior that can be difficult to diagnose. Some migrations can be awkward to run on NixOS. As you mentioned some migrations are not safe to run without human interaction. Some migration programs aren't idempotent. Some software can damage it's own state if upgraded and run before migrations are executed. And to top it all off, the NixOS module system doesn't give us the ability to easily prevent a service from starting the first time after an upgrade. In summary this topic is very complex and hasn't been discussed in any public forum in detail. It would be nice if NixOS had a good solution for this in general and promoted standard desired behavior to module authors.
I think we should run the migrations automatically. It isn't great to have your system stop working. They don't really recommend backups, they say to do them if you want to be extra safe. I think we should just rely on the user having their own backups anyways. We should probably have a flag to control this, but I think default-enabled would be fine.
ping because they have become increasingly interested in these types of topics lately. ping who wants to smash all things state. :smile:
What am I doing wrong?

EDIT: Also worked for me with
I used
Is there least some sort of one-shot systemd job that we could create that users would run by hand instead of the above? How are e.g. postgresql migrations handled today?
AFAIK, on postgresql migrations are always handled by applications themselves. Each application defines it's own ExecPreStart to run it's own migration. I was thinking that we could have a separate one-shot systemd job, and an option to run migrations automatically. If the automated migrations option is checked, then ipfs service would the migration job, and if it's not checked, then the user can run manually that job. I'm having a look at running IPFS at the moment. I've got a in case anyone is interested.
You can definitely run fs-repo-migrations in a dependency or PreStart command. Are you referring to Postgres version migrations or application schema migrations? Applications migrating their own schema is definitely the common case but I have yet to see an application that will automatically migrate your postgres from 9.2 to 9.3. The IPFS case is somewhat in the middle because it is both the application and the database. But in this case I think it makes sense to act like the application and run the migrations on startup.
yes, I was referring to schema migration. I've never seen version migration either.
I went with the easy solution, just running the migrator on preStart. The repo migration itself said that those were safe Happy to take feedback.